Après il y a citadel, … je ne sais pas vers quoi me tourner. Yunohost mais pour X adresses mails je ne suis pas sur que ça soit une "excellente idée".
Je ne te suis pas : pourquoi tu parles d’hébergeurs si tu as prévu d’héberger toi-même tes mails ?
2-Acheter un nom de domaine chez quel registrar ?
J’en ai aucun à te conseiller en particulier. Perso je suis chez bookmyname, c’est pas cher et ça marche, mais je pense qu’ils se valent tous à peu près.
Associer le nom de domaine à une adresse IP et donc à un nom d'hote.
Pour ça tu dois utiliser un serveur DNS, Bind par exemple.
3-Éviter que les courriers ne soient considéré comme indésirables par les grands du mail (Gmail, …)
A priori, si on passe par les FAI comme les grands classiques, on risque des envoies de mails considéré comme indésirable.
Ça c’est un problème. Pour l’instant je continue à utiliser le SMTP de Free comme relai, mais je suis quand même classé comme spam de temps en temps. Il faudrait que je teste si SPF+DKIM améliorent ou empirent la situation (parce qu’on s’identifie, certes, mais on perd la "note" du serveur SMTP grand FAI).
En parlant de spam, garde à l’esprit qu’en t’hébergeant toi-même tu vas devoir gérer celui que tu reçois, et c’est pas une mince affaire. Rien que s’occuper des spams, ça représente autant de travail que tous les autres aspects du mail réunis.
Tu peux jeter un œil du côté de postscreen et de milter-greylist, qui virent à eux deux au moins 90% du spam que je reçois. Mais depuis que je les ai installés, j’ai pas encore mis à jour mon billet sur le mail.
Est-ce qu'utiliser un VPN et passer par un FAI d'association pour la neutralité du net serait une solution ?
Je ne sais pas comment sont gérés les VPN des membres FFDN, le mieux ça reste de te rapprocher de celui de ta région pour avoir des infos.
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.
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.
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/
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.
Ç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 ;)
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.
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.
pas faire les choses à moitié et de déplacer vos services HTTPS du port 443 vers un port aléatoire
Il y a une différence majeure entre https et ssh : le premier s’adresse à des utilisateurs qui peuvent être novices, le deuxième à des sysadmins. Un coup de ~/.ssh/config et c’est transparent dans la plupart des cas, sauf quand on est pas sur son ordi.
Par contre, il y a deux avantages : ne pas farcir les logs avec des scans de script kiddies, et rendre le trafic ssh un peu moins évident à repérer (à la base, le journal parle des capacités de la NSA). Si on voit un flux chiffré qui passe sur le port 22, on devine tout de suite à quoi on a affaire. Mais un flux chiffré sur le port 23904, well, ça peut être n’importe quel protocole.
Il suffit ensuite de recompiler vos clients HTTP (ou dans le meilleur cas des bibliothèques) après y avoir apporté les mêmes modifications mineures pour qu'ils fonctionnent comme avant ; l'inconvénient d'avoir un client par site web est assez léger : on se fait très vite au fait d'ouvrir chaque lien avec un navigateur différent, croyez-moi.
Comparer un changement de port à une modification du protocole… on voit que c’était trolldi hier.
certe mais c'est pas super user friendly pour ne pas tout casser :).
C’est un peu casse-pied, mais pas si compliqué que ça non plus. Il ne faut pas mixer l’option Default-Release et un épinglage personnalisé, il faut épingler à 990 la release par défaut à la place. Puis on spécifie les règles pour les paquets que l’on veut. Ça permet de jongler avec plusieurs dépôts sans faire n’importe quoi et tout casser pendant une màj.
Sinon quand j’installe une machine de bureau, je mets Debian stable et les backports, ça suffit pour une grande partie des utilisateurs. Pour ceux qui ont besoin d’installer des logiciels qui ne sont pas dans les backports, il faut faire un chroot sid.
Mine de rien, c'est comme passer de sendmail et son language de macro m4 ( on m'a parlé de faire une calculatrice avec ) à postfix, qui est purement déclaratif.
Analogie bien trouvée, et comme je suis fan de postfix tu viens de me convaincre de passer à systemd quand jessie sortira. Bon ceci dit, au début j’étais aussi convaincu par pulseaudio, mais j’avais déchanté à l’usage ;)
# Postfix
Posté par Almin (site web personnel) . En réponse au message Mise en oeuvre d'un serveur mail de 5 à 50 adresses mails max. Évalué à 1.
Postfix+dovecot c’est ce que j’utilise également.
Je ne te suis pas : pourquoi tu parles d’hébergeurs si tu as prévu d’héberger toi-même tes mails ?
J’en ai aucun à te conseiller en particulier. Perso je suis chez bookmyname, c’est pas cher et ça marche, mais je pense qu’ils se valent tous à peu près.
Oui si tu utilises Postfix, je te conseille sa gestion des utilisateurs virtuels. cf la description de mon installation :
http://almin.tf/blog/2006/10/22/gerer-mail-avec-unix/
Pour ça tu dois utiliser un serveur DNS, Bind par exemple.
Ça c’est un problème. Pour l’instant je continue à utiliser le SMTP de Free comme relai, mais je suis quand même classé comme spam de temps en temps. Il faudrait que je teste si SPF+DKIM améliorent ou empirent la situation (parce qu’on s’identifie, certes, mais on perd la "note" du serveur SMTP grand FAI).
En parlant de spam, garde à l’esprit qu’en t’hébergeant toi-même tu vas devoir gérer celui que tu reçois, et c’est pas une mince affaire. Rien que s’occuper des spams, ça représente autant de travail que tous les autres aspects du mail réunis.
Tu peux jeter un œil du côté de postscreen et de milter-greylist, qui virent à eux deux au moins 90% du spam que je reçois. Mais depuis que je les ai installés, j’ai pas encore mis à jour mon billet sur le mail.
Je ne sais pas comment sont gérés les VPN des membres FFDN, le mieux ça reste de te rapprocher de celui de ta région pour avoir des infos.
[^] # Re: Pourquoi obligatoirement un webmail ?
Posté par Almin (site web personnel) . En réponse au journal Auto-hébergement: pas toujours évident.... É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 Almin (site web personnel) . En réponse au journal Auto-hébergement: pas toujours évident.... É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 Almin (site web personnel) . En réponse au journal Auto-hébergement: pas toujours évident.... É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 Almin (site web personnel) . En réponse au journal Auto-hébergement: pas toujours évident.... É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 Almin (site web personnel) . En réponse au journal Auto-hébergement: pas toujours évident.... É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 Almin (site web personnel) . En réponse au journal Auto-hébergement: pas toujours évident.... É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: Il est conseillé de changer de port
Posté par Almin (site web personnel) . En réponse au journal Espionnage sur le net : des nouvelles du front. Évalué à 2.
Il y a une différence majeure entre https et ssh : le premier s’adresse à des utilisateurs qui peuvent être novices, le deuxième à des sysadmins. Un coup de ~/.ssh/config et c’est transparent dans la plupart des cas, sauf quand on est pas sur son ordi.
Par contre, il y a deux avantages : ne pas farcir les logs avec des scans de script kiddies, et rendre le trafic ssh un peu moins évident à repérer (à la base, le journal parle des capacités de la NSA). Si on voit un flux chiffré qui passe sur le port 22, on devine tout de suite à quoi on a affaire. Mais un flux chiffré sur le port 23904, well, ça peut être n’importe quel protocole.
Comparer un changement de port à une modification du protocole… on voit que c’était trolldi hier.
[^] # Re: Étrange...
Posté par Almin (site web personnel) . En réponse au journal Espionnage sur le net : des nouvelles du front. Évalué à 1.
Bonne idée, ça évite effectivement que quelqu’un mette une passphrase sur la clé de l’hôte ;)
[^] # Re: Debian stable + pinning
Posté par Almin (site web personnel) . En réponse au journal Une idée de distribution Linux. Évalué à 0.
C’est un peu casse-pied, mais pas si compliqué que ça non plus. Il ne faut pas mixer l’option Default-Release et un épinglage personnalisé, il faut épingler à 990 la release par défaut à la place. Puis on spécifie les règles pour les paquets que l’on veut. Ça permet de jongler avec plusieurs dépôts sans faire n’importe quoi et tout casser pendant une màj.
Je me suis remis récemment à l’épinglage apt, parce que openvz n’est plus supporté dans wheezy, et surtout à cause de la faille de bash.
http://almin.tf/blog/2014/09/26/epinglage-apt-pinning/
Sinon quand j’installe une machine de bureau, je mets Debian stable et les backports, ça suffit pour une grande partie des utilisateurs. Pour ceux qui ont besoin d’installer des logiciels qui ne sont pas dans les backports, il faut faire un chroot sid.
[^] # Re: Forkons Fedora !
Posté par Almin (site web personnel) . En réponse au journal Un fork de Debian à cause de systemd ?. Évalué à 2.
Analogie bien trouvée, et comme je suis fan de postfix tu viens de me convaincre de passer à systemd quand jessie sortira. Bon ceci dit, au début j’étais aussi convaincu par pulseaudio, mais j’avais déchanté à l’usage ;)
[^] # Re: Beaucoup de bruit
Posté par Almin (site web personnel) . En réponse au journal Un fork de Debian à cause de systemd ?. Évalué à 7.
À propos de BSD, on voit de plus en plus de monde qui pense migrer si systemd devient incontournable sous Linux.