Journal Auto-hébergement: pas toujours évident...

Posté par (page perso) . Licence CC by-sa
17
5
fév.
2015

Sommaire

L'auto-hébergement a toujours été défini comme une alternative saine aux offres de stockage en ligne proposées par exemple par Amazon, Google ou Microsoft. Héberger chez soi ses propres données est un gage de sécurisation et de préservation de la confidentialité de ses données personnelles.

Il y a eu une période au cours de laquelle on trouvait toute une panoplie d'applications Libres pour réussir son auto-hébergement. On avait du choix, les applications étaient techniquement abouties et complètes. Puis il y a eu une période de creux. Une période pendant laquelle de nombreux projets ont été abandonnés, faute de temps et de moyens.

L'auto-hébergement retrouve désormais des couleurs, non pas sans rapport avec l'affaire Snowden, les atteintes quotidiennes à la liberté d'expression ou à la confidentialité, ou le vol de données privées. Malheureusement, le florilège des applications libres destiné à cet usage s'est réduit, et concilier sécurité, simplicité et fonctionnalités devient difficile.

Auto-hébergement et NAS

Sécurité: moyen
Simplicité: excellent
Fonctionnalités: bon, mais…

Les NAS "physiques" (comprendre: Synology, QNAP, etc.) offrent généralement un système de paquets logiciels permettant d'étendre leurs fonctionnalités: serveur web, serveur multimédia, serveur mail, etc. Cela permet de grandement simplifier leur installation bien sûr, mais au détriment - généralement - de leur "paramétrabilité".

Quand on a un accès root au système sous-jacent, les manques sont rapidement comblés par les connaisseurs. Quant aux utilisateurs lambda, ils utilisent ce qu'ils ont sous la main.

Le problème avec les NAS concerne surtout leur niveau de sécurité. Plus exactement, leur niveau de sécurité dépend de la réactivité des constructeurs à sortir des mises à jour en cas de problème. L'actualité récente (HeartBleed, ShellShock, etc.) nous a montré - si besoin était encore - que les systèmes fermés contraignent les utilisateurs à attendre que les constructeurs sortent des correctifs. Un paradigme insupportable pour les défenseurs du Libre, à juste titre puisque cela affecte la sécurité et la confidentialité des données. Cela soulève donc la question de la confiance que l'on choisi d'accorder à un système de stockage de données qui contiendra - a fortiori - des données privées. Autrement dit, confier ses données à un NAS dont le système n'est pas (totalement) libre serait équivalent à confier ses données à un hébergeur dans le cloud.

Au final, les NAS offrent une grande simplicité (l'installation peut se faire en un gros quart d'heure), au détriment des fonctionnalités et surtout de la sécurité. Je ne crois pas qu'il s'agisse d'une bonne solution pour faire de l'auto-hébergement à cause de ça. Quand on veut s'auto-héberger, c'est pour contrôler le stockage, et donc avoir confiance dans son système de stockage.

Un serveur home-made

Sécurité: excellent
Simplicité: peut mieux faire
Fonctionnalités: excellent mais…

À l'autre opposé, on a la possibilité de monter son propre serveur. Dans ce cas là, la sécurité n'est plus dictée "que" par le bon sens de l'administrateur, et sa connaissance des outils de base. Bien sûr, on ne joue plus dans la même cours que les NAS: monter un serveur soi même est loin d'être aussi simple et requiert un certain nombre de compétences pour être capable de le sécuriser. Mais le gain en terme de fonctionnalités est incommensurable, sauf que…

Le problème avec le serveur fait soi-même, je l'ai évoqué dans le premier paragraphe de ce journal. Il y a pour ainsi dire une certaine pénurie d'applications Libres dédiées à l'auto-hébergement.

Cas du client mail

Le webmail, tout simple

Un exemple concret: le webmail.

Il y a quelques temps, on avait:

Aujourd'hui, on a:

Ces listes sont loin d'être exhaustives, mais le but est de montrer que le choix s'est grandement limité avec le temps, pour différentes raisons.

Squirrelmail n'est pratiquement plus utilisable aujourd'hui, et Horde non plus dans une moindre mesure. Dans le cas du premier, l'austérité de son interface rebute les nouveaux utilisateurs, déjà habitués aux interfaces léchées, claires, pleines d'icônes et dynamiques. Et bien que Horde ait su mieux moderniser son interface, elle reste en retrait par rapport à la concurrence. D'ailleurs, son remplacement au profit de Roundcube dans un certain nombre de packages est révélateur (par exemple, Kolab n'offre plus Horde comme client depuis la version 3.0).

Les développeurs des autres solutions Libres ont simplement jeté l'éponge depuis 2013, voire avant. @mail est d'ailleurs probablement l'exemple le plus décevant puisque le projet Libre a été abandonné au profit d'une version sous licence non libre et qu'aucun fork n'existe depuis six ans.

Tout cela importerait peu si Roundcube et Mailpile n'étaient pas si "pauvres". Roundcube par exemple, bien que doté d'un système de plugins, souffre du manque de support du chiffrement et de la signature des mails: cela fait quelques années déjà que le support de GPG/PGP/SMIME est dans leur roadmap, et leur dépôt de plugins ne liste que des modules pour vérifier les signatures, pas pour chiffrer. Pas possible non plus d'envoyer un mail différé par exemple.

D'autre part, le seul plugin existant pour gérer un calendrier est celui de… Kolab, et ne supporte que des backends MySQL ou Kolab. Exit donc caldav ou les rappels automatiques.

Quant à Mailpile, bien que l'accent soit mis sur la sécurité, et donc un support natif de GPG, il n'a pas de gestion de dossiers, pas de panneau de visualisation, et encore moins de calendrier avec rappel, ou de gestion des filtres. Il est en phase de beta, ces manques pourraient être comblés à l'avenir, mais pour l'heure, ce n'est pas une solution viable pour le commun des mortels.

La solution tout-en-un

Il apparait donc qu'une solution plus adéquate, ou en tout cas plus souple, plus complète, est la solution tout-en-un, aka groupwares. C'est un compromis entre l'abondance des fonctionnalités, la simplicité d'installation et d'utilisation, et la sécurité.

Et là, les outils Libres sont un peu plus nombreux. Sans parler de Kolab qui repose sur Roundcube, je citerai Citadel, mais surtout Zimbra, que j'ai adopté avec une immense satisfaction.

Le cas des galeries photos

Un autre exemple auquel j'ai été récemment confronté: la gestion de galeries de photos.

Historiquement, je me suis toujours tourné vers Gallery. Et puis j'ai eu un Synology entre les mains, avec PhotoStation, que je trouvais tout simplement parfait: l'authentification se faisait auprès du serveur LDAP, les permissions d'accès étaient celles du système de fichiers, et les photos étaient dans l'arborescence du dossier dédié.

Gallery pourrait toujours faire tout ça, et remplacer avantageusement PhotoStation, non libre. Mais le projet est mort. En "hibernation" depuis juin dernier. Plus de mises à jour, donc potentiellement plus sécurisé.

Je n'ai pu trouver aucun remplaçant à Gallery, bien que cette fois, les solutions soient nombreuses. Pas de support de LDAP, obligation de stocker les photos dans l'arborescence de l'application, pas de liberté dans la structure des fichiers, pas d'affichage des données EXIF, il manque toujours quelque chose.

Le cas de la gestion des utilisateurs

Quand on monte son serveur et qu'on gère quelques utilisateurs, on a envie de le faire bien, et permettre aux utilisateurs d'utiliser le même identifiant et le même mot de passe pour tous les services hébergés. Cela permet aux utilisateurs d'utiliser une seule interface pour gérer leur compte. Par ailleurs, l'attribution et la gestion des droits en est simplifiée pour l'administrateur. Tout simplement une bonne pratique héritée des grosses structures.

Là encore on doit faire face à l'absence d'un tel système, pourtant bien présent dans les NAS.

Suite à un commentaire de NeoX, j'utilise désormais SSP. C'est parfait pour changer son mot de passe, mais quid des autres informations personnelles ? On pourrait par exemple supposer que certains utilisateurs préfèreraient un shell différent de celui attribué par défaut, ou la possibilité de changer son avatar, son téléphone, son adresse, etc. Je n'ai pas pu trouver une telle application.

Il y a bien MDS qui offre ces fonctionnalités, mais apparemment ne supporte pas les champs LDAP SambaNTPassword et SambaLMPassword, qui évitent notamment une manipulation dans le registre des clients Windows relative au chiffrement des mots de passe.

Conclusion

L'auto-hébergement est vital. C'est peut être long et fastidieux, mais c'est enrichissant, intéressant, en plus d'être gage de protection de la confidentialité.

Malheureusement, tant qu'on ne retrouvera pas la diversité des applications existantes avant l'avènement du cloud, et tant qu'elles ne conjugueront pas la simplicité des applications livrées avec les NAS avec l'exhaustivité typique des applications Libres, je crois que l'auto-hébergement (hors NAS) restera plus ou moins marginal, réservé à une population de connaisseurs, et par conséquent, et malgré les faits d'actualité, le commun des mortels ne pourra pas pleinement mesurer son importance.

Il faut voir le bon côté des choses: on pourra toujours leaker des photos compromettantes…

  • # je suis épaté

    Posté par (page perso) . Évalué à 10.

    un article sur l'auto-hébergement qui ne cite ni Seafile, ni Owncloud…

    Puisqu'on parlait des Odroid récemment, un lien sur Seafile, Owncloud et les Odroid

    http://magazine.odroid.com/assets/201501/pdf/ODROID-Magazine-201501.pdf

    If you choose open source because you don't have to pay, but depend on it anyway, you're part of the problem.evloper) February 17, 2014

    • [^] # Re: je suis épaté

      Posté par (page perso) . Évalué à 3.

      Je n'en ai pas parlé parce que les solutions de stockage et d'accès aux fichiers existent et sont abouties, et qu'un article sur l'auto-hébergement qui les citerait serait probablement redondant :)

  • # Rainloop ?

    Posté par (page perso) . Évalué à 10.

    Il y a Rainloop comme Webmail également, c'est celui que j'utilise. L'interface est simple et moderne, il y a OpenPGP.js d'intégré, la gestion des filtres Sieve vient d'y être ajoutée, il y a une gestion des dossiers, il gère CardDAV pour les contacts, et les mises à jour se font via l'interface admin. Il n'y a cependant pas de calendrier.

    Ça répond plus ou moins aux manquements de Roundcube et Mailpile ?

    • [^] # Re: Rainloop ?

      Posté par (page perso) . Évalué à 2.

      Ça répond plus ou moins aux manquements de Roundcube et Mailpile ?

      En tout cas ça mérite d'être essayé :)

      • [^] # Re: Rainloop ?

        Posté par . Évalué à 0.

        Rainloop est super, ça fait plaisir à voir !
        Il mériterait une dépêche à lui tout seul, non ? :)

        • [^] # Re: Rainloop ?

          Posté par (page perso) . Évalué à 2.

          https://linuxfr.org/proposer-un-contenu
          "Les dépêches servent à publier de l'information sur les thèmes principaux de LinuxFr.org, à savoir Linux et les Logiciels Libres."

          Vu que RainLoop n'a pas vraiment de lien avec Linux (à part qu'il est instalable dessus, mais si on part par la on peut aussi parler d'Oracle DB) ni avec le libre, ça serait bizarre que la dépèche soit acceptée (mais bon, il y a des incohérences parfois donc peut-être que ça passera).

    • [^] # Re: Rainloop ?

      Posté par . Évalué à 10.

      http://www.rainloop.net/licensing/

      Rainloop n'est pas libre

      https://github.com/RainLoop/rainloop-webmail

      et écrit en PHP

      Pouark !!!!

    • [^] # Re: Rainloop ?

      Posté par (page perso) . Évalué à 6. Dernière modification le 05/02/15 à 17:10.

      Pour le libristes en herbe, remarque : ce n'est pas libre.

      Edit : argh, grillé de quelques secondes!

      • [^] # Re: Rainloop ?

        Posté par (page perso) . Évalué à -2.

        Ah effectivement… Enfin bon, la clause NC ne me dérange pas pour ma part.

        • [^] # Re: Rainloop ?

          Posté par (page perso) . Évalué à 2.

          J'ai bien précisé que ça peut être bloquant pour les libristes.
          Après, pour ceux qui s'en foutent du libre et veulent juste un truc gratos dont sa version modifiée ne pourra jamais aller dans un repo libre, forcément ça n'a pas d'importance.

        • [^] # Re: Rainloop ?

          Posté par (page perso) . Évalué à 4.

          cela pourrait empêcher de demander des thunes à sa famille pour participer à l'hébergement…

          (ah bah oui, c'est du NC, son ampleur est difficilement mesurable :/)

          • [^] # Re: Rainloop ?

            Posté par (page perso) . Évalué à 2.

            Respectueux des licences, je me devrais de le désinstaller de mon serveur perso avant de répondre à une offre d'emploi. C'est quand même balo.

            • [^] # Re: Rainloop ?

              Posté par . Évalué à 5.

              je me devrais de le désinstaller de mon serveur perso avant de répondre à une offre d'emploi

              Tu pourrais attendre le vendredi..

              Depuis la FAQ de la CC :
              "NonCommercial means not primarily intended for or directed towards commercial advantage or monetary compensation."

              • [^] # Re: Rainloop ?

                Posté par (page perso) . Évalué à 4. Dernière modification le 06/02/15 à 09:42.

                Ce qui est pratique avec le mot "primarily" c'est que la limite est floue, et ça ouvre la porte à beaucoup de conflits.

                N'empèche, si pendant 1 mois tu utilises ton webmail quasi-exclusivement pour ta recherche d'emploi (est-ce commercial? déjà pas facile de répondre : pas stricto-sensu, mais le but est de trouver du fric, pas facile), ça ne devient pas "primarily" à ce moment?

                Bref, si on compte faire un usage commercialement (difficile à définir) secondaire (déficile à définir), quel qu'il soit, vaut mieux éviter.
                Déjà qu'avec la GPL, qui ne parle pas de "primarily", on a une tonne de conflits…

                Mais tu as bien raison, ça aurait mérité le troll du vendredi!

          • [^] # Re: Rainloop ?

            Posté par . Évalué à 4.

            Non. Parce que dans ce cas, tu ne factures pas nécessairement l'usage du logiciel, mais la bande passante, le stockage, l'électricité, le temps d'administration, voire même, soyons fou, les frais de femme de ménage.

  • # Zimbra

    Posté par . Évalué à 6.

    mais surtout Zimbra, que j'ai adopté avec une immense satisfaction.

    Ouais mais Zimbra c'est monstrueux, il faut un serveur 64 bits avec 4GB de RAM minimum pour le faire tourner, et j'ose même pas imaginer ce qui se passe le jour où ça ne fonctionne plus (pas simple à dépanner à moins d'avoir un expert de chez vmware). Mais effectivement c'est puissant, beau, abouti, scalable.

    Sinon tu aurais pu jeter un oeil du côté de Yunohost, je l'utilise depuis 2014 et ça poutre pas mal. La gestion de multiples utilisateurs y est présente.

    • [^] # Re: Zimbra

      Posté par (page perso) . Évalué à 2.

      Un serveur 64Bits, tant qu'on essaye pas de le faire tourner sur un Pi, on s'en sort pas trop mal. Je le fais tourner sur un A4-5300, 4Go avec un load-average de 0.01 0.07 0.12. Pour une machine qui m'a couté moins de 150 euros, c'est pas mal je trouve :)

      Pour Yunohost, c'est un malheureux oubli de ma part. Merci de l'avoir signalé :)

      • [^] # Re: Zimbra

        Posté par . Évalué à 4.

        Dans les solutions tout en un, il y a SoGo. J'ai pas testé.

        • [^] # Re: Zimbra

          Posté par . Évalué à 2.

          SOGo n'est pas "tout en un", il a besoin de se reposer sur un serveur SMTP, IMAP et LDAP existants.
          Cela peut d'ailleurs être vu comme un avantage, si ton entreprise a déjà un annuaire et un serveur de messagerie, SOGo viendra s’imbriquer dedans sans faire d'histoires :)

          • [^] # Re: Zimbra

            Posté par . Évalué à 2.

            En fait, SOGo est aussi un tout en un, via leur solution ZEG (Zero Effort Groupware). Le revers de la médaille étant qu'ils imposent du coup leurs choix de technos, notamment Cyrus (alors que Dovecot c'est cool).

  • # Webmails, GPG, toussa...

    Posté par . Évalué à 3.

    Tout cela importerait peu si Roundcube et Mailpile n'étaient pas si "pauvres". Roundcube par exemple, bien que doté d'un système de plugins, souffre du manque de support du chiffrement et de la signature des mails: cela fait quelques années déjà que le support de GPG/PGP/SMIME est dans leur roadmap, et leur dépôt de plugins ne liste que des modules pour vérifier les signatures, pas pour chiffrer.

    Il est vrai que ce genre de fonctionnalité intégrée au webmail aiderait certainement à grandement populariser le chiffrement des courriels.

    D'un autre côté, pour autant que j'imagine le fonctionnement du-dit bouzin, cela implique une immense confiance dans le serveur a qui on va confier sa clé, et qui aura en plus la possibilité d'intercepter les mot de passe des clés. Glurp. Dites moi si je me trompe. Si ce n'est pas le cas, je verrais largement à la baisse la confiance que j'accorde au chiffrement des courriels avec PGP, craignant un risque trop fort de compromission des clés de mes correspondants..
    En ce qui me concerne, je n'accorderais une telle confiance que dans un webmail installé sur une machine sur laquelle j'ai la main (en fait, je ne conserve mes clés privées que sur des disques eux-même chiffrés). C'est « un peu » limitant. Autant en rester au chiffrement courriel avec des clients classiques (Mutt, Thunderbird, Evolution, Claws, etc).

    Quitte à chiffrer des courriels avec un webmail, un bon compromis ne pourrait-il pas être l'utilisation d'extensions au navigateur ? Je crois qu'il en existait une pour Firefox, à un moment, mais qu'elle n'est plus maintenue (je n'ai pas refait de recherche à l'instant pour vérifier).

    • [^] # Re: Webmails, GPG, toussa...

      Posté par (page perso) . Évalué à 0.

      Via le navigateur, c'est le fonctionnement de SMIME pour autant que je sache.

      Pour GPG, on parle bien d'auto-hébergement, donc a fortiori, le webmail est sur un host en https. Donc normalement, pas possible d'intercepter les mots de passe (en théorie…)

      • [^] # Re: Webmails, GPG, toussa...

        Posté par . Évalué à 1.

        Ben c'est rajouter un maillon à une chaîne de sécurité. Et en terme de sécurité, moins il y a de maillons et mieux c'est, car si l'un est compromis, c'est toute la chaîne qui risque de l'être.

        Même si, oui, on perd le côté pratique du webmail.

  • # Pourquoi obligatoirement un webmail ?

    Posté par . Évalué à 10.

    C'est une question un peu naïve mais pourquoi obligatoirement un webmail ?
    Pourquoi pas un serveur Postfix + des clients "riches/lourds" comme Thunderbird ou K-9 ?

    En plus de mon expérience perso, les gens consultent de plus en plus les emails via une appli sur mobile.

    Bon ok on perd un peu en souplesse (pas si facile de consulter ses emails sur un autre poste que le sien) mais on gagne beaucoup plus par ailleurs.

    • [^] # Re: Pourquoi obligatoirement un webmail ?

      Posté par (page perso) . Évalué à 4.

      C'est comme une roue de secours : c'est inutile jusqu'à ce qu'on ai un problème et qu'on a besoin d'un truc pour dépanner (son smartphone rend l'âme et on est chez un pote etc…)

      Mais sinon, je reconnais que c'est de moins en moins utile depuis l'avenement des smartphones (on n'a plus besoin de taxer le PC du pote)

      • [^] # Re: Pourquoi obligatoirement un webmail ?

        Posté par . Évalué à 4.

        Un webmail à deux balles dépanne aussi bien qu'une galette.

      • [^] # Re: Pourquoi obligatoirement un webmail ?

        Posté par . Évalué à 2.

        Si tu en es au point d'installer ton propre serveur chez toi et de faire des pieds et des mains pour installer un webmail qui marchouille juste pour les cas de dépannage, peut-être que le plus simple est d'apprendre à se servir de SSH + Mutt (ou emacs !) ;-)

        En plus je crois que j'ai vu un truc qui permet d'avoir un SSH dans son navigateur…

        Mais bon OK, je comprends que l'on puisse avoir besoin d'un Webmail dans certains cas. Je me pose juste la question si certains n'en font pas une montagne alors qu'ils n'en ont pas vraiment besoin. Donc je suis preneur des cas de figure où c'est vraiment essentiel et que ça justifie tous les efforts.

        • [^] # Re: Pourquoi obligatoirement un webmail ?

          Posté par (page perso) . Évalué à 2.

          Une fois l'installation d'un serveur de mail fait, installer un webmail type Rouncube (celui que je connais) c'est vraiment un jeu d'enfant.
          On parle d'auto hébergement. Si on y met ses emails, il est plus que probable qu'il y ait aussi dessus un serveur web parce que c'est pratique pour administrer plein de trucs, et montrer ses photos à Mamie.

          Donc le webmail, c'est décompresser l'archive dans le bon coin et 3 lignes de paramétrage.

          C'est plus rapide qu'apprendre à utiliser Mutt, d'autant que c'est pour un truc qu'on utilisera qu'une fois de temps en temps, donc pour lequel on n’aura aucune habitude.

        • [^] # Re: Pourquoi obligatoirement un webmail ?

          Posté par . Évalué à 2.

          faire des pieds et des mains pour installer un webmail qui marchouille

          Jamais essayé, mais, apt-get install roundcube ne fait pas le taf? (vraie question hein, je voudrai savoir si tu as essayé avant de dire que c'est complexe…)

          • [^] # Re: Pourquoi obligatoirement un webmail ?

            Posté par . Évalué à -1.

            Jamais essayé, mais, apt-get install roundcube ne fait pas le taf? (vraie question hein, je voudrai savoir si tu as essayé avant de dire que c'est complexe…)

            Tu peux jeter un oeil par toi-même :
            http://trac.roundcube.net/wiki/Howto_Install

            Et si en regardant en 30s la page wiki, tu penses encore que c'est très facile à installer et demande peu de maintenance au quotidien, on peut en discuter, oui.

            • [^] # Re: Pourquoi obligatoirement un webmail ?

              Posté par . Évalué à 6.

              Hum… ce wiki est à côté de la plaque, pour un utilisateur de distro linux.

              # apt-get install apache2
              # apt-get install php5 php-pear php5-mysql
              # apt-get install php5-mcrypt php5-intl
              

              Moi je le fais en moins de caractères: # apt-get install roundcube. Ça m'installe apache et php direct.
              Ok, à la fin je n'aurai que la version 0.9.5 (hé, je suis sous Debian après tout… et encore, c'est le backport ;) ) mais ça me semble moins casse-gueule que la façon officielle d'installer la v1.
              Mais l'avantage, c'est que derrière il y à des gens qui savent mieux que moi ce qu'ils font qui ont packagé le soft pour qu'il s'intègre dans la distro sans anicroche. Le wiki que tu pointes, lui, décrit comment installer manuellement la toute dernière version, en se fadant la maintenance manuellement alors que quelqu'un dans ta distro le fait peut-être déjà. Mais c'est légitime pour un soft d'expliquer comment s'installer à la main, hein, juste, ce n'est pas la référence. Ils ne sont pas la pour faire les paquets, ils font déjà le logiciel… (même s'il est vrai que ça serait pas mal qu'ils proposent un paquet plus ou moins propre des distros majeures, c'est pas comme s'il fallait qu'ils compilent pour chaque archi. Mais bon, yaka faukon…)

              En fait, ça me rappelle quand j'ai essayé d'installer redmine la première fois: pleins de trucs bizarre à faire quand on suit le fm, puis tu t'aperçois qu'avec un simple apt-get redmine ruby-passenger en prenant les backports (problème de debian, quand on veut du neuf en stable, faut backport ou bidouiller…) et en suivant la procédure Debian, tout marche sans problème.
              À noter que je dois spécifier passenger parce que j'ai la manie de désactiver l'installation automatique des paquets recommandés.

              Du coup, vraiment, est-ce qu'un simple apt-get ne suffit pas? Et si c'est le cas, en quoi il faut faire des pieds et des mains ?

              • [^] # Re: Pourquoi obligatoirement un webmail ?

                Posté par . Évalué à 0.

                Si ton métier est sysadmin ou que tu as les compétences d'un sysadmin, je pense que tout cela doit te paraître très facile.

                Moi je vois tout de suite les problèmes que j'aurai au delà du double-clic pour installer :
                - base de données : apprendre à s'en servir un minimum et organiser proprement le backup (en ce moment j'ai tout le temps des merdes avec le backup de PostgreSQL)
                - serveur web : le configurer correctement, blinder la sécurité, mettre en place https et les certificats SSL, un mécanisme de fail2ban ou un captcha en plus
                - gestion du spam : j'ai suivi le tutorial "héberger son courriel" passé sur linuxfr, bah faire marcher Dspam cela n'a pas marché tout de suite (de mémoire déplacer un spam dans le dossier Spam pour qu'il rentre dans la base des spams).
                - IMAP : Fastmail m'a fait des soucis avec l'IMAP au niveau des dossiers (j'ai eu des doublons à un moment donné), j'imagine que ce doit être aussi un peu délicat avec Roundcube (suffit de voir les bugs ouverts et fermés sur le bug tracker de Rouncube sur IMAP pour avoir une idée)

                Et ça c'est sans même avoir mis le nez dans Roundcube.

                • [^] # Re: Pourquoi obligatoirement un webmail ?

                  Posté par . Évalué à 3.

                  Justement, ma question c'est: avant de dire que c'est difficile, a-t-il été tenté d'installer, via le gestionnaire de dépôt de la distro (du graphique, ok, synaptic) le paquet roundcube?
                  Ce à quoi on me renvoie la page d'installation manuelle du site officiel, qui est complètement à côté de la plaque puisque ma distro, qui n'est pas l'une des moins célèbre ni des plus jeunes, intègre un paquet…

                  Je ne dis pas que c'est facile d'installer un serveur mail, mais roundcube c'est un client, qui devra de toute façon nécessiter d'être configuré pour utiliser un serveur. Donc, encore une fois, est-il si difficile que ça d'installer roundcube? Et pas en passant par les étapes manuelles: quand t'installes claws (par exemple) tu te tapes la compilation toi? Pas moi.

                  • [^] # Re: Pourquoi obligatoirement un webmail ?

                    Posté par . Évalué à 0.

                    Pardon mais je pense que tu n'as pas compris ma réponse.

                    Tout ce que j'ai mis c'était des choses à faire absolument parce que j'installe Roundcube.
                    Si je n'installe pas Roundcube mais juste Postfix, je n'ai pas besoin de base de données, de serveur web, etc.

                    Donc (désolé si je me répète) dire que installer (et maintenir) Roundcube cela se résume à apt-get install Roundcube + apt-get upgrade de temps en temps et puis basta, c'est un peu exagéré.

                    Pour ma part après avoir installé mon serveur, j'ai été surpris par ce que je voyais passer dans les logs, c'était pas beau à voir.

                    Je pense que tu sous-estimes la tache, non pas par mauvaise foi, mais plutôt parce que pour toi c'est facile de par tes compétences (ou alors c'est que je suis vraiment nul, ce qui est aussi possible…).

                    • [^] # Re: Pourquoi obligatoirement un webmail ?

                      Posté par . Évalué à 1.

                      Donc (désolé si je me répète) dire que installer (et maintenir) Roundcube cela se résume à apt-get install Roundcube + apt-get upgrade de temps en temps et puis basta, c'est un peu exagéré

                      Juste pour être vraiment sûr: tu as essayé? Parce que, oui, la page du wiki indiquée est tout sauf attirante. C'est l'équivalent d'un howto pour compiler, pour moi.

                      pour toi c'est facile de par tes compétences

                      J'en doute, je ne suis pas admin.

                      (ou alors c'est que je suis vraiment nul, ce qui est aussi possible…).

                      Je ne m'aventurerais pas à dire ça.

                      Bon allez, pour le fun, je me lance, vais faire ça sur ma machine actuelle.

                      Machine cible:
                      Debian Wheezy + backports, presque à jour (j'ai pas mis à jour de la semaine…)
                      Quelques outils de dev installés, notamment pour faire joujou avec postgresql.
                      Paquets recommandés non installés par défaut.
                      Gestionnaire de paquets: aptitude (mode ncurses)

                      • Je sélectionne roundcube. Conflits détectés. J'annule les actions. Je sélectionne, ce coup-ci, roundcube, version backports (plus récente), aucun conflit.
                      • roundcube-sqlite3 installé par défaut. Ça ne me conviens pas, j'ai envie de voir un peu plus loin ce que ça donne avec pgsql. Du coup je sélectionne roundcube-pgsql version backports. Toujours aucun problème détecté.
                      • je jette un œil à l'aperçu
                        • javascript-common est recommandé. Je prend note, j'installe pas mais j'en aurai peut-être besoin plus tard si ça marche pas. Idem, je note php-auth-sasl, authentification, j'en aurai peut-être besoin.
                        • diverses suggestions, rien de pertinent à première vue: de la doc, des plugins… on verra plus tard.
                        • divers paquets sélectionnés pour installation, genre apache, jquery, etc. Peu m'importe, je fais confiance à aptitude, c'est juste ma curiosité maladive de dev, et ça me permets d'identifier des libs dont j'entends souvent parler mes confrères du web.
                      • je valide.
                      • téléchargement, dépaquetage, sélection, paramétrage, démarrage d'apache…
                      • question de l'installateur: dois-je configurer avec db-config. Je dis oui, et sélectionne pgsql (qui est sélectionné par défaut, étrange, normalement il aurait du avoir sqlite3 par défaut, une tentative précédente sans faire les choses aussi proprement avait aussi cette sélection alors que debian avait sélectionné sqlite. Bon, un choix à faire.). Demande du password pgsql. Deux fois. Je mets ce bon vieux P@ssw0rd, par habitude: m'en fout c'est du test.
                      • installation finie.

                      Je teste, rien sur localhost. Ah, si, des résidus de trucs que j'ai bricolé par le passé… l'inconvénient d'une machine de dev, faudra que je nettoie ça un jour. Bref, je sais pas ou aller…
                      Reste à ajouter roundcube à apache. J'ai déjà eu à me battre contre apache par le passé, du coup je crois savoir qu'il faut ajouter un fichier dans /etc/apache2/sites-enabled. Généralement le fichier en question existe dans sites-available, et on est censé faire un lien symbolique, ou utiliser je ne sais plus quelle commande à la con…
                      Flemme de réfléchir, ddg et "apache ajouter roundcube". Je note les 2nd et 3ème liens: le 2nd est vers le site officiel, en anglais. Flemme. Le 3ème c'est ubuntu, en français, vais jeter un œil.
                      L'auteur indique: installer via apt-get (déjà fait de mon côté), dé-commenter 2 lignes de conf de roundcube, relancer apache, et aller sur http://monserveur/roundcube. Dans mon cas, http://localhost/roundcube. Je teste, ça semble marcher: roundcube me demande un nom d'utilisateur, un mot de passe et un serveur.

                      C'est quand que ça deviens compliqué? Peut-être que si j'essaie d'accéder à un serveur pour de vrai, ça ne marche pas? Tu as suivi ce chemin la?
                      Parce que jusque la, admets le: rien de sorcier… Mais je n'ai pas suivi les instructions officielles, j'ai utilisé la raison d'être des distributions linux: le système de paquet.

                      Dans mon cas, c'est d'ailleurs inutilement compliqué à cause de ma config perso (j'aime avoir le contrôle maximum sur mon système): un utilisateur vraiment lambda n'aura aucun choix à faire, sauf activer les backports et prendre les versions de roundcube correspondantes.
                      C'est juste qu'il se retrouvera avec des outils en plus et une base sqlite au lieu de postgresql. Rien de bien méchant.

                      PS: j'ai failli me faire la config d'apache à la mano, mais j'ai eu la flemme, j'ai horreur de cette usine à gaz. C'est pour ça que j'ai préféré une recherche rapide finalement, et grand bien m'en a pris on dirait. D'ailleurs, cette version de roundcube à l'air plus léchée que celle que j'utilise. Je testerai peut-être plus en détails plus tard.

                      • [^] # Re: Pourquoi obligatoirement un webmail ?

                        Posté par . Évalué à 1.

                        Bon j'abandonne, tu n'as même pas lu mon message plus haut où j'énumérais les problèmes : c'est là que c'était justement délicat.

                        • [^] # Re: Pourquoi obligatoirement un webmail ?

                          Posté par . Évalué à 2. Dernière modification le 06/02/15 à 15:55.

                          Dans les points que tu cites, aucun n'est par rapport à roundcube, et encore moins à son installation.

                          • HTTPS? SSL? En quoi ça a à voir avec roundcube? Il marche sans non? Si tu es capable de mettre en place du SSH, je pense que tu sauras faire la même chose pour de l'HTTP.
                          • apprendre à se servir de SQL pour les backup? Complètement faux, le choix par défaut c'est sqlite3, qui stocke la DB dans un fichier. Niveau sécu c'est bof de mémoire, mais niveau sauvegarde c'est ce qu'il y à de plus simple: tu copies/colles le fichier. En fait, ça reviens à faire un backup de ton home avec mutt je pense.
                          • le spam? Tu n'es pas obligé de le traiter côté client le MUA, tu peux très bien le faire côté serveur, aka MTA. C'est ce qu'il y à de plus efficace en fait. D'ailleurs, comment fais-tu avec mutt?
                          • l'IMAP? Quel est le problème exactement? En quoi ce serait différent de mutt?

                          Oui, tu peux abandonner, donner de vraies raisons pour dire qu'il faut «faire des pieds et des mains pour installer un webmail qui marchouille juste pour les cas de dépannage» à l'air trop dur pour toi.

                          Le pire, c'est que tu parles de mutt, mais ce MUA n'est pas trivial à apprendre à utiliser. Contrairement à roundcube.

                          • [^] # Re: Pourquoi obligatoirement un webmail ?

                            Posté par . Évalué à 1.

                            Alors rapidement :

                            • HTTPS : tu te connectes comment à ton Roundcube ? Via HTTP seulement ? Et le but c'est d'améliorer sa vie privée ? Génial.
                            • DB backup : perso j'utilise PostgreSQL (sqlite je trouve que ce n'est pas assez fiable et robuste, choix perso). Au moindre pépin il faut savoir un peu où l'on met les pieds. Donc utiliser PostgreSQL sans rien y connaître et espérer ne jamais avoir à intervenir dedans j'y crois plus (j'y croyais et à la première merde j'ai du lire la doc). sqlite, ok tu peux juste copier le fichier pour faire un backup. PostgreSQL c'est pas si facile.
                            • Spam : tu n'as pas compris. Je traite côté serveur, mais côté client quand je marque en tant que Spam il faut que cela remonte bien l'info côté serveur. J'utilise Dspam sur le serveur et bah cela n'a pas été facile de le configurer pour que cela marche bien avec le client.
                            • IMAP : J'ai eu des problèmes avec Gmail, avec Claws, j'ai eu des problèmes avec K-9, j'ai eu des problèmes avec Fasmail, bref j'ai toujours eu des petits soucis avec IMAP. J'imagine que ce sera pareil avec Roundcube (je suis juste allé voir le bug tracker et je ne suis pas le seul à lutter avec IMAP parfois), mais on peut prier bien fort et espérer que tout roule parfaitement avec Roundcube (ok ce point là il est aussi avec les autres clients emails).

                            Enfin je ne pense pas réussi à te faire changer d'avis : si tu penses que tu peux garder ton install exactement comme ça et y confier tes emails sans aucune arrière pensée, tant mieux pour toi. Il y en a bien qui gardent leur argent sous le matelas avec un gros cadenas sur la porte, ils font ce qu'ils veulent…

                            • [^] # Re: Pourquoi obligatoirement un webmail ?

                              Posté par . Évalué à 2.

                              HTTPS : tu te connectes comment à ton Roundcube ? Via HTTP seulement ? Et le but c'est d'améliorer sa vie privée ? Génial.

                              Certes, mais, selon moi, roundcube n'est que le site web, il exploite la couche 7 du modèle OSI, il ne la fournit pas. Le point délicat, c'est la configuration du serveur web, qui lui fournit la couche 7 (http ou https pour du serveur web).
                              Tu l'as dis toi-même (enfin, me semble que c'était toi, pardonnes moi j'ai pas envie de remonter au début de ce fil): pourquoi s'embêter, il suffit d'utiliser mutt+ssh.
                              Dans cette idée, c'est simple: ssh gère la connexion, et mutt configuré en accès local te permets d'accéder aux mails. Tu y considères bien que le client mail et le protocole de transport sont deux choses différentes, alors pourquoi tu ne fais pas la distinction également pour roundcube?
                              Et d'ailleurs, pourquoi ne pas utiliser un tunnel SSH plutôt que du HTTPS avec roundcube (oui, je sais, c'est contraire à l'usage habituel)?

                              sqlite je trouve que ce n'est pas assez fiable et robuste, choix perso

                              Yep, je ne suis pas trop motivé non plus pour utiliser du sqlite, même s'il à ses avantages. Mais je suis d'accord avec toi: pour maintenir un SGBDR, il faut des compétences (enfin, savoir se servir de pg_dump/pg_restore/psql en l'occurrence).
                              Maintenant,

                              IMAP : J'ai eu des problèmes avec Gmail, avec Claws, j'ai eu des problèmes avec K-9, j'ai eu des problèmes avec Fasmail,

                              J'imagine que tu dois avoir un usage plus avancé que beaucoup de gens. Je t'avoue que je ne me suis jamais vraiment penché sur la question.
                              D'ailleurs, tu dis toi-même que tous les MUA que tu as utilisé ont des problèmes avec IMAP, mais, n'est-ce pas le MTA derrière qui, en fait, gère mal? Comment le savoir quand tu ne peux accéder serveur? Les mails, c'est, je le sais, loin d'être simple, mais je ne pense pas que la complexité vienne des MUA.

                              Ce qui me pose souci dans ton propos en fait, c'est que tu considères roundcube comme l'ensemble de la pile. Roundcube est simple à installer et configurer. La pile logicielle permettant de fournir un webmail public, elle, est complexe, et je ne pense pas l'avoir nié.
                              Mais voila: elle est complexe parce que tout serveur public est une chose sensible, auto-hébergé ou pas. Justement parce que c'est une pile, il faut configurer plusieurs logiciels pour qu'ils marchent ensemble, et ce n'est pas juste la faute de l'interface homme-machine si c'est difficile.
                              Voila mon propos.

                              • [^] # Re: Pourquoi obligatoirement un webmail ?

                                Posté par (page perso) . Évalué à 5.

                                Ce qui me pose souci dans ton propos en fait, c'est que tu considères roundcube comme l'ensemble de la pile. Roundcube est simple à installer et configurer. La pile logicielle permettant de fournir un webmail public, elle, est complexe, et je ne pense pas l'avoir nié.

                                Ben c’est pourtant exactement le propos qui a lancé tout ce thread:

                                faire des pieds et des mains pour installer un webmail qui marchouille

                                Tu confirmes bien qu’installer et maintenir un webmail, si on a pas déjà du web pour d’autres raisons, c’est la merde. Il a dit plusieurs fois clairement que c’était ça son problème:

                                Tout ce que j'ai mis c'était des choses à faire absolument parce que j'installe Roundcube.
                                Si je n'installe pas Roundcube mais juste Postfix, je n'ai pas besoin de base de données, de serveur web, etc.

                                • [^] # Re: Pourquoi obligatoirement un webmail ?

                                  Posté par . Évalué à 2.

                                  Hum.

                                  Tu confirmes bien qu’installer et maintenir un webmail, si on a pas déjà du web pour d’autres raisons, c’est la merde.

                                  Ce que moi j'appelle webmail, c'est l'application (web) elle-même, dans ce cas, roundcube. Si j'étais fan de l'IHM de roundcube, je pourrait l'installer sur ma machine physique pour taper des serveurs distants.
                                  Donc, non, ce n'est pas plus que ça la merde.

                                  Ce qui est merdique, dans mon appellation, c'est d'installer la pile logicielle permettant de faire tourner roundcube, que ce soit sécurisé pour un accès distant, et que l'anti-spam fonctionne correctement. C'est autrement plus compliqué, et le client mail n'est pas la cause principale de cette complexité.

                                  • [^] # Re: Pourquoi obligatoirement un webmail ?

                                    Posté par (page perso) . Évalué à 5.

                                    Ce qui est merdique, dans mon appellation, c'est d'installer la pile logicielle permettant de faire tourner roundcube

                                    Tu joues sur les mots et fais semblant de ne pas comprendre que c’est précisément ça son problème depuis le début du thread. Il n’a d’ailleurs pas cité roundcube précisément à la base, il dit juste administrer du webmail c’est chiant parce que ça fait administrer du web (critique en plus).

                                  • [^] # Re: Pourquoi obligatoirement un webmail ?

                                    Posté par (page perso) . Évalué à 1.

                                    Ce qui est merdique, dans mon appellation, c'est d'installer la pile logicielle permettant de faire tourner roundcube,

                                    Oui, donc au final c'est merdique d'installer Roudcube, sauf si on veut faire l'autruche sur la difficulté.
                                    Franchement, c'est facile d'installer x, suffit de dire "installe x" à haute voix, bon après c'est merdique d'installer l'humanoide qui va comprendre la tâche, mais ce n'est pas la la difficulté pour installer x, vraiment… Ou alors, si.

                                    • [^] # Re: Pourquoi obligatoirement un webmail ?

                                      Posté par (page perso) . Évalué à 1.

                                      ce n'est vraiment pas une distinction si idiote que ça….
                                      on parlait de maildrop plus haut, que je ne connaissais pas.
                                      je lái installé sur mon desktop, pour tester : apt-get install apache2, télécharger maildrop (clic-clic), le dezipper (clic-clic), le mettre dans /var/www (sudo mv) changer les permissions (chown -R). 2 commandes, 2 clics. et ça marche.

                                      je l'ai vraiment fait, pour mon usage de test personnel, pas pour prouver quelque chose. C'était très simple, c'etait utile, et j'aurais fait la même chose, tout aussi facilement avec roundcube, si je ne le connaissais pas déjà.

                                      Donc, je confirme, installer roundcube est très facile.
                                      Faire fonctionner un système public de mail, avec la sécurisation qui va bien et les moyens d'accés faciles et sécurisés qui vont avec, non(je l'ai fait aussi, longtemps).

                                      Mais ce n'est pas la même chose

                                      \Ö<

                          • [^] # Re: Pourquoi obligatoirement un webmail ?

                            Posté par (page perso) . Évalué à 1.

                            Je crois surtout que le problème est le suivant :
                            - d'un côté, Freem, qui installe Roundcube via un gestionnaire de paquet. La configuration par défaut est faite par les mainteneurs du paquet et va, je l'espère, avoir une configuration pas trop moche utilisable de suite. Par exemple, l'utilisation de SQLite par défaut est un choix de la distribution ;
                            - de l'autre, SaintGermain, qui a tenté une installation manuelle, avec des besoins spécifiques d'un point de vue sécurité, backup et compagnie.

                            Maintenant, est-ce que l'installation par défaut d'une distribution convient à tout le monde ? J'ai envie de dire non. Exemple, pour Freem, l'installation utilise par défaut SQLite. Ben je n'irai pas utiliser cela si l'environnement est "fortement" sollicité par de multiple utilisateurs.

                            Le backup, qui n'est qu'une opération de copie de fichier dans le cas de SQLite, peut ne pas être sans incidence. Pour un fichier de 8ko, on s'en fiche. Pour un fichier de 2Go, on repassera, car pendant le backup, la base est alors inaccessible en écriture (voir en lecture). Alors qu'un SGBD supporte aisément ce genre de chose.

                            Donc, oui, une installation "basique" est peut être simple avec une bonne distribution, mais une installation adaptée à un besoin particulier (de sécurité, de backup, etc…), ça demande de vraies compétences, et pas forcément que pour Roundcube mais pour les briques utilisées (notamment SGBD).

                            • [^] # Re: Pourquoi obligatoirement un webmail ?

                              Posté par . Évalué à 0.

                              Toutafé ;-)

                              Enfin je ne fais pas une installation tout à la main (compilation…). J'installe via le gestionnaire de paquets et ensuite je me retrousse les mains pour bien configurer.

                              Je considère (c'est mon avis seulement) que les emails c'est sacrément important et je ne me vois pas faire cela à la légère.

                              Pour d'autres choses (comme le partage avec Seafile), je pense que cela vaut clairement le coup de tenter l'aventure.

                              • [^] # Re: Pourquoi obligatoirement un webmail ?

                                Posté par (page perso) . Évalué à 2.

                                Tu veux utiliser un outil sans lire de doc… Je sais que certains trucs sont innés pour certains, mais bon, non un gestionnaire de base de donnée n'est pas simple sans lire de la doc (bien que pg_dump roundcube ou quelque chose comme ça n'est pas si compliqué). Même SQLite n'est pas simple pour faire un backup (un bon article de blog des créateurs de Geary explique les problèmes difficiles à gérer).

                                Ensuite, tu te cherches des ennuis pour rien : la base de donnée d'un client mail est quasiment inutile si tu utilises IMAP. Au pire si la base foire, tu la vides et le programme devrait la repeupler.

                                Pour HTTPS, il faut aussi lire un peu de doc (le chiffrage a besoin d'être un minimum compliquée, hé oui…). Mais créer des certificats autosignes est assez aisé et peu se faire. automatiquement, comme je l'ai vu pour Prodody.

                            • [^] # Re: Pourquoi obligatoirement un webmail ?

                              Posté par . Évalué à 2.

                              Maintenant, est-ce que l'installation par défaut d'une distribution convient à tout le monde ? J'ai envie de dire non. Exemple, pour Freem, l'installation utilise par défaut SQLite. Ben je n'irai pas utiliser cela si l'environnement est "fortement" sollicité par de multiple utilisateurs.

                              Fortement sollicité? Un auto-hébergement? La connexion ADSL ne tiendrait de toute façon pas, dans le cas d'un webmail fortement sollicité…

                              Non, mon problème viens du fait que SaintGermain accuse roundcube d'être complexe à installé, quand c'est en réalité les outils dont roundcube se base qui le sont.
                              Personnellement, je ne sais pas configurer HTTPS sur apache. Je ne sais pas non plus le faire avec nginx, ni yaws, ni tntnet (soft pris au hasard dans aptitude, dans la liste des paquets fournissant httpd). Pour autant, je ne serais pas surpris qu'apache soit celui avec lequel cette configuration serait la plus complexe. Les fois ou j'ai manipulé un serveur web, c'était apache parce que c'est lui qui est installé. J'en garde un très mauvais souvenir, du genre de ceux que j'ai quand j'affronte un système très complexe qui fait de nombreuses choses. Si je devais choisir un httpd, je pense que je regarderai très sérieusement la concurrence.

                              Un exemple plus parlant serait, par exemple, d'installer firefox sur une machine à accès public hautement sécurisée. Genre, chiffrement du disque, blocage de tous les accès réseau non désirés, interdiction d'accès aux systèmes de fichiers… et le tout en partant de LFS (bon, ok, ou en partant de Debian potato).
                              Parce que, oui, je considère personnellement que le «monde du web» est en retard de 10 ans sur le monde du logiciel local, que ce soit en terme de facilité pour faire une interface adaptable à l'écran du client qui tienne la route, ou en terme d'intégration (il n'y à pas, à ce que je sache, de système de paquets considérant le réseau comme étant le système, à ma connaissance, que ce soit archlinux, debian, red hat, freebsd, les systèmes de paquet considèrent la machine comme étant le système, ce qui dans le cas du web est faux, comme pour toute application basée sur le réseau).
                              Il à ses avantages et je ne le nierais jamais. Mais on oublie tellement souvent les multiples inconvénients du web…

                              Ça me rappelle l'époque ou j'accusais windows d'être responsable des crash des applications… l'époque ou j'écrivais windaube, micro$oft et ce genre de débilités. Avant de tester autre chose sérieusement, en somme. Et de constater que les mêmes logiciels plantaient au même moment sous un OS différent ;)

                              Il n'y à que pour l'IMAP et le SPAM que je ne sais pas si les reproches faits sont vraiment à cause de roundcube, ou à cause de la configuration du MTA. Ceci dit, dans le cas SPAM+IMAP, en général on à un dossier type spam-to-learn. Du coup, comme sur de l'IMAP les mails sont censés rester sur le serveur (je me trompe?) c'est de la responsabilité de l'anti-spam d'aller chercher le contenu de ce dossier pour classer de nouveaux spams. Mais dans le cas de POP3, je n'ai aucune idée de comment ça peut marcher, c'est un fait.

                              • [^] # Re: Pourquoi obligatoirement un webmail ?

                                Posté par (page perso) . Évalué à 2. Dernière modification le 09/02/15 à 12:25.

                                Fortement sollicité? Un auto-hébergement? La connexion ADSL ne tiendrait de toute façon pas, dans le cas d'un webmail fortement sollicité…

                                L'auto-hébergement, ce n'est pas que pour les particuliers hein ;) Et même en tant que particulier, j'ai eu la chance d'avoir une connexion fibre quand j'étais étudiant par exemple. Connexion 30/30. Ca poutre xD.

                                Mais par exemple, mon ancienne école d'ingénieur faisait de l'auto-hebergement. 4 promos + le personnel. Ca fait quelques milliers d'adresses. Chose intéressant, ils utilisaient Roundcube à un moment. Mais je ne sais pas la configuration !

                                Non, mon problème viens du fait que SaintGermain accuse roundcube d'être complexe à installé, quand c'est en réalité les outils dont roundcube se base qui le sont.

                                Non. Tu confonds installation/configuration. C'est le deuxième point sur lequel il s'attarde à dire que c'est compliqué, pas sur le premier. Tu dis d'ailleurs clairement que ce second point est celui qui pose problème avec ton exemple d'un firefox sécurisé ;)

                                En bref, vous êtes d'accords \o/

                                • [^] # Re: Pourquoi obligatoirement un webmail ?

                                  Posté par . Évalué à 2.

                                  L'auto-hébergement, ce n'est pas que pour les particuliers hein ;)

                                  Mais dans ce cas on paye un pro. Enfin, un type censé savoir faire du moins.

                                  En bref, vous êtes d'accords \o/

                                  C'est surtout sur le point de mettre sur le dos du webmail l'ensemble de la complexité de la pile permettant de gérer les mails que je ne suis pas d'accord. Pour le fait que les mails soient super complexes, oui, je suis d'accord: j'avais essayé à un moment de mettre mon nez dans ce genre de trucs, même en surface. J'en ai conclus que les gens qui font des outils user-friendly manipulant les mails sont doués. Ou alors je ne suis pas tombé sur les bons docs :)

                                  les outils dont roundcube se base

                                  ouch… s/dont/sur lesquels/g. Et c'est moi qui ait commis ça… mea culpa

                                  • [^] # Re: Pourquoi obligatoirement un webmail ?

                                    Posté par (page perso) . Évalué à 1.

                                    Mais dans ce cas on paye un pro. Enfin, un type censé savoir faire du moins.

                                    Tu serais surpris du nombre d'entreprise qui font de l'auto-hébergement ! Et u as mis le dois dessus sans même le savoir : on "paye". Un type qui s'y connais "un peu" va monter le service pour "pas grand chose". Si la PME est petite, c'est souvent une solution qu'elle va accepter si elle est un peu faible financièrement. Seulement voilà, généralement, la solution vaut des clous.

                                    C'est surtout sur le point de mettre sur le dos du webmail l'ensemble de la complexité de la pile permettant de gérer les mails que je ne suis pas d'accord.

                                    On a une interprétation différente de ses propos. Je ne l'ai pas ressenti ainsi. Bien au contraire !

                                    • [^] # Re: Pourquoi obligatoirement un webmail ?

                                      Posté par . Évalué à 2.

                                      Et u as mis le dois dessus sans même le savoir : on "paye".

                                      Nope, c'était volontaire. On paye. Et on à ce qu'on paye.
                                      De la merde si on paye des clous, à la première attaque, un truc solide comme le rock si on investit (oui, embaucher une personne est un investissement).
                                      D'ailleurs, je rirai de bonheur le jour ou un client que j'ai en tête se fera attaquer. Bon, faudra réparer les dégâts, mais je le ferai en mode triomphant, à la «je vous l'avais bien dit». Parce qu'on ne nous écoute pas quand on fait les Cassandre, on attend que ça pète, mode fuite en avant, et après on tombe des nues… sigh que ce soit niveau admin (ou j'y connais pas grand chose, mais je vois des failles) ou dev (du code… hum, dans un état assez triste, vraiment, ce serait drôle de faire un audit dessus) «tant que ça marche, on y va».
                                      Yay. Mais tu dois connaître, je pense (j'oubliai: je bosse pour une SSII pour le moment…).

                                      On a une interprétation différente de ses propos.

                                      Le problème de l'écrit.
                                      Je n'aurai pas réagit s'il avait parlé de la pile mail, parce que pour moi, un webmail est un logiciel isolé, juste un MUA, et non pas la pile complète qui est, clairement, hyper complexe. Surtout les mails, il faut dire ce qui est, c'est assez horrible, entre la flopée de protocoles POP3, IMAP4, SMTP, leurs déclinaisons sécurisées (et on double le nombre de protocoles, allez!) les options de sécurisations (on lance le SSL dès le début, on en fait pas, ou on le mets en milieu? What? Ouai, j'ai vu ce type d'options dans claws…), les spam (whitelist, blacklist, greylist?).
                                      Alors, tu ajoutes à ça un webmail.
                                      Du coup, il faut un serveur web. Mais du coup, la sécurité n'est pas intégrée au HTTP, qui est un protocole détourné jusqu'au foutu trognon: il n'à jamais été fait ni pour le chiffrement, ni pour supporter la notion d'état, de connexion. Alors on ajoute des cookies et du chiffrement. Supayr.
                                      Donc, on mets SSL. Ouf!

                                      Ouai, sauf qu'en fait, il y à plus simple que le SSL. Au début, on disait que mutt+ssh c'était mieux, plus simple? Alors pourquoi ne pas faire du tunneling HTTP over SSH? On enlève donc une couche de complexité (enfin, on prend ssh qui est aussi compliqué à configurer proprement, mais avec des config par défaut assez propre dans les distrib) pas vrai?

                      • [^] # Re: Pourquoi obligatoirement un webmail ?

                        Posté par (page perso) . Évalué à 2.

                        Donc (désolé si je me répète) dire que installer (et maintenir) Roundcube cela se résume à apt-get install Roundcube + apt-get upgrade de temps en temps et puis basta, c'est un peu exagéré

                        Non, ce n’est pas exagéré. Ce qui prend du temps c’est la configuration des mails, un webmail c’est rien de plus qu’une cerise sur le gâteau.

                        La preuve par l’exemple, sur un serveur avec postfix+dovecot :
                        http://almin.tf/blog/2010/11/27/roundcube-debian/

                        Apache, php et mysql viendront en dépendances et debconf (enfin, le paquet dbconfig-common) sait causer à un mysql, local ou distant. Je détaille ce qu’il faut pour le SSL.

                        Pour les mises à jour, apt-get update && apt-get upgrade, ou même cron-apt. Tiens faudrait que je fasse un billet sur cron-apt, c’est une bénédiction avec la multiplication des VE/VM.

                        Pour les sauvegardes, je ne vois aucun intérêt à gérer les DB à part, il faut de toutes façons sauvegarder tout le système pour ne pas se retaper la config si un dd lâche. Si on a juste besoin de la BD, tar xJf + chroot + mysqldump.

                        PS: j'ai failli me faire la config d'apache à la mano, mais j'ai eu la flemme, j'ai horreur de cette usine à gaz. C'est pour ça que j'ai préféré une recherche rapide finalement, et grand bien m'en a pris on dirait. D'ailleurs, cette version de roundcube à l'air plus léchée que celle que j'utilise. Je testerai peut-être plus en détails plus tard.

                        Faut arrêter avec le apache-bashing… Quand je n’ai pas une contrainte forte sur les performances (ce qui est typiquement le cas pour de l’auto-hébergement), je me cantonne à apache+mysql qui font ce qu’on leur demande et qui facile à déployer.

                        C’est la config la mieux supportée : ce couple sera toujours testé par les devs, c’est la plus répandue donc on trouve plein d’infos sur le net, et tous les paquets debian viennent préconfigurés pour ces deux-là. J’ai vu dbconfig-common faire des trucs bizarres avec postgres.

                        • [^] # Re: Pourquoi obligatoirement un webmail ?

                          Posté par . Évalué à 3.

                          Faut arrêter avec le apache-bashing…

                          Ça reste complexe pour ajouter un site. Enfin, pour quelqu'un dont le web n'est pas le métier (je suis développeur, mais pas dev web, et plus je peux éviter le web mieux je me porte, franchement).
                          D'ailleurs, j'ai appris un truc en testant: il s'avère que roundcube ne se mets pas dans /etc/apache2/sites-enabled. Il doit se mettre ailleurs, mais où, je n'en ai aucune idée.
                          Je ne dis pas que cette complexité n'est pas normale, je n'ai aucune foutue idée des fonctionnalités que c'est censé apporter.
                          Mais je pense que pour fournir un seul site web, apache est trop compliqué. C'est (probablement) un outil très puissant, utilisé dans des usages qui ne nécessitent pas la plupart de sa puissance, selon moi. Des situations ou je pense qu'un autre httpd serait probablement plus pertinent.

                          Pour ce qui est de mysql… honnêtement, je m'en tamponne. Personnellement, quand j'utilise un SGBDR, j'évite au maximum les procédures stockées (parfois pas le choix, ok, mais le moins il y à de PS le mieux je me porte!) pour rester sur des requêtes simples qui n'interrogent que mes schémas. Les calculs plus complexes je les fait dans le langage dans lequel l'application est vraiment écrite. Les SGBDR ne sont pas faits pour traiter les données, pour moi, mais uniquement pour les stocker.
                          Et comme les PS sont ce qui est le moins portable d'un SGBDR à l'autre… ça me permets d'avoir un truc plus agnostique.

                          • [^] # Re: Pourquoi obligatoirement un webmail ?

                            Posté par (page perso) . Évalué à 1.

                            Ça reste complexe pour ajouter un site.

                            Ça se passe de la même manière pour apache et nginx, il faut créer un nouveau fichier dans le bon répertoire :
                            /etc/apache2/sites-enabled/
                            /etc/nginx/sites-enabled/
                            Le plus simple étant de copier leur exemple de site par défaut et de l’adapter pour le nouveau site.

                            Apache bouffe plus de ram que d’autres serveurs httpd pour faire la même chose… mais tout dépend de la fréquentation du site, et comme tu le dis c’est la ligne adsl qui saturera avant apache, à moins d’avoir 32 Mo de ram sur le serveur ;)

                            Par contre, côté config je trouve que apache est toujours au-dessus du lot, parce qu’il est mieux supporté. Regarde l’exemple de roundcube, y’a apache et lighttpd : où est nginx ? Pour phpmyadmin idem, apache et lighttpd, et pas de nginx préconfiguré. Pour l’instant apache reste le choix qui simplifie la vie, mais ça va évoluer avec le temps car nginx monte de plus en plus.

                            D'ailleurs, j'ai appris un truc en testant: il s'avère que roundcube ne se mets pas dans /etc/apache2/sites-enabled. Il doit se mettre ailleurs, mais où, je n'en ai aucune idée.

                            Les paquets debian (roundcube, phpmyadmin, owncloud, etc) créent un lien symbolique dans /etc/apache2/conf.d/

                            Je ne dis pas que cette complexité n'est pas normale, je n'ai aucune foutue idée des fonctionnalités que c'est censé apporter. Mais je pense que pour fournir un seul site web, apache est trop compliqué. C'est (probablement) un outil très puissant, utilisé dans des usages qui ne nécessitent pas la plupart de sa puissance, selon moi. Des situations ou je pense qu'un autre httpd serait probablement plus pertinent.

                            Pour moi c’est l’inverse, mis à part une forte contrainte sur les perfs, je vois pas l’intérêt d’utiliser autre chose qu’apache. Après j’ai sans doute un biais parce que je le connais bien, en relisant mes notes d’installation pour apache je m’aperçois que ça fait 8 ans que je bosse avec ;)

                            • [^] # Re: Pourquoi obligatoirement un webmail ?

                              Posté par (page perso) . Évalué à 3.

                              Par contre, côté config je trouve que apache est toujours au-dessus du lot, parce qu’il est mieux supporté. Regarde l’exemple de roundcube, y’a apache et lighttpd : où est nginx ? Pour phpmyadmin idem, apache et lighttpd, et pas de nginx préconfiguré. Pour l’instant apache reste le choix qui simplifie la vie, mais ça va évoluer avec le temps car nginx monte de plus en plus.

                              Met-toi vite à la page si tu veux pas avoir de mauvaise surprise, parce que les projets web Apache first c'est les vieilleries (par exemple Roundcube dont son développeur lui-même dit que c'est un vieux truc mal conçu avec les techniques d'il y a 10 ans). Les trucs cools en Rails 4 genre gitlab c'est nginx ou crève, pour Apache faut aller chercher un exemple de config dans un dépôt tiers -contrib en espérant que le papi apachien la tient à jour.

                              • [^] # Re: Pourquoi obligatoirement un webmail ?

                                Posté par (page perso) . Évalué à 1.

                                Faut lire avant de répondre : j’ai précisé que c’est en fonction de la fréquentation du site, et que si la charge est conséquente il vaut mieux éviter apache.

                                Les trucs cools en Rails 4 genre gitlab

                                ahahahah, critiquer apache sur la facilité d’administration, et venir parler de ruby. De ruby quoi, le truc qui passe son temps à tout péter pour réinventer la roue… résultat faut souvent gérer les gems à la place de la distribution, d’ailleurs en fait la procédure standard c’est devenu installer les dépendances avec gem ou bundler, et parfois quand la stable debian, ou rhel, ou sles commence à dater, faut compiler tout le bazar depuis les sources. Sans doute l’un des pires choix pour la prod si ça doit être maintenu longtemps. Et l’empreinte mémoire de ruby a rien à envier à celle d’apache.

                                T’as pas honte ? t’aurais pu attendre vendredi :p

                                • [^] # Re: Pourquoi obligatoirement un webmail ?

                                  Posté par (page perso) . Évalué à 2.

                                  Faut lire avant de répondre : j’ai précisé que c’est en fonction de la fréquentation du site, et que si la charge est conséquente il vaut mieux éviter apache.

                                  Je vois pas le rapport avec ma réponse qui contredit (à tort ou à raison ; mais il faudrait peut-être répondre sur le sujet pour infirmer mon point de vue) l'idée qu'on trouve partout du Apache comme référence.

                                  [ruby c'est le bordel]

                                  Je vois toujours pas le rapport avec le fait que les projets web du 21ème siècle in en responsive design / flat design codés par des dev sous OSX qui viennent bosser en claquettes sur des standing desktop privilégient nginx parce qu'ils le trouvent plus cool et le préfèrent à Apache.

                                  En conséquence,

                                  Faut lire avant de répondre

                                  Je te retourne le conseil.

                                  • [^] # Re: Pourquoi obligatoirement un webmail ?

                                    Posté par (page perso) . Évalué à 0.

                                    Je vois pas le rapport avec ma réponse qui contredit (à tort ou à raison ; mais il faudrait peut-être répondre sur le sujet pour infirmer mon point de vue) l'idée qu'on trouve partout du Apache comme référence.

                                    Puisqu’on parlait de roundcube, pour son paquet dans la debian stable :

                                    Regarde l’exemple de roundcube, y’a apache et lighttpd : où est nginx ? Pour phpmyadmin idem, apache et lighttpd, et pas de nginx préconfiguré.

                                    Donc si tu as besoin d’un webmail simple pour une ou deux centaines d’utilisateurs, prendre la config par défaut avec apache te simplifie la vie. CQFD.

                                    Je vois toujours pas le rapport avec le fait que les projets web du 21ème siècle in en responsive design / flat design codés par des dev sous OSX qui viennent bosser en claquettes sur des standing desktop privilégient nginx parce qu'ils le trouvent plus cool et le préfèrent à Apache.

                                    Le fait que tu choisisses un exemple avec ruby, l’un des trucs les plus inmaintenables qui soient, ça démontre que tu as l’approche classique du dev qui ne s’occupe pas du déploiement et de la maintenance. Qui veut toujours la dernière version à la mode (le plus souvent pour se servir de 5% des nouveautés…), parce que c’est « in », parce que c’est « cool » (les deux termes sont de toi…). Sans comprendre que le bleeding edge ça n’a pas sa place sur un serveur.

                                    On était en train de causer sysadmin, et tu débarques avec une approche de codeur : pas étonnant qu’on se comprenne pas.

                            • [^] # Re: Pourquoi obligatoirement un webmail ?

                              Posté par . Évalué à 2.

                              Ça se passe de la même manière pour apache et nginx, il faut créer un nouveau fichier dans le bon répertoire :
                              /etc/apache2/sites-enabled/

                              Il semble que ce ne soit pas tout à fait ça, puisque, après l'isntall de roundcube, je n'avais rien de relatif dans ces dossiers. Ou alors j'ai raté un épisode, ça serait pas surprenant vu que je ne connais pas du tout le dev web, ni les outils qui y sont liés.

                              • [^] # Re: Pourquoi obligatoirement un webmail ?

                                Posté par (page perso) . Évalué à 0.

                                Il faut créer un fichier pour ton site dans /etc/apache2/sites-enabled/, et pour le reste :

                                D'ailleurs, j'ai appris un truc en testant: il s'avère que roundcube ne se mets pas dans /etc/apache2/sites-enabled. Il doit se mettre ailleurs, mais où, je n'en ai aucune idée.

                                Les paquets debian (roundcube, phpmyadmin, owncloud, etc) créent un lien symbolique dans /etc/apache2/conf.d/

                        • [^] # Re: Pourquoi obligatoirement un webmail ?

                          Posté par . Évalué à 3.

                          La preuve par l’exemple, sur un serveur avec postfix+dovecot :

                          Tu devrais reprendre ton article car l'utilisation que tu fais de sites-enabled n'est pas canonique. Toi tu crées ton fichier de conf directement dans sites-enabled alors que l'usage qui veut que dans sites-enabled ne se trouvent que des liens vers sites-available. Avantage, du actives ou desactives des vhosts avec un lien symbolique et quand tu supprimes un lien, tu ne perds pas la conf.

                          Pour les sauvegardes, je ne vois aucun intérêt à gérer les DB à part

                          Y en a un gros pourtant, c'est que ça permet d'utiliser le service pendant les sauvegardes. Si un des fichiers de base de mysql est modifié durant la sauvegarde, il y a un gros risque de corruption de données. Donc soit tu coupes mysql, soit tu lockes les bases. Dans les deux cas, le service est coupé.

                          • [^] # Re: Pourquoi obligatoirement un webmail ?

                            Posté par (page perso) . Évalué à 0.

                            tu crées ton fichier de conf directement dans sites-enabled alors que l'usage qui veut que dans sites-enabled ne se trouvent que des liens vers sites-available.

                            Perso je préfère déplacer un fichier de conf qui ne sert plus dans sites-available, plutôt que faire des liens symboliques. Mais dans le tutoriel je décrit la méthode classique et pas mes habitudes persos ;)

                            Si un des fichiers de base de mysql est modifié durant la sauvegarde, il y a un gros risque de corruption de données. Donc soit tu coupes mysql, soit tu lockes les bases.

                            Troisième option : faire les sauvegardes à une heure où on est certain que rien n’écrit dans la BD ;) Mais tu as raison, quand on ne peut pas être sûr, il faut faire un export.

    • [^] # Re: Pourquoi obligatoirement un webmail ?

      Posté par (page perso) . Évalué à 2.

      Choix personnel pour le coup. Tant que possible, j'utilise des applis web. Je n'ai pratiquement aucune application "lourde" sur mes clients, qu'ils soient PC, tablette ou smartphone.

    • [^] # Re: Pourquoi obligatoirement un webmail ?

      Posté par (page perso) . Évalué à 0.

      Je rajoute que le serveur postfix, il est bien là.

      Tu parle "des gens". Or dans le cas de l'auto-hébergement, on ne part pas du principe qu'on fourni un service à des gens externes, le webmail est fait pour notre usage à nous (la famille quoi).

      Et il se trouve que le webmail, et plus particulièrement celui de Zimbra dans notre cas, nous convient bien mieux que les clients "natifs" des systèmes qu'on utilise.

      • [^] # Re: Pourquoi obligatoirement un webmail ?

        Posté par . Évalué à 2.

        Eh bien je te tire mon chapeau : vos convictions sont suffisamment fortes pour accepter tous les efforts/inconvénients.

        Pour ma part c'est Fastmail, avec les inconvénients suivants :

        • un poil cher
        • risque d'espionnage/surveillance par l'état
        • [^] # Re: Pourquoi obligatoirement un webmail ?

          Posté par (page perso) . Évalué à -1.

          Quels sont les inconvénients et les efforts dont tu parle ?

          En effet, la mise en place est un peu pénible quand on fait tout soi-même. Mais une solution tout intégrée (postfix + dovecot/cyrus par exemple) a l'avantage d'éviter l'angoisse de l'édition des fichiers de configuration. Zimbra (et sans aucun doute les autre solutions mentionnées à l'exception peut être de Kolab) offre par ailleurs une interface d'administration facile à prendre en main.

          Enfin, à l'usage, le webmail et ses autres composants (calendriers, contacts, etc.) est aussi très facile à utiliser et offre tout sous la main. Bien sûr, les clients "lourds" offrent aussi ces fonctionnalités, mais je ne crois pas qu'il y ait tant "d'efforts/inconvénients" à gérer soi même son serveur mail :)

          • [^] # Re: Pourquoi obligatoirement un webmail ?

            Posté par . Évalué à 2.

            Inconvénients : quoi que tu fasses, tu vas perdre en fonctionnalités par rapport à Gmail ou Fastmail (tu en auras peut-être quelques unes en plus, mais ils en auront beaucoup plus que tu n'auras pas).

            Exemple :

            • Performance
            • Backup
            • Redondance en cas de panne
            • Push email

            Ensuite au niveau des efforts, tu as l'installation et la maintenance au quotidien. On ne me fera pas croire qu'un serveur ça se gère les doigts dans le nez au quotidien sans faire un minimum attention (surveillance des logs) et d'interventions (certificats SSL troués à changer…).

            Au final pour ma part cela s'est résumé à cela : est-ce que le risque de surveillance par l'état est pertinent pour mon cas personnel ? Non. Donc pour 20 euros par an je m'embête pas et prends Fastmail.

            • [^] # Re: Pourquoi obligatoirement un webmail ?

              Posté par (page perso) . Évalué à 7.

              tu en auras peut-être quelques unes en plus, mais ils en auront beaucoup plus que tu n'auras pas).

              En fait, ça va surtout dépendre du coefficient que tu vas mettre pour les fonctionnalités "c'est libre" (Fastmail 0, Rainloop 0, Roudcube 1) et "je peux hacker" (Fastmail 0, Rainloop 1, Roudcube 1) et je m'emmerde pas (Fastmail 1, Rainloop 0, Roudcube 0) et plein d'autre suivant ta grille toi, suivant les coefficients mis le choix change.

              Fastmail peut être gagnant, ou dernier, suivant les coefficient de ta grille, ce n'est pas à coup sûr le premier "pour 20 euros par an je m'embête pas".

              • [^] # Re: Pourquoi obligatoirement un webmail ?

                Posté par . Évalué à 1.

                Euh je ne sais pas si être "libre" peut être considéré comme une fonctionnalité, c'est intéressant comme question.
                Parce que si personne ne code derrière, tu n'en auras pas beaucoup de réelles fonctionnalités ;-)
                Je voyais plutôt cela comme une propriété ou une contrainte que tu n'as pas.

                Mais bon j'ai compris le fond de ton message et oui il faut peser les patates avant de faire son choix.

                J'ai bien insisté sur le fait que ma décision était un choix personnel. Cependant je maintiens que Gmail ou Fastmail offrent bien plus de fonctionnalités et que le choix se fait surtout sur des critères de conviction ou idéologiques (et il n'y a absolument aucun mal à mettre un poids prépondérant à ces critères).

                • [^] # Re: Pourquoi obligatoirement un webmail ?

                  Posté par (page perso) . Évalué à 3. Dernière modification le 05/02/15 à 21:20.

                  Euh je ne sais pas si être "libre" peut être considéré comme une fonctionnalité,

                  Perso, ça l'est : on peut traduire ça par "capacité à demander à un tiers de reprendre en main le bousin si l'upstream merde". C'est optionel (il faut payer), mais c'est une fonctionalité.
                  Perso, cette fonctionnalité a pas loin de 50% des coefficients chez moi (pour d'autres c'est 0%, et pour encore d'autres c'est éliminatoire).

                  J'ai bien insisté sur le fait que ma décision était un choix personnel.

                  Je n'ai aucunement remis en cause ton choix personnel, qui est tout à ton honneur (tant que tu dis pas "c'est libre", comme j'ai pu lire sur Rainloop plusieurs fois par exemple, si encore on disait "open source" car oui j'ai déjà vu pas mal de monde dire que le NC est open source)

                  Cependant je maintiens que Gmail ou Fastmail offrent bien plus de fonctionnalités

                  Ca dépend ce que tu cherches : quand on a la fonctionnalité "je peux hacker le code", ça permet d'inventer des miliers de fonctionnalités derrière. La où je ne suis pas d'accord avec toi, c'est sur ton "ça offre plus". Non, ça n'offre pas plus; ça offre des choses différentes.

                  que le choix se fait surtout sur des critères de conviction ou idéologiques

                  Ben justement, non : ce n'est pas de la conviction ou de l'idéologie, c'est de la fonctionnalité, purement technique.
                  Disclaimer : je suis plus proche de l'OSI que de la FSF (j'en suis même très éloigné de ceux-la) quand à mon appréciation du libre.

                  • [^] # Re: Pourquoi obligatoirement un webmail ?

                    Posté par . Évalué à 1.

                    Ah pinaise on se croirait au boulot où les gens se battent sur ce qui définit une "exigence fonctionnelle" ou une "exigence non fonctionnelle" ou une "contrainte" ! ;-)

                    Il nous faut un expert en "requirements management", celui-là il pourra nous trancher la question rapidement et sans bavure.

                    Mais j'ai compris ton argumentation, pas de soucis.

                    • [^] # Re: Pourquoi obligatoirement un webmail ?

                      Posté par (page perso) . Évalué à 2.

                      Ah pinaise on se croirait au boulot

                      Je crois que je me suis fait capté…
                      Un exigence est une exigence, pas de séparation, c'est plus simple! :)
                      Et le libre répond à l'éxigence : évolutivité.

                  • [^] # Re: Pourquoi obligatoirement un webmail ?

                    Posté par . Évalué à 2.

                    si encore on disait "open source" car oui j'ai déjà vu pas mal de monde dire que le NC est open source

                    Là-dessus, j'ai deux approches selon la langue. En anglais, je veux bien admettre que "open source" puisse se référer à un code source "ouvert" (lisible, par exemple) dans un contexte autre que l'Open Source avec des majuscules et des barbus. Par contre, en français, je ne vois aucune ambiguïté : on parlerait de logiciel à source ouvert pour un NC que ça ne me choquerait pas, mais le terme "open source" repris tel quel de l'anglais a un sens connoté assez fort.

                    Bon, après, ça n'est pas une position officielle (ni officieuse d'ailleurs, j'ai pas l'age) de la Cadémie.

                    • [^] # Re: Pourquoi obligatoirement un webmail ?

                      Posté par . Évalué à -4.

                      Mouai. Perso, open source, en anglais ça veut dire qu'on à accès au code source. Et en français, ça veut rien dire, juste rien dire. Alors si j'intègre open source dans une phrase, c'est le terme anglais, le seul qui ait une signification réelle en dehors des élucubrations des drosophiles.

                      Ok, je veux bien que l'on dise NC => pas libre. C'est un fait, vu il y à une contrainte. Sauf que dans ce cas, techniquement, GPL => pas libre (ouai, y'a une contrainte, celle d'ouvrir un code qui inclue du code GPL).
                      Le reste, les théories sur la liberté, la garantie de la liberté et compagnie, c'est de la philo-politique, beaucoup de blabla pour détourner le sens d'un mot pourtant simple: libre, absence de contraintes.
                      Je ne parlerais pas des licences libre de documentation avec morceaux de texte non modifiables…

                      Oh, dernière chose. Je sais ce que sont les 4 libertés définissant un logiciel GNU/Libre, et je n'ai rien contre. Même, je les aime bien. Mais dans ce cas, on parle de free software, pas d'open source (pas de majuscules => pas des noms propres donc pas de sens customisé).

                      • [^] # Re: Pourquoi obligatoirement un webmail ?

                        Posté par . Évalué à 3.

                        on parle de free software, pas d'open source (pas de majuscules => pas des noms propres donc pas de sens customisé).

                        Sauf que l'open source a aussi un sens "customisé", cf. OSI. L'absence de majuscules, il me semble que tu la tolères bien sur "free software", non?

  • # Piwigo

    Posté par (page perso) . Évalué à 6.

    Pour l'hébergement de photos, si Gallery t'avais plu tu aimeras sans doute Piwigo. Sinon, l'application de galerie photos de OwnCloud est assez basique mais pas mal aussi.

    • [^] # Re: Piwigo

      Posté par (page perso) . Évalué à 2.

      Je n'ai malheureusement pas été convaincu par Piwigo pour l'usage que je souhaite faire, mais je me trompe peut être. Je ne l'ai testé que superficiellement.

      Par exemple, pas vu de gestion de LDAP, et je crois qu'il n'est pas possible d'utiliser une arborescence située en dehors du serveur web. Je classe mes photos par année, puis par mois puis par jour dans mon système de fichiers. Je ne tiens pas à devoir créer d'autres dossiers "virtuels" dans l'appli qui gère mes photos, alors que tout est déjà classé comme je le souhaite.

      • [^] # Re: Piwigo

        Posté par (page perso) . Évalué à 4.

        Pour le LDAP, il y a un plugin : http://piwigo.org/ext/extension_view.php?eid=650
        (plus l'air d'être maintenu par contre, mauvaise nouvelle).

        Pour la manière de gérer l'arborescence, ce que tu décris ressemble pas mal aux « albums physiques » de Piwigo : http://piwigo.org/doc/doku.php?id=user_documentation:albums_management
        (je n'ai jamais utilisé Piwigo comme ça). Par contre, une contrainte qui ne sera pas forcément acceptable pour toi : Piwigo considère les images comme des fichiers servis statiquement par le serveur web, donc je ne crois pas que tu puisses avoir tes photos en dehors de l'arborescence du serveur web, et si tu veux une gestion correcte des permissions ça ne marchera probablement pas. Pour les albums virtuels, c'est différent vu que les URL sont générées aléatoirement au moment de l'upload => la sécurité est assuré par le fait que les URLs ne sont pas devinables.

        Une autre option, c'est d'avoir ton arborescence de travail quelque part, et de synchroniser régulièrement vers ta galerie avec quelque chose comme http://piwigo.org/doc/doku.php?id=user_documentation:tools:piwigo_import_tree .

        Je ne suis pas non plus 100% convaincu par Piwigo, mais dans la catégorie « outil libre, avec plein de fonctionnalités, bien maintenu et avec une grosse communauté », il est à peu près le seul.

        Par contre, j'ai l'impression que owncloud ferait vraiment tout ce que tu veux.

        • [^] # Re: Piwigo

          Posté par (page perso) . Évalué à 1.

          Pour piwigo, c'est effectivement l'abandon du plugin LDAP qui m'a chiffonné. Par ailleurs, tu décris mieux que moi ce que je cherche à faire (albums physiques). Du coup, synchroniser deux répertoires… A la limite, un mount -o bind pour éviter la dupplication mais c'est sale…

          Pour owncloud (que j'utilise), en effet ça fait mieux que ce que j'ai vu jusqu'à maintenant et je pense que je vais rester là dessus, mais si j'ai tendance à me plaindre de sa relative lenteur…

  • # Pourquoi toujours le cas du mail ?

    Posté par . Évalué à 10. Dernière modification le 05/02/15 à 18:06.

    On va sans doute me prendre pour un gros trolleur mais le cas du mail c'est toujours le premier cas qu'on sort pour l'auto-hébergement alors que c'est sans doute le moins utile/pratique/réalisable.

    Parce que déjà la plupart de tes contacts ne font pas de GPG et sont sur gmail, donc niveau vie privé toussa on repassera, tes communications mails sortirons forcément de ton serveur auto-hébergé. Et de deux le mail c'est juste horrible à administrer, entre les whitelist/greylist/backlist, les anti-spam à configurer et le fait que du jour au lendemain tu peux te retrouver dans un liste de spam type spamhaus et consort à cause d'un faux positif. C'est juste le service à la con dont je laisse l'administration à d'autres. C'est rigolo de monté un serveur postfix en prototype, le gérer au quotidien c'est l'enfer.

    Par contre des services d'échanges de photos/fichier avec mes proches la ça peut avoir un sens de faire de l'auto-hébergement. (Bien que ça empêche pas qu'un amis les repose sur facedebook)

    Voila mes 10 cents, éviter de parler de mail lorsque vous parler d'auto-hébergement ça désert la cause je trouve.

    • [^] # Re: Pourquoi toujours le cas du mail ?

      Posté par (page perso) . Évalué à 6.

      Parce que déjà la plupart de tes contacts ne font pas de GPG et sont sur gmail, donc niveau vie privé toussa on repassera, tes communications mails sortirons forcément de ton serveur auto-hébergé.

      Il faut bien commencer par quelque part, montrer l'exemple.

      C'est rigolo de monté un serveur postfix en prototype, le gérer au quotidien c'est l'enfer.

      Certes la configuration initiale est galère, mais une fois que c'est fait ça roule tout seul. Et c'est d'autant plus facile avec des solutions comme YunoHost et bientôt OwnCloud.

      • [^] # Re: Pourquoi toujours le cas du mail ?

        Posté par . Évalué à 2.

        Parce que déjà la plupart de tes contacts ne font pas de GPG et sont sur gmail, donc niveau vie privé toussa on repassera, tes communications mails sortirons forcément de ton serveur auto-hébergé.

        Il faut bien commencer par quelque part, montrer l'exemple.

        Rien n'empêche d'utiliser un client lourd IMAP (e.g. thunderbird) avec un compte sous GMail (ou autre provider IMAP). Ce n'est pas parfait, mais ça permet de faire du chiffrement sans avoir les emmerdements d'un mail totalement auto-hébergé.

    • [^] # Re: Pourquoi toujours le cas du mail ?

      Posté par . Évalué à -1.

      Tout à fait d'accord. J'ai installé mon propre Postfix pour apprendre et Ok c'est sympa et ça marche mais pour quelque chose d'aussi important que ses emails, je préfère confier cela à des professionnels (Fastmail pour ma part).

      Après le problème c'est de trouver un bon prestataire et les histoires d'espionnage/surveillance : c'est un autre débat et je ne souhaite pas rentrer dedans ici.

      Par contre à partir d'un certain nombre de personnes cela prend plus de sens car tu amortis très vite un serveur Postfix (le travail est sensiblement le même pour 1 personne ou 100 personnes).

      • [^] # Re: Pourquoi toujours le cas du mail ?

        Posté par . Évalué à 1.

        c'est un autre débat et je ne souhaite pas rentrer dedans ici.

        Parce-que si tu rentrais dedans, tu changerais d'avis ?

        • [^] # Re: Pourquoi toujours le cas du mail ?

          Posté par (page perso) . Évalué à 2.

          Parce qu'il s'en fout et ne souhaite pas rameter la troupe de gens qui hurlent et qu'il a déjà entendu sans que ça le fasse changer d'avis (chacun son truc et voila).

          • [^] # Re: Pourquoi toujours le cas du mail ?

            Posté par . Évalué à 1.

            Tout à fait.

            Les histoires d'espionnage/surveillance : c'est un sujet qui a été débattu pleins de fois. Je ne sais pas si il y a quelqu'un par ici qui souhaite remettre le sujet sur le tapis.

            Le choix du prestataire : pareil on va tourner en rond. Mais à la limite cela on peut en parler dans un autre journal ou dans le forum, car on ne parle pas trop de Fastmail par ici et je trouve qu'ils font du bon boulot. J'ai juste peur que cela dégénère sur "Gmail/Google c'est evil".

    • [^] # Re: Pourquoi toujours le cas du mail ?

      Posté par (page perso) . Évalué à 2.

      C'est rigolo de monté un serveur postfix en prototype, le gérer au quotidien c'est l'enfer.

      Pour du perso, non ça va. On limite les risques de blacklisting en passant par le smarthost de son FAI.

    • [^] # Re: Pourquoi toujours le cas du mail ?

      Posté par (page perso) . Évalué à 6.

      Et de deux le mail c'est juste horrible à administrer, entre les whitelist/greylist/backlist, les anti-spam à configurer et le fait que du jour au lendemain tu peux te retrouver dans un liste de spam type spamhaus et consort à cause d'un faux positif.

      Perso, j'ai jamais eu aucun problème avec le mail : d'abord avec postfix, maintenant avec OpenSMTPD (conf d'une dizaine de lignes qui n'a jamais changé). Je fais rien pour le spam (j'en reçois vraiment très rarement), et je n'ai pas l'impression d'avoir été blacklisté nulle part jusqu'à présent. Je me demande si j'ai juste eu beaucoup de chance jusqu'à présent (plus de deux ans), ou si c'est qu'il y a moins de spam ces dernières années, mais le mail c'est vraiment pas ce qui me cause le plus de soucis.

      • [^] # Re: Pourquoi toujours le cas du mail ?

        Posté par (page perso) . Évalué à 1.

        Tout dépend de l'usage que tu as du mail et surtout de l'ancienneté de ton domaine..

        Personnellement, j'hoste mes mails depuis 2003 (le premier qui me traite de vieux, je lui casse la bouche à coup de canne!) et même avec de bonnes habitudes (utilisation d'alias pour les sites de faible confiance, etc…) je reçois de plus en plus de spam.
        Plus le domaine est ancien, plus la probabilité de le voir être pris pour cible des spammeurs augmente…

      • [^] # Re: Pourquoi toujours le cas du mail ?

        Posté par (page perso) . Évalué à 2. Dernière modification le 06/02/15 à 21:09.

        Pareil, auto-hébergé depuis une dizaine d'années maintenant, d'abord avec un serveur à la maison sur l'adsl de free, puis en louant une machine personnelle chez un hébergeur, aujourd'hui avec une kimsufi chez OVH.

        Je n'ai jamais eu de soucis avec le mail pour une raison simple: désactiver le relai smtp et mettre à jour son serveur en temps régulièrement. Pour le reste, suivre les tutoriels qui pullulent, et du bon sens, comme ne pas installer n'imp sur son serveur de prod.

        C'est sûr que maintenant je commence à m'y connaitre un peu mais j'applique les même règles simples depuis le début en ce qui concerne la sécurité, et je n'ai jamais eu à me plaindre. (des petits soucis parfois, des tentatives d'attaque par des bots principalement, mais -je touche du bois- rien de grave jusqu'à présent).

        Pour le spam, je ne peux pas empêcher d'en recevoir, néanmoins limiter la diffusion de son adresse mail sur le web public, greylist postfix+spamassassin font que j'en recois peu.
        Peu comparativement à une époque où j'en recevais genre 50 par jour, là c'est plus une dizaine max par semaine, et très peu de faux positif par spamassassin. Le greylisting pour mon utilisation a été la meilleure façon de limiter le spam.

    • [^] # Re: Pourquoi toujours le cas du mail ?

      Posté par (page perso) . Évalué à -1.

      le fait que du jour au lendemain tu peux te retrouver dans un liste de spam type spamhaus et consort à cause d'un faux positif

      Alors ça, en 13 ans d'hébergement de mes mails, ça ne m'est JAMAIS arrivé.

      Si tu finis sur spamhaus, c'est toujours que t'as chié à un moment et que ton MTA était configuré en Open Relay OU qu'on t'a volé tes identifiants et qu'un spammeur s'en sert pour tenter de vendre du viagra à la planète.

      D'ailleurs, je vois pas trop ce que pourrait être un faux positif en fait …

      • [^] # Re: Pourquoi toujours le cas du mail ?

        Posté par . Évalué à 1. Dernière modification le 07/02/15 à 13:36.

        À mes tous débuts d'auto-hébergement, il y a une dizaine d'années, j'ai été blacklisté au bout de six-huit mois : j'avais installé Squid sans identification d'aucune sorte, du coup des petits malins s'en étaient servis comme d'un relais. Encore maintenant, j'ai un peu honte. ^

  • # Synology et chiffrement de volume

    Posté par (page perso) . Évalué à 3.

    Parler de NAS Synology et de sécurité me fait penser que le gros manque de ces machins là, c'est l'absence de possibilité de chiffrement à l'échelle du volume. On peut juste chiffrer des dossiers.

    Prochainement, je vous proposerai peut-être un commentaire constructif.

  • # distribution ?

    Posté par . Évalué à 2.

    On en sont les distributions sur ce genre d'application ? Je n'ai jamais compris pourquoi les applications web était souvent livré "à poil", voir pas du tout, dans les distributions linux. Pourquoi n'ont-elles pas le même statut que les applications classiques ? C'est si difficile de faire des paquets de configuration pour qu'un ensemble de logiciel marche ensemble ?

    "La première sécurité est la liberté"

    • [^] # Re: distribution ?

      Posté par . Évalué à 2.

      Bah écoutes, on dirait bien que roundcube et squirrelmail sont dans le répo debian. Jamais testé de les installer (notamment parce que l'idée de config un serveur mail et de comprendre ce que je fait me parait bien pénible), mais elles sont bien là.

      J'ai déjà installé redmine depuis les même dépôts (bon, ok, le backports) et ça s'est passé relativement aisément, même si ça pourrait être amélioré.

      Mais pour répondre à ta question, le problème à mon avis est que les distributions voient un système comme étant une machine, virtuelle ou physique. Pas comme s'il s'agissait d'un réseau, du coup aucun système de paquet que je connaisse ne gère les interactions entre plusieurs machines. Hors, dans le cas des applications web, il arrive amha fréquemment que la base de données ne soit pas sur la même machine que le frontal. Du coup, ça me semble impossible de régler ce problème de façon propre.
      En gros, pour moi, les systèmes de paquets que je connais ne sont pas adaptés au «monde moderne» ou le réseau est prédominant (mais ils sont très bons pour maintenir un système autonome, ça me semble évident).

      • [^] # Re: distribution ?

        Posté par . Évalué à 2.

        Par défaut, ils pourraient faire des paquets "propres" pour un usage local, ensuite n'importe qu'elle administrateur pourrait changer la configuration. Cela rendrait au moins l'auto-hébergement plus facile.

        Lors que Mandrake avait sorti la "clic", une distrib pour cluster, il avait rendu rpmi distribuable sur un cluster, en utilisant un outil de copy p2p rapide. Ce genre d'outil aurait largement pu servir à la gestion d'un parc de machine.

        "La première sécurité est la liberté"

        • [^] # Re: distribution ?

          Posté par . Évalué à 3.

          Je viens de tester.

          Franchement, l'install de roundcube est enfantine sous Debian, resterait juste à config pour virer le choix du serveur sur la page d'accueil, mais je doute que ce soit complexe.
          Honnêtement, j'ai eu l'impression d'installer claws, ou un truc du même genre. J'aurai du tester plus tôt, j'aurai peut-être pu raccourcir certains threads sur ce sujet.

          Ça semble même relativement simple à installer/activer avec autre chose qu'apache, en tout cas, c'est le contenu de /etc/roundcube qui me fait dire ça:

          /etc/roundcube# ls
          apache.conf  db.inc.php  debian-db.php  htaccess  lighttpd.conf  main.inc.php  mimetypes.php  plugins
          

          Vu comment ce fut… difficile… d'activer roundcube sur apache (dé-commenter 2 lignes dans l'apache.conf de ce dossier, pour ajouter un alias a apache. Ce sont les 3ème et 4ème lignes du fichier, les deux lignes précédentes indiquant qu'il faut les dé-commenter ou adapter les 2 autres. Dans la tradition Debian quoi: simple et efficace) j'aurai du faire le test plus tôt: ça aurait peut-être raccourcis certains threads.

          • [^] # Re: distribution ?

            Posté par . Évalué à 3.

            J'aurai du tester plus tôt, j'aurai peut-être pu raccourcir certains threads sur ce sujet.

            Puis

            j'aurai du faire le test plus tôt: ça aurait peut-être raccourcis certains threads

            ça dépend, si tu répètes tout deux fois, ça risque de les rallonger ;-)

  • # Édition des informations personnelles : FusionDirectory

    Posté par (page perso) . Évalué à 4.

    Suite à un commentaire de NeoX, j'utilise désormais SSP. C'est parfait pour changer son mot de passe, mais quid des autres informations personnelles ? On pourrait par exemple supposer que certains utilisateurs préfèreraient un shell différent de celui attribué par défaut, ou la possibilité de changer son avatar, son téléphone, son adresse, etc. Je n'ai pas pu trouver une telle application.
    Il y a bien MDS qui offre ces fonctionnalités, mais apparemment ne supporte pas les champs LDAP SambaNTPassword et SambaLMPassword, qui évitent notamment une manipulation dans le registre des clients Windows relative au chiffrement des mots de passe.

    Pour ça tu peux utiliser FusionDirectory, quitte à utiliser un LDAP, autant faire les choses bien.
    En installation nue sans plugin FD contient quasi-uniquement la gestion utilisateurs, en installant le plugin Samba et en donnant aux utilisateurs le droits sur leur infos, ça devrait répondre à tes besoins. (Et comme ça si tu veux mettre ta configuration posix et compagnie dans ton annuaire tu peux profiter des autres plugins FD)

  • # squirrelmail versus la mode du full JS

    Posté par . Évalué à 5.

    «Squirrelmail n'est pratiquement plus utilisable aujourd'hui, » «Dans le cas du premier, l'austérité de son interface rebute les nouveaux utilisateurs,»

    N'importe quoi.
    Cet outil ne s'adresse pas à tout le monde, c'est vrai, mais de la à le qualifier d'inutilisable… franchement, quand tu as une connexion qui merde sévère ( réseau d'école ou hôtel formule 1 avec wifi, pour des cas tirés de la vie réelle. Peut-être aussi que la 3G est concernée, je ne sais pas ) l'absence de dynamisme (pas de javascript nécessaire) de squirrelmail est un véritable atout. Dans ces moments là, roundcube est strictement inexploitable, tandis que squirrel est juste un poil long, mais fonctionne.

    Ça lui permets aussi d'être fonctionnel sur n'importe quelle machine, oui, y compris le vieux coucou de mémé michu qui n'à pas été mis à jour depuis 95, ou une machine sans serveur graphique. Je me demande si roundcube est accessible «sans les yeux», tiens? Et squirrelmail?

    Je ne parle même pas des 4cm de hauteur gâchés par l'interface de roundcube, ni du fait que si il refresh (la version déployée sur mon mail en tout cas) alors que tu es en train de sélectionner des mails pour les virer, tu perds ta sélection…
    Bref, niveau utilisabilité, je trouve que squirrelmail est, certes, pauvre en fonctionnalités, mais au moins il réagit au doigt et à l'œil, sans jamais surprendre son utilisateur.

    • [^] # Re: squirrelmail versus la mode du full JS

      Posté par (page perso) . Évalué à 3.

      l'absence de dynamisme (pas de javascript nécessaire) de squirrelmail est un véritable atout. Dans ces moments là, roundcube est strictement inexploitable, tandis que squirrel est juste un poil long, mais fonctionne.

      Oui je suis parfaitement convaincu que recharger la page entière pour faire le moindre truc met moins de pression sur la mauvaise connexion qu'un appel Ajax.

      Avec cette logique, t'as essayé de lancer un Thunderbird sur le serveur en export display ? Y aura encore moins d'Ajax, ça devrait encore mieux marcher.

      • [^] # Re: squirrelmail versus la mode du full JS

        Posté par . Évalué à 0.

        Je doute qu'il y ait "encore moins d'Ajax" que pour squirrel, puisque squirrel n'en à pas, d'Ajax ;)
        L'HTTP+HTML, par contre, ok ;)

        Pour l'export display… tu veux dire, un Xorg accédé à distance? Dans ce cas, je pense que ce serait plus lourd que de l'HTML (données graphique, ouch!). Accessoirement, installer un Xorg sur un serveur est un truc qui m'intrigue: personnellement, sur une machine que je veux stable, j'essaie d'installer le moins de choses possibles, pour réduire les risques de bugs et avoir un comportement le plus prévisible possible.
        De toute façon, je ne m'auto-héberge pas, donc je n'ai pas la main sur ce serveur, du coup pour installer des trucs… mal parti.

    • [^] # Re: squirrelmail versus la mode du full JS

      Posté par . Évalué à 3.

      Cet outil ne s'adresse pas à tout le monde, c'est vrai, mais de la à le qualifier d'inutilisable… franchement, quand tu as une connexion qui merde sévère ( réseau d'école ou hôtel formule 1 avec wifi, pour des cas tirés de la vie réelle. Peut-être aussi que la 3G est concernée, je ne sais pas ) l'absence de dynamisme (pas de javascript nécessaire) de squirrelmail est un véritable atout. Dans ces moments là, roundcube est strictement inexploitable, tandis que squirrel est juste un poil long, mais fonctionne.

      Je ne connais pas ces logiciels, mais :

      • l'exécution du js coté client ne dépend pas du réseau
      • le js est conçu par design pour être asynchrone donc il doit permettre de coller totalement à la performance du réseau

      Ton ressenti vient peut être de du fait qu'il vaut mieux faire un gros téléchargement que plusieurs petits lorsque le réseau a une forte latence. Ça peut être bien être pris en compte.

      Ça lui permets aussi d'être fonctionnel sur n'importe quelle machine, oui, y compris le vieux coucou de mémé michu qui n'à pas été mis à jour depuis 95, ou une machine sans serveur graphique. Je me demande si roundcube est accessible «sans les yeux», tiens? Et squirrelmail?

      Et est-ce que l'un ou l'autre est utilisable la tête en bas ?
      Et avec une main dans le dos ?
      Le quel est capable de sauter à cloche pied ?

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: squirrelmail versus la mode du full JS

        Posté par . Évalué à 2.

        l'exécution du js coté client ne dépend pas du réseau

        Nope, mais le fait de multiplier les requêtes http pour récupérer de petits éléments augmente la charge réseau. Et je ne sais pas comment c'est foutu dans roundcube, mais le fait est que je me retrouvais avec l'interface principale chargée et affichée, mais toutes les données dynamiques récupérées par AJAX n'étaient pas là. Autrement dit: inutilisable. Alors qu'en passant par squirrelmail, certes c'était long pour afficher un mail, parfois de l'ordre de la minute (et sans les images hein, j'affiche que du texte dans mes mail moi) mais au moins, ça marchait.

  • # Deux choses me laissent perplexe

    Posté par (page perso) . Évalué à 7.

    L'auto-hébergement comme son nom l'indique consiste à héberger soi-même les services que l'on confie généralement à des tiers "privateurs" de liberté.

    Est il nécessaire, dans ce cas, de faire la distinction entre "logiciel pour l'auto-hébergement" et "logiciel" (tout court) ?
    Que le service soit hébergé sur un serveur dans ton salon, sur un serveur dédié racké dans un datacenter ou encore sur une VM d'un gros serveur à <inserer ici le nom de ton hébergeur favori> change t il quoi que ce soit au fonctionnement de ce service ? A mon sens non.
    De la même façon, les hébergeurs qui s'appuient sur des softs libres pour proposer un service privateur utilisent les même logiciels que toi et moi… sans pour autant faire de l'auto-hébergement ;-)

    Pour être plus juste, il faudrait plutôt parler de pénurie d'applicatifs "serveurs" libres que d'applicatifs "pour l'auto-hébergement".

    Un autre point me fait sourire, tu évoques la simplicité dans le processus d'hébergement.
    L'administration système est un métier et "simplifier" ce dernier représente pour moi un risque non négligeable.
    Si demain Mme Michu est capable de déployer un serveur pour l'auto-hébergement sur son petit PC, quid du jour ou une énorme faille de sécurité vient toucher la configuration "par défaut" d'un service ? Quid du jour ou, pour une obscure raison, le MTA du serveur se vautre et ne se relance pas ? Ce jour là, les belles idées de l'auto-hébergement qui est plus fiable et plus sécurisé que google et ses amis voleront en éclat.
    Certes, aujourd'hui, les gens qui se lancent dans l'auto-hébergement ont une bonne culture de l'informatique et peuvent généralement faire face à 90% des problèmes rencontrés … mais mon expérience dans l'administration système me pousse à croire que les 10% restants, les problèmes réellement velus (le genre de problème où il faut strac-er le process pour voir qu'il se vautre à tel endroit), peuvent amener au mieux un bon gros mal de tête et au pire la perte de quelques mails "importants".
    Niveau "sécurité", on repassera …

    Pour résumer, j'ai l'impression que dans ton journal, tu demandes un peu tout et son contraire: simplicité d'un côté, exhaustivité des fonctions proposées de l'autre.
    A mes yeux, simplicité et exhaustivité sont tout bonnement incompatibles aujourd'hui…

    Allé, j'ai envie de lancer un petit sondage aux amateurs d'auto-hébergement qui tiendra en quelques questions:

    _ Les systèmes de fichiers qui reçoivent vos mails et documentroot sont ils sur du RAID ?

    _ En cas de panne hardware (CPU fendu, carte mère HS, disques HS), en combien de temps pouvez vous remonter une configuration "de backup" et, si les disques sont en cause, en combien de temps pouvez vous remonter un l'OS et ses services à l'identique ?

    _ Votre noyau est il "hardené" ? (patch contre les stacks/heap/whatever overflow, adresses mémoire aléatoire, support des modules desactivés, etc…).

    _ Vos différents services sont ils isolés au sein de différents containers (LXC, VZ, whatever) ?

    _ Quelle est la fréquence de vos backups mail et web et quel est le support ?

    _ Si le support de vos backups est un serveur sur internet administré par un tiers (ftp de free, cloud amazon), quelle méthode de chiffrement utilisez vous pour ces derniers ?

    Ce petit sondage, si il est un peu suivi, devrait nous permettre d'y voir un peu plus clair sur la réalité de l'auto-hébergement: ce qu'il est théoriquement possible de faire, on le sait tous … mais qu'en est il de ce que peux faire un geek passionné sur son temps libre ?
    A vos commentaires !

    • [^] # Re: Deux choses me laissent perplexe

      Posté par . Évalué à 1.

      _ En cas de panne hardware (CPU fendu, carte mère HS, disques HS), en combien de temps pouvez vous remonter une configuration "de backup" et, si les disques sont en cause, en combien de temps pouvez vous remonter un l'OS et ses services à l'identique ?

      Euh… bonne question!

      Pour Yunohost, le backup en est là:

      The backup system is not implemented yet.
      You should take care of backing up your data yourself for now.

      Donc, ça refroidit un peu, si on est adepte du clickodrome

    • [^] # Re: Deux choses me laissent perplexe

      Posté par (page perso) . Évalué à 3.

      _ Les systèmes de fichiers qui reçoivent vos mails et documentroot sont ils sur du RAID ?

      Oui, RAID1. Je sais que c'est pas un truc de fou, mais ça reste utile au cas où l'un des deux disques tombe. Evidemment, si les deux tombent, le serveur tombe.

      _ En cas de panne hardware (CPU fendu, carte mère HS, disques HS), en combien de temps pouvez vous remonter une configuration "de backup" et, si les disques sont en cause, en combien de temps pouvez vous remonter un l'OS et ses services à l'identique ?

      Plus ou moins rapidement. Mes services tournent dans des containers docker. Donc il me suffit de runner de nouveaux containers à partir des images et c'est tout bon. Après, forcement, avant cela, il faut réinstaller l'OS, configurer le réseau et installer Docker. Mais bon, disons qu'en moins d'une aprem, ça peut être fait.

      _ Votre noyau est il "hardené" ? (patch contre les stacks/heap/whatever overflow, adresses mémoire aléatoire, support des modules desactivés, etc…).

      Pas du tout. C'est le noyau stock d'Ubuntu 14.04. Mais je vais me renseigner sur ces choses là.

      _ Vos différents services sont ils isolés au sein de différents containers (LXC, VZ, whatever) ?

      Oui. Docker.

      _ Quelle est la fréquence de vos backups mail et web et quel est le support ?

      Tout les soirs à minuit. Je fais un backup de mon serveur, sur un FreeNAS que j'ai installé chez moi et dont j'y accède par VPN.

      _ Si le support de vos backups est un serveur sur internet administré par un tiers (ftp de free, cloud amazon), quelle méthode de chiffrement utilisez vous pour ces derniers ?

      Ça ne me concerne pas.

      • [^] # Re: Deux choses me laissent perplexe

        Posté par (page perso) . Évalué à 3.

        Mais bon, disons qu'en moins d'une aprem, ça peut être fait.

        Sauf si tu viens de partir en vacances loin de la maison.
        Ca doit être cool les vacances "attend, la, ça va pas le faire, faut que je bosse sinon dans 48 heures je perds mes mails".

        • [^] # Re: Deux choses me laissent perplexe

          Posté par (page perso) . Évalué à 1. Dernière modification le 07/02/15 à 21:54.

          Ca doit être cool les vacances "attend, la, ça va pas le faire, faut que je bosse sinon dans 48 heures je perds mes mails".

          C'est bien pour cela que j'ai renoncé à monter un serveur mail en perso.

      • [^] # Re: Deux choses me laissent perplexe

        Posté par (page perso) . Évalué à 2.

        Ta réponse est intéressante car dans ton cas, l'auto-hébergement semble bien géré et donc compatible avec les contraintes de sécurité des données personnelles si chères aux auto-hébergeurs.

        Juste une petite question, tu écris:

        Tout les soirs à minuit. Je fais un backup de mon serveur, sur un FreeNAS que j'ai installé chez moi et dont j'y accède par VPN.

        Ca veut dire que ton serveur principal n'est pas physiquement chez toi ?
        C'est important … juste pour rappeler que les sauvegardes, pour être réellement fiables, doivent être faites sur un site distant (pour éviter que le serveur et son backup partent en cendres en cas d'incendie, ou sous le bras d'un voleur en cas de cambriolage).

        • [^] # Re: Deux choses me laissent perplexe

          Posté par (page perso) . Évalué à 1.

          Ca veut dire que ton serveur principal n'est pas physiquement chez toi ?
          C'est important … juste pour rappeler que les sauvegardes, pour être réellement fiables, doivent être faites sur un site distant (pour éviter que le serveur et son backup partent en cendres en cas d'incendie, ou sous le bras d'un voleur en cas de cambriolage).

          C'est exact. Il se trouve en Allemagne dans une serverfarm. Et le backup se trouve chez moi.

    • [^] # Re: Deux choses me laissent perplexe

      Posté par . Évalué à 5.

      Moi je ferais un autre sondage chez les auto-hébergés qui trouvent ça vraiment trop génial et tout le monde devrait faire pareil:

      -Êtes-vous sysadmin?
      -Si non, êtes-vous développeurs ou professionnel de l'informatique?

      -Avez-vous les connaissances techniques pour faire tout ce qui est énoncé ci-dessus?

      C'est un peu comme les grands bricoleurs qui t'expliquent que tu devrais faire l'essentiel de la maintenance de ta voiture tout seul dans ton garage, "c'est pas si compliqué".

      • [^] # Re: Deux choses me laissent perplexe

        Posté par . Évalué à 1.

        -Êtes-vous sysadmin?
        -Si non, êtes-vous développeurs ou professionnel de l'informatique?

        Je suis de statut TPE, de formation sciences humaines ! Ca veut dire, prendre des décisions, faire des choix (stratégiques, techniques, économiques) dans des domaines qui ne sont pas mon coeur de métier, en veillant à la pérennité de ma structure et à sa viabilité : ça force à toucher à tout : compta, services commerciaux, outils métier et système d'information…
        et à décider quoi faire soi-même et quoi externaliser dans une enveloppe budgétaire concrète.

        Ca veut dire, en plus du boulot alimentaire facturable :
        - Beaucoup d'autoformation : dernièrement la signature et le chiffrement des messages avec pgg et enigmail
        - des horaires à rallonge : la maintenance, les tests de systèmes avant mise en production, les migrations de nuit ou le WE, car pas le droit à l'échec et à l'indisponibilité de systèmes critiques
        - des raccourcis (pas de raid 5 par ex.)

        • [^] # Re: Deux choses me laissent perplexe

          Posté par . Évalué à 0.

          moi ça me rappel la phrase d'un de mes conseiller quand j'ai monté ma société, concentrez vous sur votre coeur de métier rentabilisez la au maximum pour vous "payer" entourez de bons prestataires spécialistes aussi de leur activité.

          après toutes ces années ça ne me viendrai pas a l'idée de faire ma compta moi même, j'y perdrai trop de temps d'énergie et au final d'argent, je préfère me payer un très bon expert comptable qui de plus minimisera mes erreurs et apporte un oeuil frais et extérieur

      • [^] # Re: Deux choses me laissent perplexe

        Posté par (page perso) . Évalué à 1.

        -Êtes-vous sysadmin?

        Oui, je le suis.

      • [^] # Re: Deux choses me laissent perplexe

        Posté par . Évalué à 2.

        -Êtes-vous sysadmin?

        Je le suis devenu après avoir commencé à m'autohéberger…

        Personnellement, je ne prétends pas que tout le monde devrait faire pareil. Il y en a qui préfèrent cultiver leur propres légumes, bricoler leur voiture/maison/meubles/arduino/whatever, ou simplement passer leur temps sur des activités improductrices (mais pas moins intéressantes). C'est simplement des choix qu'on fait en fonction de notre temps, notre envie et nos moyens.

  • # Cosy cloud et Arckos

    Posté par . Évalué à 1. Dernière modification le 08/02/15 à 00:01.

    Je ne sais pas si c'est exactement en rapport avec le sujet mais il existe aussi d'autres solutions assez complètes comme:

    • cozy cloud (http://cozy.io/) une startup française qui propose une solution basé sur nodejs

    • arkos (https://arkos.io/) qui est beta mais qui fourni un système basé sur archlinux

    Ces deux solution son un peu meta par rapport aux outils présentés ici car elle permettent l'installation et la configuration d'outils pour l'auto-hébergement.
    J'ai tester sur raspberry il y a quelque temps déjà et ca manquait encore de maturité mais c'était plutôt prometteur :)

Suivre le flux des commentaires

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