Une petite dépêche pour annoncer la publication sous licence libre (CC-BY-SA) d'une documentation complète pour s'auto-héberger.
Une version précédente de ce document reposait sur debian, mais après des tests sous OpenBSD, il est clairement apparu que la configuration et la maintenance sous ce dernier système est nettement plus simple. Des parallèles avec debian et un guide d'installation est malgré tout fournit pour les plus inquiets, bien qu'on retrouve ses repères très rapidement (cp, ls, mv, vi…)
Le contenu n'est pas exhaustif ni académique, mais devrait constituer un bon tremplin pour ceux qui seraient tentés par l'aventure de l'auto-hébergement.
Une version numérique est disponible ici [1], ainsi qu'une version papier selon les préférences de lecture [2].
[1] : http://yeuxdelibad.net/ah/
[2] : http://www.atramenta.net/books/lauto-hebergement-facile-et-securise-avec-openbsd/477
Bonne lecture!
# Pas mal du tout
Posté par karchnu . Évalué à 3.
En parcourant un peu le document on se rend compte de quelques approximations, mais c'est quand même une très bonne approche et un bon début pour un néophyte. Bravo ! :)
[^] # Re: Pas mal du tout
Posté par Thuban (site web personnel) . Évalué à 4.
Des approximations totalement assumées, j'aurais dû prévenir dès le début. Je me voyais mal faire un cours sur les réseaux alors que l'objectif est de "vulgariser" l'auto-hébergement. J'en aurais d'ailleurs été incapable.
# cool mais...
Posté par Nico C. . Évalué à 0.
l'autohébergement, c'est bien mais ça tient pas bien la charge…
[^] # Re: cool mais...
Posté par foobarbazz . Évalué à 10.
google est auto-hébergé et ils n'ont pas de soucis à ce niveau là.
[^] # Re: cool mais...
Posté par Nico C. . Évalué à 3.
C'etait juste une petite blague sur le fait que le site rame un peu (probablement a cause d'un mini effet /. )
[^] # Re: cool mais...
Posté par bobo38 . Évalué à 2.
Oui j'allais le signaler en commentaire, sans doute qu'une version HTML sans image pourrait permettre de ne pas pomper trop la bande passante. Après c'est l'effet publication avec toutes les moules de LinuxFR.org qui télécharge le document dans l'heure qui suit la publication :D
[^] # Re: cool mais...
Posté par Thuban (site web personnel) . Évalué à 8.
Oui, ça rame au premier chargement, surtout à cause des images, mais aussi des (quelques) libs js, polices woff que j'ai préférer héberger plutôt que relier à un CDN google & co.
C'est un des désagréments de s'héberger tout seul : la bande passante. La mienne est pourrie qui plus est :/
Et puis, ça aurait été vachement hypocrite une doc sur l'auto-hébergment pas auto-hébergée :D
[^] # Re: cool mais...
Posté par Nico C. . Évalué à 6.
Ben après, c'est quoi pour toi l'autohebergement exactement ? gerer soi meme son site jusqu'au serveur lui meme ?
Est ce qu'un serveur dédié (physique ou virtuel) loué chez OVH rentre dans cette catégorie ?
Autre remarque : j'ai du mal a piger pourquoi tu consideres que OpenBSD est plus simple que Debian etant donné que l'extreme majorité de ton doc consiste a expliquer comment configurer des services identiques sur les 2 systemes (a une exception pres : openbsd httpd au lieu d'apache) ?
[^] # Re: cool mais...
Posté par Thuban (site web personnel) . Évalué à 7.
Dans l'idéal, l'auto-hébergement, c'est d'avoir tout chez soi. Lorsque ce n'est pas possible, un dédié fait l'affaire, même si on s'éloigne du concept d'origine.
OpenBSD est plus simple à mon avis, au moins pour les raisons suivantes :
- Configuration du parefeu : 1 seul fichier de configuration, lisible pour un humain. Pas de ufw, arno-iptables-firewall, d'iptables et ip6tables (comme si l'ipv6 devait être géré à part…) pour faire un bazar dans lequel on s'y perd vite. Dans ce même fichier, on peut en plus y intégrer des règles anti-bruteforces habituellement gérées par fail2ban sous linux.
- On retrouve la même simplicité pour httpd et opensmtpd. Des fichiers de configuration jusqu'à 3 fois plus courts.
- Chaque service vient avec une documentation intégrée limpide (voir php) et des exemples.
Ce que tu considères comme "l'extrême majorité" constitue la 2e partie de la documentation appelée "Travaux pratique", qui n'est là qu'à titre d'exemple.
Les services sont bien évidemment identiques, il n'y a pas deux sortes de serveur de courrier ni deux sortes de serveur http :)
[^] # Re: cool mais...
Posté par patrick_g (site web personnel) . Évalué à 2.
Sur certains aspects peut-être.
Mais bon, support limité à un an et après il faut obligatoirement passer sur une nouvelle version. Et pour les patchs de sécurité c'est soit à la mano en recompilant son noyau, soit en utilisant les binaires mis à disposition par une société tierce (bonjour la confiance qu'il faut avoir).
[^] # Re: cool mais...
Posté par Thuban (site web personnel) . Évalué à 4.
Je ne vois pas en quoi le support d'un an est un problème. C'est au contraire plus dangereux de garder un serveur pas à jour.
Pour les mises à jour justement, ce que tu dis est vrai. Mais franchement, c'est tout bête. Tout est très bien expliqué et détaillé pour les compilations. C'est tellement bien décrit qu'on pourrait presque bêtement recopier les commandes données unes à unes. Je trouve ça plus prudent que de mettre à jour tout d'un coup en faisant confiance à apt sans trop savoir exactement ce qu'il se passe et voir des erreurs données par dpkg. C'est rare, mais le fait qu'encore beaucoup de serveurs tournent sous wheezy n'y est peut-être pas étranger.
[^] # Re: cool mais...
Posté par patrick_g (site web personnel) . Évalué à 1. Dernière modification le 01 juin 2016 à 17:35.
Oui mais je ne compare pas par rapport à un serveur pas à jour. Je compare par rapport à des distros ayant un support bien plus long (CentOS, Debian, Ubuntu LTS, etc).
Quand à la facilité de mise à jour. Mmmm…comment te dire ? Recompiler son noyau ce serait plus facile que de cliquer sur un bouton d'un pop-up de mise à jour ? PAs pour madame michu en tout cas.
Et tu te contredis dans ton argumentation en disant qu'il suffit de recopier bêtement des commandes (donc accessible à un neuneu) et que ça permet de surveiller vraiment ce qu'il se passe par opposition à apt (donc cas d'un utilisateur avancé).
[^] # Re: cool mais...
Posté par Thuban (site web personnel) . Évalué à 8.
:D Un popup de mise à jour sur un serveur? C'est nouveau ça :)
As-tu déjà procédé à la mise à jour complète d'une OpenBSD? Rien à voir avec la compilation du noyau linux en tout cas.
Non, je ne me contredis pas, je dis que ça évite les mauvaises surprises. Car entre recopier un "apt-get upgrade && apt-get dist-upgrade" ou celles indiquées dans la doc d'OBSD, il n'y a pas de différences pour l'utilisateur "neuneu" comme tu dis.
[^] # Re: cool mais...
Posté par Frank-N-Furter . Évalué à 2.
https://fr.wikipedia.org/wiki/Auto-h%C3%A9bergement_(Internet)
Non, dans ce cas tu fais juste de l'admin sys.
Depending on the time of day, the French go either way.
[^] # Re: cool mais...
Posté par Misc (site web personnel) . Évalué à 4.
Ne pas mettre une version sur 1 seule page comme lien aurait sans doute suffit.
La, quelqu'un clique et charge toute les images d'un coup, donc bon. Au contraire, mettre des pages plus petites aurait en effet sans doute pris plus de requêtes http, mais moins de bp.
[^] # Re: cool mais...
Posté par Thuban (site web personnel) . Évalué à 3.
Oui bien sûr.
Mais il faut faire des choix quand on écrit un truc pareil. Là, je voulais qu'il puisse être imprimé, c'est possible avec la page html et un peu de CSS. LE tout est généré avec txt2Tags, on a donc un beau pdf en LaTeX au besoin. Bref, il y avait d'autres choix possibles, avec leurs inconvénients aussi :)
[^] # Re: cool mais...
Posté par GG (site web personnel) . Évalué à 4.
Bonjour,
j'aurais bien voulu un affichage par chapitre, et non pas le document en entier.
Mais, aussi, un lien vers la page html complète.
Il y a plusieurs sites avec de la documentation qui fonctionnent ainsi.
Bonne journée
G
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: cool mais...
Posté par zurvan . Évalué à 3.
Bravo et merci pour ce guide, et c'est chouette d'utiliser txt2tags, le meilleur langage de balisage léger :)
C'est vrai que ce n'est pas trop prévu pour créer une doc avec de multiples pages html, mais il y a des astuces malgré tout :
https://txt2tags.wordpress.com/2006/08/31/split-html-in-multiple-pages/
L'autre solution, c'est de séparer les chapitres dans des fichiers différents, ça a ses avantages et inconvénients, mais c'est facile de les regrouper ensuite dans un document html unique avec des includes.
Au niveau du CSS, ça rend joli, par contre sur mobile la table des matières, omniprésente, rogne sur la marge à gauche du texte. Peut-être qu'un menu, qui se replierait en cliquant sur un bouton, serait plus adapté.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: cool mais...
Posté par Thuban (site web personnel) . Évalué à 1.
Salut,
Alors j'avais essayé le lien que tu donnes pour séparer la page html en plusieurs, mais le rendu est vraiment très moche!
[^] # Re: cool mais...
Posté par steph1978 . Évalué à 2.
Il y a des astuces pour ne charger les images qu'à l'affichage.
De cette manière, seules les images consultées par le lecteur sont chargées.
Tu peux aussi utiliser ggl page speed qui est de bon conseil.
# Lecture rapide
Posté par Mimoza . Évalué à 3.
En effet OpenBSD offre quelques avantages, par contre il n'est pas présent sur des plateforme populaire tel qu'un Raspberry(http://marc.info/?l=openbsd-misc&m=142299965218464&w=4).
Sinon ton lien vers Bozon n'est pas bon, ça envoie vers une page d'erreur du site. D’ailleurs impossible de trouver une capture d'écran de ce logiciel sur leur site.
Pour les nom de domaine tu peux aussi inclure freenom.com qui offre la possibilité d'avoir un .tk, .ml, .ga, .cf et/ou .gq gratuitement.
Ton § avec les équivalence des commandes Debian n'est pas bête et mériterait d'être étoffé.
Peut être un § sur openNTPd serais pas mal.
[^] # Re: Lecture rapide
Posté par Thuban (site web personnel) . Évalué à 1.
Eh non, pas de raspberry pi pour openBSD. C'est très bien pour commencer, mais c'est vite limité comme jouet. Heureusement, il y a YUnoHost.
Merci pour bozon. Il y avait cette url : http://bozon.pw/fr , alors qu'il faut http://bozon.pw/fr/ pour que ça fonctionne :/
Je garde tes conseils pour les étudier plus tard, afin de ne détailler que des procédures que j'ai pu tester ;)
# L'autohebergement oui, l'ADSL non
Posté par gUI (Mastodon) . Évalué à 6.
Promouvoir l'autohebergement c'est très bien. Mais je pense qu'il faut promouvoir également le fait d'aller louer un serveur (dédié ou mutualisé) afin de pouvoir réellement profiter de ses services.
Si les gens galèrent quelques week-end pour se mettre en place un serveur qui est difficilement utilisable dans la vie réelle (ça rame !!!) ça va pas faire de la grosse pub, ça va pas convaincre.
Et hébergement loué ne veux pas dire cher, j'avais fait un journal dans ce sens il y a peu : http://linuxfr.org/users/gbetous/journaux/son-propre-cloud-a-pas-cher
Pour moi l'essentiel dans l'auto-hebergement c'est la maîtrise des données, et un peu moins de l'infrastructure.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par Liorel . Évalué à 1.
D'un autre côté, si tu ne maîtrises pas l'infrastructure, tu ne maîtrises pas les données non plus. Tu es obligé de faire confiance à l'hébergeur. Tant qu'il est réglo, ça va, mais si un jour il décide de te faire une vacherie… Tu n'auras que tes yeux pour pleurer, et si la requête vient de l'état, tu n'auras même pas de possibilité de recours en justice.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par gUI (Mastodon) . Évalué à 4.
Bin non, t'auras tes sauvegardes et ton nom de domaine. En 48h tu t'es hébergé ailleurs.
Serveur dédié ne veut en aucun cas dire "ne prendre aucune précaution de sauvegarde".
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par foobarbazz . Évalué à 1.
Non, ça veut dire « J'utilise la machine de quelqu'un d'autre » et ça soulève plus ou moins les même problèmes que l'utilisation de services en ligne.
T'as un compte mail en ligne, les services secrets peuvent taper dedans.
T'as une machine virtuelle en ligne qui fait tourner serveur mail, les services secrets peuvent taper dedans. La seule différence c'est le protocole qu'il devront utiliser pour ça, c'est bonnet blanc et blanc bonnet.
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par Psychofox (Mastodon) . Évalué à 2.
Ouais bon les services secrets s'ils veulent tes données auto-hébergées ils vont aller les chercher chez toi hein et ce ne sera pas bien plus compliqué.
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par foobarbazz . Évalué à 2.
Les services secrets a priori ne veulent pas "mes données" mais "des données". Si les miennes sont à porté de script, elle sont intéressantes, s'il faut défoncer ma porte pour (peut-être) les avoir, elles le sont beaucoup moins.
Et je parle des services secrets, mais c'est pareil pour les publicitaires, ou toute autre institution intéressées par des données…
Certes, tu limite fortement l'exposition de tes données en ayant ton serveur chez un hébergeur, mais cette solution est loin d'être équivalente à avoir ta machine à coté de ta box.
Et même si je fais l'objet d'une surveillance ciblée, s'ils veulent mes données je préfère qu'elles soient chiffrés, par ma machine, chez moi. De sortes qu'ils ne puissent y accéder qu'à grand frais et avec mon consentement.
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par kna . Évalué à 4.
C'est quoi la différence avec tes données chiffrées chez un hébergeur ?
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 4.
La difficulté de taper le mot de passe au boot.
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par kna . Évalué à 2.
Tu peux avoir un accès console distant chez un hébergeur. Je dois néanmoins reconnaitre que les soucis de mappage du clavier sont fréquents sur ces trucs là.
Sinon, tu peux chiffrer uniquement les partitions qui contiennent des données. Il faut juste que tu aies en clair de quoi booter, te connecter, et monter tes partitions chiffrées.
Et comme c'est pas parce que tu es parano qu'ils ne sont pas après toi, tu peux stocker sur une partition chiffrée les sommes de contrôle pour contrôler l'intégrité des partitions non chiffrées.
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
Qui peut donc sniffer ton mot de passe si tu le tapes dans la console.
Ça ne garantit pas la sûreté du machin parce que tu lances la vérification de l'intégrité sur une machine non sûre.
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par dyno partouzeur du centre . Évalué à 1.
Je crois qu'il y a des protocoles un peu plus sécurisés que telnet. Genre ssh.
Après, une partition chiffrée c'est bien mais une fois qu'elle est montée avec le bon mot de passe, l'hébergeur accède aux données tout pareil.
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 4.
On parle d'une machine qui n'a pas booté, donc sans ssh. L'hébergeur te file une console genre IPMI, iLo, à travers une interface web pour que tu puisses taper le mot de passe comme si tu étais physiquement présent. Donc tu passes par l'infrastructure de l'hébergeur qui peut sniffer ton mot de passe.
Comment ?
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par n0wic . Évalué à -7.
Ca dépend du contexte, il faut le préciser c'est important car on ne connait pas ton hébergeur ni les mécanismes de gestion des droits de montage de tes partitions.
Tu peu envisager un mécanisme de sécurité où les droits de montage des partitions sont supérieurs à ceux de root par exemple.
Il y a différents types de mécanismes de sécurité tout comme tu peu gérer les droits sur l'éxécution d'un code sur une machine.
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par n0wic . Évalué à -8.
C'est légal ca ?
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par Liorel . Évalué à 1.
C'est moi ou tu te poses une question à toi-même ?
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par n0wic . Évalué à -7.
C'est à propos du contexte car tu n'as pas la réponse ?
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par Thuban (site web personnel) . Évalué à 1.
Ça reste nettement plus simple d'avoir ses données à la maison.
Et puis restons réalistes, on parle d'auto-hébergement, donc des services à l'échelle d'une famille quoi. Pas d'un gros datacenter qui doit pouvoir balancer des Go de données à longueur de journée.
Et même si un site est un peu plus lent, on peut toujours lire le texte le temps que toutes les images soient téléchargées, c'est à dire pendant 3 à 4 secondes… C'est pas si énorme quand on compare avec une navigation sans bloqueur de pub sur Le Monde par exemple.
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par Misc (site web personnel) . Évalué à 3.
Alors la question est pas pour moi, mais ça dépend du service et de l'attaquant.
Tu peux avoir une VM (sans doute pas ton cas), et l'hébergeur peut en théorie et "trivialement" faire des trucs à partir de ça (genre 'freeze de la mémoire' et extraction des clés depuis le dump).
Techniquement, une attaque du même genre à base de coldboot est possible: https://en.wikipedia.org/wiki/Cold_boot_attack . Ca implique un reboot du serveur et 5 ou 6 minutes de downtime au mieux.
Techniquement, une attaque à base de modification de l'initrd est aussi possible: https://github.com/GDSSecurity/EvilAbigail
Ça requiert aussi un reboot, et ça laisse des traces.
Théoriquement, tu peux aussi dumper la ram via jtag/openocd en fonction de l'archi de la machine. Je sais que ça passe pour de l'arm embarqué (ou du mips), mais je sais pas du tout pour les archis plus classiques (genre x86 ou serveur). En fonction de la machine, ça requiert sans doute du matos et des trucs spéciaux et peut être éteindre la machine pour mettre les connecteurs. C'est une piste à explorer AMHA.
Mais non, à part la VM, y a rien de trivial mais ça dépend vraiment des attaquants.
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par Misc (site web personnel) . Évalué à 2.
Une solution possible serait de regarder clevis and tang:
https://speakerdeck.com/frasertweedale/tang-and-clevis-shackling-secrets-to-the-network
( https://github.com/latchset/ )
Ça requiert en effet 2 serveurs, mais tu peux dire "utilise le réseau et le tpm", ce qui fait qu'un attaquant volant le disque doit prendre le serveur, la carte mère et répliquer le réseau.
Ça ne réponds pas forcément à tout types d'attaques, bien sur, mais ça me semble un élément de réponse.
Sinon, y a des modules pour dracut pour faire ça par dessus ssh:
https://github.com/dracut-crypt-ssh
https://github.com/mk-fg/dracut-crypt-sshd
( le premier vient de https://bugzilla.redhat.com/show_bug.cgi?id=524727 et n'a pas été mergé upstream, hélas)
Ou d'autres solutions:
https://bitbucket.org/geekman/dracut-gmcrypt
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par Misc (site web personnel) . Évalué à 2.
Plus ça coute cher, plus ça va finir par faire mal aux portefeuilles et en effet rendre le truc plus compliqué.
Mais plus ça coute cher, plus il y a de raisons de rendre ça plus facile.
Soit par des lois (cf le FBI par exemple), soit en faisant appel au secteur privé (HT, gamma group), qui va voir en effet une opportunité business.
Et bon, je doute aussi que tout les services secrets débordent d'experts. Ils doivent en avoir bien sur, mais pas non plus des tonnes. Et donc partir du principe qu'ils misent surtout sur le fait qu'ils ont des gens dédiés (cf la présentation de l'équipe TAO durant la conf enigma), et que leur force, c'est surtout d'avoir du temps pour être méticuleux.
Et cf le catalogue de la NSA, il y a aussi de la refacturation interne pour le matos, c'est donc pas non plus la fête du slip.
(encore une fois, ça reste une administration, avec le secret défense et tout, donc ça doit être lourd procéduralement, d'autant plus après les leaks de snowden).
J'ai aussi l'impression qu'ils ont juste tendance à bruteforcer les trucs ( "alors, on va prendre une tonne de serveur mysql pour stocker xkeyscore, c'est plus simple") la ou Google (pour donner un exemple de boite avec des ingés et des besoins de monter à l’échelle) a refait toute l'infra from scratch, de part une pression plus forte à être compétitif (et sans doute plus d'ingés que la NSA).
Donc ouais, je pense que "rendre le truc plus cher" est une bonne idée. De la même façon qu'on juge les coffres par le temps pour être percés plus que savoir si on rentre ou pas. C'est plus honnête et logique vis à vis du modèle d'attaque courant.
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par n0wic . Évalué à -6. Dernière modification le 03 juin 2016 à 13:09.
En plus si tu fais l'objet d'un fichage ciblé par les authorités tu t'exposes aussi à la conccurence et aux industriels qui ont certainement un regard critique sur l'hébérgement personnel chez soit (puisqu'il propose un modèle compétitif) et qui ne se généront certainement pas pour te cracher dessus ou descendre ton service.
C'est déloyal comme dirait l'APRIL.
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par n0wic . Évalué à -6. Dernière modification le 03 juin 2016 à 09:21.
Si on te dégrade les performances de ton applicatif de filtrage des porcs alors tu peu compromettre la sécurité du caractère privé des données d'un tiers dont tu as la responsabilité et cela que la requète vienne de l'état ou d'Alkaida que cela soit dicté par une idéologie ou par une directive ministérielle ou autre?!
Et ce caractère privé des données est sans doute le plus important pour des particuliers.
Que tu réagisses vite ou non fait partie de la problématique mais la disponibilité est secondaire à ce niveau et cela est impossible pour une personne lambda.
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par cyberjunkie . Évalué à 1.
Un applicatif de filtrage des porcs c'est pour faire quoi? Du saucisson?
Oui je sais… --->[]
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par n0wic . Évalué à -6.
D'aucun disent que tout est bon dans le cochon.
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par steph1978 . Évalué à 3.
Je partage.
Bande passante pas top.
Serveur sur le disjoncteur de la cuisinière.
Je n'auto-héberge que certains services.
Pour les plus critiques, j'utilise un serveur dédié chez OVH.
Comme toi, l'important pour moi est la maîtrise des données et de publier des services sur mon nom de domaine.
Que ça tourne sur un serveur chez moi n'est pas primordiale pour moi. Après tout, je ne possède/maîtrise pas infrastructure de mon fournisseur d'accès à Internet.
[^] # Re: L'autohebergement oui, l'ADSL non
Posté par benoar . Évalué à 4.
C'est toujours les même faux objectifs qui font planter la cause, comme pour le Libre : il faudrait être « aussi bien », voire « mieux » que le proprio, tout en étant gratuit et plus efficace. Ça n'est pas possible, il faut faire des concessions, les licornes n'existent pas. Et si ta préoccupation c'est de faire de la bonne « pub », je pense que tu pars du mauvais pieds, en te mettant un très mauvais objectif.
Donc oui, quand tu es auto-hébergé, ça va moins vite, mais au moins tu as tes données chez toi. Oui, tu ne partage pas de gros fichiers, tu fais attention, etc. Oui c'est chiant, mais on ne t'as jamais dit qu'être libre était facile. C'est comme ça, et toute personne qui essayera de trouver la solution « magique » le fera toujours au détriment d'autre chose, et souvent de la Liberté. Tu ne peux pas tout avoir, c'est tout. Et ça, les gens un minimum intelligents, ils le comprennent : ils n'ont pas besoin qu'on leur « vende » un truc chimérique, ils savent que tu n'as pas rien sans rien.
# question mail et DNS
Posté par steph1978 . Évalué à 2.
Dans 6.1. tu indiques une configuration DNS :
votredomaine.net A 109.190.193.182
votredomaine.net. MX 1 votredomaine.net.
Intuitivement j'aurai désigné explicitement mon serveur mail:
mail.votredomaine.net A 109.190.193.182
votredomaine.net. MX 1 mail.votredomaine.net.
Quelle est la bonne pratique ?
[^] # Re: question mail et DNS
Posté par Misc (site web personnel) . Évalué à 2.
je préfère avoir un serveur séparé, vu que 1) c'est plus clair 2) c'est plus rapide de migrer sur un serveur séparé.
Mais les 2 marchent, donc question de gout.
[^] # Re: question mail et DNS
Posté par steph1978 . Évalué à 3.
Je partage.
Quitte à avoir www et mail qui résolvent sur la même IP.
En plus, généralement, on aime bien avoir un alias de www vers vide pour que les visiteurs qui tapent juste le nom de domaine dans un navigateur tombent sur le site web.
qqch comme çà:
votredomaine.net CNAME www.votredomaine.net
mail.votredomaine.net A 109.190.193.182
www.votredomaine.net A 109.190.193.182
votredomaine.net. MX 1 mail.votredomaine.net.
[^] # Re: question mail et DNS
Posté par Thuban (site web personnel) . Évalué à 1.
Les deux sont valables. Désigner un "mail.domaine.com" est fréquent, une sorte de convention, mais ce n'est pas du tout nécessaire. Et comme j'ai voulu garder au plus simple, j'ai fait ce choix. Il y en a d'autres qui ne plairont pa aux puristes, mais j'ai prévenu, c'est pas pour les gens qui sont déjà formés aux subtilités.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.