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:
- Roundcube
- Mailpile
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 palm123 (site web personnel) . É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
ウィズコロナ
[^] # Re: je suis épaté
Posté par Richard Dern . É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 NiKaro (site web personnel) . É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 Richard Dern . Évalué à 2.
En tout cas ça mérite d'être essayé :)
[^] # Re: Rainloop ?
Posté par dzecniv . Évalué à 0.
Rainloop est super, ça fait plaisir à voir !
Il mériterait une dépêche à lui tout seul, non ? :)
[^] # Re: Rainloop ?
Posté par Zenitram (site web personnel) . É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 El Titi . É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 Zenitram (site web personnel) . Évalué à 6. Dernière modification le 05 février 2015 à 17:10.
Pour le libristes en herbe, remarque : ce n'est pas libre.
Edit : argh, grillé de quelques secondes!
[^] # Re: Rainloop ?
Posté par NiKaro (site web personnel) . Évalué à -2.
Ah effectivement… Enfin bon, la clause NC ne me dérange pas pour ma part.
[^] # Re: Rainloop ?
Posté par Zenitram (site web personnel) . É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 BAud (site web personnel) . É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 Sufflope (site web personnel) . É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 Elfir3 . Évalué à 5.
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 Zenitram (site web personnel) . Évalué à 4. Dernière modification le 06 février 2015 à 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 freem . É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 MTux . Évalué à 6.
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 Richard Dern . É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 jihele . Évalué à 4.
Dans les solutions tout en un, il y a SoGo. J'ai pas testé.
[^] # Re: Zimbra
Posté par MTux . É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 Larry Cow . É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 Parleur . Évalué à 3.
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 Richard Dern . É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 Parleur . É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 SaintGermain . É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 Zenitram (site web personnel) . É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 KiKouN . Évalué à 4.
Un webmail à deux balles dépanne aussi bien qu'une galette.
[^] # Re: Pourquoi obligatoirement un webmail ?
Posté par SaintGermain . É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 FDF (site web personnel) . É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 freem . Évalué à 2.
Jamais essayé, mais,
apt-get install roundcubene 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 SaintGermain . Évalué à -1.
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 freem . Évalué à 6.
Hum… ce wiki est à côté de la plaque, pour un utilisateur de distro linux.
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-passengeren 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 SaintGermain . É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 freem . É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 SaintGermain . É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 freem . Évalué à 1.
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.
J'en doute, je ne suis pas admin.
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 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 SaintGermain . É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 freem . Évalué à 2. Dernière modification le 06 février 2015 à 15:55.
Dans les points que tu cites, aucun n'est par rapport à roundcube, et encore moins à son installation.
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 SaintGermain . Évalué à 1.
Alors rapidement :
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 freem . Évalué à 2.
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)?
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,
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 MCMic (site web personnel) . Évalué à 5.
Ben c’est pourtant exactement le propos qui a lancé tout ce thread:
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:
[^] # Re: Pourquoi obligatoirement un webmail ?
Posté par freem . Évalué à 2.
Hum.
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 MCMic (site web personnel) . Évalué à 5.
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 Zenitram (site web personnel) . Évalué à 1.
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 Effraie (site web personnel) . É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
\Ö<
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Pourquoi obligatoirement un webmail ?
Posté par SaintGermain . É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 Adrien Dorsaz (site web personnel, Mastodon) . É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 roundcubeou 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 freem . Évalué à 2.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 09 février 2015 à 12:25.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Pourquoi obligatoirement un webmail ?
Posté par freem . Évalué à 2.
Mais dans ce cas on paye un pro. Enfin, un type censé savoir faire du moins.
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 :)
ouch… s/dont/sur lesquels/g. Et c'est moi qui ait commis ça… mea culpa
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Pourquoi obligatoirement un webmail ?
Posté par freem . Évalué à 2.
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…).
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 Almin (site web personnel) . Évalué à 2.
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.
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 freem . Évalué à 3.
Ç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 Almin (site web personnel) . Évalué à 1.
Ç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.
Les paquets debian (roundcube, phpmyadmin, owncloud, etc) créent un lien symbolique dans /etc/apache2/conf.d/
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 Sufflope (site web personnel) . Évalué à 3.
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
malconç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 Almin (site web personnel) . É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.
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 Sufflope (site web personnel) . Évalué à 2.
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.
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,
Je te retourne le conseil.
[^] # Re: Pourquoi obligatoirement un webmail ?
Posté par Almin (site web personnel) . Évalué à 0.
Puisqu’on parlait de roundcube, pour son paquet dans la debian stable :
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.
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 freem . Évalué à 2.
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 Almin (site web personnel) . Évalué à 0.
Il faut créer un fichier pour ton site dans /etc/apache2/sites-enabled/, et pour le reste :
[^] # Re: Pourquoi obligatoirement un webmail ?
Posté par oinkoink_daotter . Évalué à 3.
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.
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 Almin (site web personnel) . Évalué à 0.
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 ;)
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 Richard Dern . É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 xcomcmdr . Évalué à 10.
Beurk.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi obligatoirement un webmail ?
Posté par Richard Dern . É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 SaintGermain . É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 :
[^] # Re: Pourquoi obligatoirement un webmail ?
Posté par Richard Dern . É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 SaintGermain . É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 :
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 Zenitram (site web personnel) . Évalué à 7.
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 SaintGermain . É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 Zenitram (site web personnel) . Évalué à 3. Dernière modification le 05 février 2015 à 21:20.
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).
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)
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.
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 SaintGermain . É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 Zenitram (site web personnel) . Évalué à 2.
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 Larry Cow . Évalué à 2.
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 freem . É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 Larry Cow . Évalué à 3.
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 Matthieu Moy (site web personnel) . É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 Richard Dern . É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 Matthieu Moy (site web personnel) . É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 Richard Dern . É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 bindpour é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 Tangi Colin . Évalué à 10. Dernière modification le 05 février 2015 à 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 NiKaro (site web personnel) . Évalué à 6.
Il faut bien commencer par quelque part, montrer l'exemple.
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 karteum59 . Évalué à 2.
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 SaintGermain . É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 Parleur . Évalué à 1.
Parce-que si tu rentrais dedans, tu changerais d'avis ?
[^] # Re: Pourquoi toujours le cas du mail ?
Posté par Zenitram (site web personnel) . É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 SaintGermain . É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 AgentSteel (site web personnel) . Évalué à 2.
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 Richard Dern . Évalué à 3.
Et/ou en faisant du DKIM + SPF. Personnellement je ne passe plus par le smarthost de free.
[^] # Re: Pourquoi toujours le cas du mail ?
Posté par SaintGermain . Évalué à 0.
Nope cela ne marche pas tout le temps :
Héberger son courriel lorsque celui-ci est classé en tant que spam
Pour ma part après bien des efforts, j'ai abandonné. Mais c'était très intéressant et j'ai beaucoup appris donc pas inutile.
[^] # Re: Pourquoi toujours le cas du mail ?
Posté par Richard Dern . Évalué à 7.
Je vais faire mon idéaliste, mais si on abandonnait tous GMail et consorts, et qu'on hébergeait tous notre propre serveur mail, on n'aurait peut être pas ce soucis.
[^] # Re: Pourquoi toujours le cas du mail ?
Posté par SaintGermain . Évalué à 3.
Et si la loi était mieux fichue, et que l'on pouvait confier nos emails à un prestataire sérieux, peut-être que l'on aurait pas tous à faire cela.
[^] # Re: Pourquoi toujours le cas du mail ?
Posté par Richard Dern . Évalué à 2.
Il resterait toujours la question de la confiance envers l'hébergeur… Mais comme on est en mode "idéaliste"…
[^] # Re: Pourquoi toujours le cas du mail ?
Posté par SaintGermain . Évalué à 2.
Non ça c'est un problème commercial et de concurrence.
Exemple : tu confies bien ta vie au pilote d'avion et cela ne te pose pas plus de problème que cela. Pourquoi ?
[^] # Re: Pourquoi toujours le cas du mail ?
Posté par Richard Dern . Évalué à 2.
Parce que je n'ai pas les compétences techniques pour piloter un 737 ?
:)
[^] # Re: Pourquoi toujours le cas du mail ?
Posté par SaintGermain . Évalué à -1.
C'est comme l'auto-hébergement, il suffit de s'y mettre avec un peu de temps, de motivation et un peu (beaucoup) d'argent et hop c'est fait !
John Travolta a bien réussi (!) alors pourquoi pas toi ? ;-)
[^] # Re: Pourquoi toujours le cas du mail ?
Posté par Richard Dern . Évalué à 1.
Parce que de toute façon j'ai moins l'intérêt de maitriser un avion que mes données ?
[^] # Re: Pourquoi toujours le cas du mail ?
Posté par SaintGermain . Évalué à 4.
Euh tes données sont plus importantes que ta vie ?
Si tu fais confiance à un mauvais fournisseur d'emails, adieu ta vie privée
Si tu fais confiance à une mauvaise compagnie aérienne, adieu ta vie.
[^] # Re: Pourquoi toujours le cas du mail ?
Posté par Richard Dern . Évalué à 2.
En plus ta comparaison est quelque peu hasardeuse. Dans le même ordre d'idée, tu ne prends jamais les transports en commun ? Tu fabrique toi-même ton soda ou ta bière ? Tu créé tes propres émissions de TV ? As-tu au moins confiance dans les cellules qui composent ton corps ? :)
On parle d'auto-hébergement, concept créé justement parce qu'on ne fait pas confiance aux hébergeurs de contenu. On ne remet pas non plus tout en question…
[^] # Re: Pourquoi toujours le cas du mail ?
Posté par SaintGermain . Évalué à 1.
Ah ? Moi je trouve que l'analogie est bonne.
Il y a pleins de cas où je fais une totale confiance à un prestataire ou une compagnie (avec ma vie, mes données, mes biens, etc.). Toute la difficulté est de trouver le bon prestataire ou la bonne compagnie. Et cela n'a rien à voir avec une utopie ou un idéalisme, c'est juste du commerce et de la concurrence.
Après si pour une raison quelconque, tu ne veux pas faire confiance, c'est ton droit le plus absolu.
C'est un calcul que l'on fait tous les jours (risque que ça merde versus valeur de la chose).
Allez on a assez dérivé, bonne nuit ! ;-)
[^] # Re: Pourquoi toujours le cas du mail ?
Posté par totof2000 . Évalué à 0.
Je ne fais pas confiance qux compagnies aériennes donc je ne prends pas l'avion :)
[^] # Re: Pourquoi toujours le cas du mail ?
Posté par freem . Évalué à 2.
Adieu ta vie privée aussi dans le 2nd cas: si t'as pas de bol, on peut voir tes organes (enfin, ce qu'il en reste) un peu partout :D
[^] # Re: Pourquoi toujours le cas du mail ?
Posté par anaseto (site web personnel) . Évalué à 6.
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 LaBienPensanceMaTuer . É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 Babelouest (site web personnel) . Évalué à 2. Dernière modification le 06 février 2015 à 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 LaBienPensanceMaTuer . Évalué à -1.
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 Parleur . Évalué à 1. Dernière modification le 07 février 2015 à 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 Arthur Geek (site web personnel) . É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 Nicolas Boulay (site web personnel) . É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 freem . É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 Nicolas Boulay (site web personnel) . É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 freem . É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:
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 Tit . Évalué à 3.
Puis
ça dépend, si tu répètes tout deux fois, ça risque de les rallonger ;-)
[^] # Re: distribution ?
Posté par freem . Évalué à 2.
Méheu! pertinent pour la peine ^
# Édition des informations personnelles : FusionDirectory
Posté par MCMic (site web personnel) . Évalué à 4.
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)
[^] # Re: Édition des informations personnelles : FusionDirectory
Posté par Richard Dern . Évalué à 1.
Je teste, ça me semble pas mal. Merci !
# squirrelmail versus la mode du full JS
Posté par freem . É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 Sufflope (site web personnel) . Évalué à 3.
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 freem . É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 barmic . Évalué à 3.
Je ne connais pas ces logiciels, mais :
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.
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 freem . Évalué à 2.
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 LaBienPensanceMaTuer . É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 samydb . Évalué à 1.
Euh… bonne question!
Pour Yunohost, le backup en est là:
Donc, ça refroidit un peu, si on est adepte du clickodrome
[^] # Re: Deux choses me laissent perplexe
Posté par Atem18 (site web personnel) . Évalué à 3.
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.
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.
Pas du tout. C'est le noyau stock d'Ubuntu 14.04. Mais je vais me renseigner sur ces choses là.
Oui. Docker.
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.
Ça ne me concerne pas.
[^] # Re: Deux choses me laissent perplexe
Posté par Zenitram (site web personnel) . Évalué à 3.
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 Atem18 (site web personnel) . Évalué à 1. Dernière modification le 07 février 2015 à 21:54.
C'est bien pour cela que j'ai renoncé à monter un serveur mail en perso.
[^] # Re: Deux choses me laissent perplexe
Posté par LaBienPensanceMaTuer . É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:
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 Atem18 (site web personnel) . Évalué à 1.
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 Maclag . É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 samydb . Évalué à 1.
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 ddfdom . É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 Atem18 (site web personnel) . Évalué à 1.
Oui, je le suis.
[^] # Re: Deux choses me laissent perplexe
Posté par kna . Évalué à 2.
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 mickours . Évalué à 1. Dernière modification le 08 février 2015 à 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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.