meilleur hébergeur
Gerald
actualisation peut aussi être bienvenue :
Je souhaite faire migrer mes noms de domaines vers un nouvel hébergeur
(avec sites associés, boites mail et blog wordpress). Petit volume de
données et de transfert, c'est du "familial". Il y a 1 .fr et 2 .com
1/ que penser des gros hébergeurs genre ovh ou 1and1, dont les tarifs
sont vraiment 10 à 100 fois inférieurs à ceux des petits ? Leur taille
n'est-il pas aussi une sorte de gage de stabilité, finalement ?
2/ quels critères seraient un peu discriminants (en dehors du prix et
des volumes) ? Avez-vous des alternatives à proposer ?
3/ en cas de conflit avec l'actuel hébergeur susceptible de mettre de la
mauvaise volonté au transfert, quelle est "l'autorité" de régulation
censée l'obliger à se comporter correctement ? Quels points sont
critiques ?
Si j'ai bien compris ce que me racontait la correspondante d'ovh à fort
accent :-( ça se passe en trois temps : d'une part on s'abonne et on
fait migrer ses données par ftp chez ovg, ensuite on signale le nouveau
pointage de l'hébergement à l'actuel hébergeur, PUIS on fait migrer le
nom de domaine en *obtenant* le code d'authentification du nom de
domaine auprès de l'ancien hébergeur pour le communiquer à ovh. Il y a
alors une interruption de 4 à 24 h dans les services (en particulier de
bàl). Pouvez-vous confirmer et préciser cette histoire de code
d'authentification ?
D'avance merci pour votre aide,
--
Gérald
Jean-Francois Ortolo
>
> 3/ en cas de conflit avec l'actuel hébergeur susceptible de mettre de la
> mauvaise volonté au transfert, quelle est "l'autorité" de régulation
> censée l'obliger à se comporter correctement ? Quels points sont
> critiques ?
>
Bonjour Monsieur
A mon avis, le point crucial, est qu'il ne faut pas avoir un
registrar ( pour le nom de domaine ), identique à l'hébergeur.
En ce qui me concerne, j'étais chez ovh il y a quelques années, *et*
mon nom de domaine ortolojf-courses.com , était enregistré chez mon
registrar Gandi.
Quand j'ai migré mon site chez Sivit ( en mutualisé aussi ), je n'ai
eu aucun problème de migration ni d'autorisation à avoir.
J'ai fait comme vous dites, je me suis abonné à Sivit, j'ai placé les
scripts de mon site sur l'arborescence de l'espace web que j'avais, avec
mon compte ftp Sivit, et puis j'ai déclaré à Gandi, que les deux
serveurs de noms DNS ( Domain Name Server ), n'étaient plus ceux de ovh,
mais ceux de Sivit.
Pour Gandi, chaque hébergeur a un identifiant Gandi, que j'ai
modifié, et j'ai spécifié sur mon compte Gandi, les serveurs de noms et
l'identifiant de Sivit, et 48h après ( temps de propagation des DNS sur
la planète ), mon site était accessible correct sur son nouvel hébergement.
Je conseille à tout webmaster, le site et son forum suivant :
www.webrankinfo.com , qui est *la* référence Française en matière de
référencement auprès des moteurs de recherche, et de webmastering.
Inscription gratuite, tout gratuit.
Plus récemment, en Septembre 2008, j'ai migré mon site, du ndd
ortolojf-courses.com , vers le ndd pronostics-courses.fr ( voir
signature ). Je possède donc ces deux nom de domaine chez Gandi.
Bien à vous.
Amicalement.
Jean-François Ortolo
--
Visitez mon site gratuit donnant des Statistiques,
des Pronostics et des Historiques Graphiques
sur les Courses de Chevaux:
http://www.pronostics-courses.fr
Denis Beauregard
écrivait dans fr.comp.infosystemes.www.auteurs:
>domaine auprès de l'ancien hébergeur pour le communiquer à ovh. Il y a
>alors une interruption de 4 à 24 h dans les services (en particulier de
>bàl). Pouvez-vous confirmer et préciser cette histoire de code
>d'authentification ?
En fait, il n'y a pas d'interruption. Durant une période qui pourrait
atteindre 3 jours (mais cela fait longtemps que je n'ai pas changé
d'hébergeur), le visiteur pourra tomber sur l'ancien ou le nouveau
serveur. Donc, si l'ancien site est toujours en fonction, et que le
nouveau site est identique, il ne verra pas la différence et ne
saura même pas qu'il y a un changement de serveur.
Pour la messagerie, il convient d'utiliser une adresse alternative
durant cette période, mais pour la réception de message, c'est
aussi transparent (les messages se retrouvant sur l'un ou l'autre
serveur). Il vous faut donc obtenir le nom du serveur (sans votre
domaine) pour aller lire vos courriels sans utiliser le nom du
serveur.
Par ailleurs, comme autre point à vérifier, il y a les services
disponibles et certaines fonctions si on a des besoins précis.
Ainsi, sur mon serveur, je pouvais facilement envoyer une grosse
base de données (2 millions de lignes) mais avec un autre serveur,
il a fallu utiliser une méthode totalement différente parce qu'il
n'y avait plus le même service. Même si ce besoin n'est pas le
vôtre, il faudra que toutes les fonctions utilisées par votre
ancien serveur (comme wordpress) soient disponibles sur le nouveau
serveur ou en d'autres mots, il vous faudra faire le tour de tout
ce que permet votre site en ce moment, avant de transférer le nom
de domaine. Il faudra aussi trouver les BDD utilisées par Wordpress
et les envoyer au nouveau site (et se rappeler que les messages
saisis lors du changement de serveur pourront être sur l'un ou
l'autre serveur, donc il est préférable de désactiver l'ancien).
Denis
Lea Gris
> Le Tue, 28 Sep 2010 18:18:53 +0200, Ger...@alussinan.org (Gerald)
> écrivait dans fr.comp.infosystemes.www.auteurs:
>
>> domaine auprès de l'ancien hébergeur pour le communiquer à ovh. Il y a
>> alors une interruption de 4 à 24 h dans les services (en particulier de
>> bàl). Pouvez-vous confirmer et préciser cette histoire de code
>> d'authentification ?
>
> En fait, il n'y a pas d'interruption. Durant une période qui pourrait
> atteindre 3 jours (mais cela fait longtemps que je n'ai pas changé
> d'hébergeur), le visiteur pourra tomber sur l'ancien ou le nouveau
> serveur. Donc, si l'ancien site est toujours en fonction, et que le
> nouveau site est identique, il ne verra pas la différence et ne
> saura même pas qu'il y a un changement de serveur.
Petite astuce utile si vous utilisez Apache. Ajoutez un .htaccess sur
l'ancien hébergement :
RedirectMatch 307 ^().*)$ http://www.example.com/~username$1
example.com étant le nom générique du nouvel hébergement http utilisable
sans le nom de domaine avec le nom de l'utilisateur.
Ainsi, les visiteurs qui se retrouveraient avec les anciens
enregistrements DNS se verraient notifier une redirection temporaire
(307) vers une URL de remplacement donnant accès au nouvel hébergement
sans utiliser le nom de domaine.
Pour les malheureux visiteurs en retard, la redirection est transparente.
Pour les moteurs de recherches, la redirection temporaire permet de
parcourir le site tout en indiquant de ne pas conserver l'URL de
redirection.
Si jamais vous changez de nom de domaine, préférez une redirection
premanente :
RedirectMatch 301 ^().*)$ http://www.example.com$1
où example.com est le nouveau nom de domaine.
--
Léa Gris
Lea Gris
> écrivait dans fr.comp.infosystemes.www.auteurs:
>
>> domaine auprès de l'ancien hébergeur pour le communiquer à ovh. Il y a
>> alors une interruption de 4 à 24 h dans les services (en particulier de
>> bàl). Pouvez-vous confirmer et préciser cette histoire de code
>> d'authentification ?
>
> En fait, il n'y a pas d'interruption. Durant une période qui pourrait
> atteindre 3 jours (mais cela fait longtemps que je n'ai pas changé
> d'hébergeur), le visiteur pourra tomber sur l'ancien ou le nouveau
> serveur. Donc, si l'ancien site est toujours en fonction, et que le
> nouveau site est identique, il ne verra pas la différence et ne
> saura même pas qu'il y a un changement de serveur.
Petite astuce utile si vous utilisez Apache. Ajoutez un .htaccess sur
l'ancien hébergement :
RedirectMatch 307 ^(.*)$ http://www.example.com/~username$1
example.com étant le nom générique du nouvel hébergement http utilisable
sans le nom de domaine avec le nom de l'utilisateur.
Ainsi, les visiteurs qui se retrouveraient avec les anciens
enregistrements DNS se verraient notifier une redirection temporaire
(307) vers une URL de remplacement donnant accès au nouvel hébergement
sans utiliser le nom de domaine.
Pour les malheureux visiteurs en retard, la redirection est transparente.
Pour les moteurs de recherches, la redirection temporaire permet de
parcourir le site tout en indiquant de ne pas conserver l'URL de
redirection.
Si jamais vous changez de nom de domaine, préférez une redirection
premanente :
RedirectMatch 301 ^(.*)$ http://www.example.com$1
Patrick Mevzek
> Leur taille n'est-il pas aussi une sorte de gage de stabilité,
> finalement ?
Vous connaissez Enron ?
Worldcom ?
Bernard Madoff ?
Lehman Brothers ?
General Motors ?
> 2/ quels critères seraient un peu discriminants (en dehors du prix et
> des volumes) ?
Le support, probablement, selon vos besoins (canal, rapidité, etc.)
> 3/ en cas de conflit avec l'actuel hébergeur susceptible de mettre de la
> mauvaise volonté au transfert, quelle est "l'autorité" de régulation
> censée l'obliger à se comporter correctement ? Quels points sont
> critiques ?
De toute façon normalement vous devez avoir une copie locale de toutes
vos données, ne serait-ce que parce que vous faites des sauvegardes
régulières et automatiques. Et si ce n'est pas le cas, courrez en faire.
Donc vous n'avez rien besoin de récupérer chez l'ancien.
Le problème peut se poser pour le transfert des noms de domaine.
A noter que vous pouvez très bien changer d'hébergeur sans transférer vos
noms de domaine, ce sont deux services disjoints même s'ils sont souvent
empaquetés ensemble commercialement. Cela peut être un inconvénient ou un
avantage d'avoir tout au même endroit...
> Il y a
> alors une interruption de 4 à 24 h dans les services (en particulier de
> bàl).
Pas forcément, il peut n'y avoir aucune interruption selon comment les 2
hébergeurs travaillent.
> Pouvez-vous confirmer et préciser cette histoire de code
> d'authentification ?
Pour les noms de domaine, selon les extensions (mais c'est le cas de nos
jours en .FR et .COM qui vous intéressent), chaque domaine a un «
authcode » ou « authInfo » ou « code EPP » ou « code d'authentification »
qui dénotent tous la même chose.
C'est une chaîne de caractères que doit vous donner le gestionnaire de
vos noms de domaine (cela peut être visible en ligne directement dans
votre interface d'administration), et le nouveau gestionnaire chez qui
vous transférez vos noms ne peut même pas techniquement entamer la
procédure sans connaissance de ce code.
Si vous avez des difficultés à récupérer le code de l'ancien fournisseur,
vous devriez déjà en profiter pour tester le support technique du nouveau
fournisseur qui devrait vous aider dans cette démarche.
Sinon, au final, il faut voir avec le registre concerné (donc l'AFNIC
pour le .FR) ou l'autorité de "régulation", à savoir l'ICANN pour les .COM
Mais si le problème se pose, le bon canal de discussion serait plutôt
fr.reseaux.internet.hebergement
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
<http://www.dotandco.net/ressources/icann_registrars/prices>
<http://icann-registrars-life.dotandco.net/>
Gerald
> Mais si le problème se pose, le bon canal de discussion serait plutôt
> fr.reseaux.internet.hebergement
Merci à vous et aux autres pour vos réponses documentées et pertinentes.
Cette dernière remarque est évidemment la cerise sur le gâteau et je
vais immédiatement m'abonner à ce forum (dont j'avais zappé l'existence)
pour en apprendre un peu plus sur les problèmes rencontrés par d'autres
dans ce domaine.
Encore merci,
--
Gérald
Olivier Masson
> Le Tue, 28 Sep 2010 18:18:53 +0200, Gerald a écrit:
>> Leur taille n'est-il pas aussi une sorte de gage de stabilité,
>> finalement ?
>
> Vous connaissez Enron ?
> Worldcom ?
> Bernard Madoff ?
> Lehman Brothers ?
> General Motors ?
>
>> 2/ quels critères seraient un peu discriminants (en dehors du prix et
>> des volumes) ?
>
> Le support, probablement, selon vos besoins (canal, rapidité, etc.)
>
Pour la majorité des sites que je crée, un hébergement à 5 euros/mois
chez ovh est suffisant. Par contre, lorsqu'il y a un problème (et je
n'ai pas dit "s'il y a un problème"), certes on a une réponse plus
rapidement qu'avant, mais avoir une *solution*, c'est moins évident.
MySQL est très lent, mais je n'ai encore jamais testé les SQL privé d'ovh.
Quant à 1&1, par politesse j'éviterai d'en parler. Mais l'utilisation
pdt 30 secondes de leur interface en dit déjà long.
Gerald
> Quant ą 1&1, par politesse j'éviterai d'en parler. Mais l'utilisation
> pdt 30 secondes de leur interface en dit déją long.
Je viens de trouver une page qui me donne la migraine : le choix n'est
pas limité entre 1and1 et ovh :-(
<http://directory.google.com/Top/World/Fran%C3%A7ais/Informatique/Intern
et/Conception_et_d%C3%A9veloppement/H%C3%A9bergement/D%C3%A9di%C3%A9/>
<http://directory.google.com/Top/World/Fran%C3%A7ais/Informatique/Intern
et/Conception_et_d%C3%A9veloppement/H%C3%A9bergement/Mutualis%C3%A9/>
on reste calme et on essaie de poursuivre... zen !
--
Gérald
Williamhoustra
> Le sujet a certainement été déjà débattu ici vingt fois, mais une
> actualisation peut aussi être bienvenue :
>
> Je souhaite faire migrer mes noms de domaines vers un nouvel hébergeur
> (avec sites associés, boites mail et blog wordpress). Petit volume de
> données et de transfert, c'est du "familial". Il y a 1 .fr et 2 .com
>
correcte (sûr que le SDSL serait préférable en ce cas) tu peux
l'héberger d'athomique façon. Mon cas avec mon serveur expérimental
(des exemples de programmation) qui gère un site Web, un site FTP et un
serveur de mails. Mon registrar est Bookmyname (encore moins cher que
Gandhi). Bien sûr il te faut un système serveur sur une machine dédiée
et un routeur pour le NAT et après tout baigne.
Gerald
> Bien sûr il te faut un système serveur sur une machine dédiée
> et un routeur pour le NAT et après tout baigne.
Je te suis et j'ai d'ailleurs déjà tout ça opérationnel en test sur le
macMINI au coin de mon bureau (qui sert aussi de serveur d'impression,
de serveur de fichiers local, de machine à mouliner la vidéo en tâche de
fond, ou à enregistrer la télé etc.) MAIS je me pose une grosse question
concernant la consommation de bande passante. Pas de la part de mes
éventuels lecteurs volontaires qui, malgré toute l'énergie que je
déploie à essayer de faire quelque chose d'original, d'utile, de
constructif, de beau, et tout et tout... ne sont probablement qu'une
poignée, mais de la part des robots qui ratissent en permanence.
Quelqu'un aurait-il une idée du bruit de fond de base généré par ces
robots sur une page sans accroche particulière ? De quoi peut dépendre
leur férocité ?
J'ai une connexion ADSL correspondant à mon implantation campagnarde et
ravitaillée par les corbeaux : 2 Mo.
De quoi disposes-tu et quelle est l'incidence de ton propre hébergement?
--
Gérald
Williamhoustra
> Williamhoustra <william...@trapellun.net> wrote:
>
>> Bien sûr il te faut un système serveur sur une machine dédiée
>> et un routeur pour le NAT et après tout baigne.
>
> Je te suis et j'ai d'ailleurs déjà tout ça opérationnel en test sur le
> macMINI au coin de mon bureau (qui sert aussi de serveur d'impression,
> de serveur de fichiers local, de machine à mouliner la vidéo en tâche de
> fond, ou à enregistrer la télé etc.) MAIS je me pose une grosse question
> concernant la consommation de bande passante. Pas de la part de mes
> éventuels lecteurs volontaires qui, malgré toute l'énergie que je
> déploie à essayer de faire quelque chose d'original, d'utile, de
> constructif, de beau, et tout et tout... ne sont probablement qu'une
> poignée, mais de la part des robots qui ratissent en permanence.
>
> Quelqu'un aurait-il une idée du bruit de fond de base généré par ces
> robots sur une page sans accroche particulière ? De quoi peut dépendre
> leur férocité ?
>
> J'ai une connexion ADSL correspondant à mon implantation campagnarde et
> ravitaillée par les corbeaux : 2 Mo.
>
> De quoi disposes-tu et quelle est l'incidence de ton propre hébergement?
J'ai le pot d'avoir un ADSL top niveau chez Free car je ne suis pas
trop loin de la cahute DSLAM. J'ai donc mis mon petit serveur sur un
Core 2 Duo, un serveur 2008 R2 (tant qu'à faire), avec un serveur FTP
et un serveur de messagerie afin de simuler en vraie grandeur une
installation pro. On peut aller voir le site sur
http://www.pandemonium-web.net. Bien sûr, en tant que site
expérimental, tout n'est pas encore fonctionnel, d'autant que je l'ai
migré récemment. Mes essais par l'extérieur ont montré que l'accès
n'était pas ridicule de lenteur pour autant qu'on ne s'y bouscule pas.
Denis Beauregard
<william...@trapellun.net> écrivait dans
fr.comp.infosystemes.www.auteurs:
>Après mûre réflexion, Gerald a écrit :
>> Williamhoustra <william...@trapellun.net> wrote:
>>
>> Quelqu'un aurait-il une idée du bruit de fond de base généré par ces
>> robots sur une page sans accroche particulière ? De quoi peut dépendre
>> leur férocité ?
>>
> Très bonne question, mais je n'en ai aucune idée.
Les blogues sont visités souvent.
Il existe au moins une directive pour que les robots ne viennent pas
souvent.
En PHP, comme c'est interprété, le robot ne connaît pas la date de
création de la page.
Ceci dit, il y a des statistiques sur les robots avec certains
logiciels.
Sur mon site, 139272 pages vues et 166489 non vues (visitées par des
robots) mais ces chiffres changent à chaque mois.
Denis
Gerald
wrote:
> Il existe au moins une directive pour que les robots ne viennent pas
> souvent.
>
> En PHP, comme c'est interprété, le robot ne connaît pas la date de
> création de la page.
la deuxième phrase est la suite de la première ou la directive est-elle
"autre" et si oui laquelle ?
d'avance merci,
--
Gérald
Denis Beauregard
écrivait dans fr.comp.infosystemes.www.auteurs:
>Denis Beauregard <denis.b-at-franc...@nospam.com.invalid>
Ce sont des énoncés indépendants.
D'un côté, on peut ajouter une directive dans l'en-tête pour retarder
la prochaine visite d'un robot sur la page (pour les robots qui
suivent ces directives). Je ne connais pas cette directive mais je
suppose qu'en cherchant un peu, on peut la retrouver, à moins qu'un
expert ne la donne dans ce fil de discussion.
De l'autre, si le code est interprété (PHP, ASP, etc.), la date de la
page n'est pas celle du code car le contenu ne dépend pas de la page,
mais d'autres données.
Denis
Pierre-Alain Dorange
> > Il existe au moins une directive pour que les robots ne viennent pas
> > souvent.
> >
> > En PHP, comme c'est interprété, le robot ne connaît pas la date de
> > création de la page.
>
> la deuxième phrase est la suite de la première ou la directive est-elle
> "autre" et si oui laquelle ?
A ma connaissance il n'y a pas de directive pour retarder la visite...
Il existe par contre le fichier robots.txt ou la directive "robot" qui
permet d'indiquer si il faut ou pas indexer la page et/ou suivre les
liens :
<http://naxos.biomedicale.univ-paris5.fr/rg/?Robots>
Mais cela reste à la discrétion du robot qui n'a aucune obligation de
suivre la directive.
Après si c'est pour retarder tu peux essayer de jouer avec les dates de
mises à jour du fichiers HTML, mais là encore tout les robots ne sont
pas égaux et ils n'utilisent pas forcément cette date...
Quand aux pages généré en PHP elle ont aussi une date de page, qui
normalement (si le moteur php est standard) correspond au moment de la
création de la page par le script PHP.
--
Pierre-Alain Dorange <http://microwar.sourceforge.net/>
Ce message est sous licence Creative Commons "by-nc-sa-2.0"
<http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>
Jean-Francois Ortolo
Bonsoir
Excusez-moi.
Ne serait-ce pas le meta tag : "revisit-after :" ?
En ce qui me concerne, je n'ai jamais tenté de "réguler" les visites
de robots.
Il est vrai que "revisit-after :" ne répondrait pas à ce que vous
souhaitez, puisque ça définit seulement le délai minimum entre chaque
visites de robot d'un moteur de recherche déterminé.
Voili, voulou.
Olivier B
> Gerald <Ger...@alussinan.org> wrote:
>
>>> Il existe au moins une directive pour que les robots ne
>>> viennent pas souvent.
>>>
>>> En PHP, comme c'est interprété, le robot ne connaît pas la date
>>> de création de la page.
Tout dépend comment tu gères tes en-têtes.
> A ma connaissance il n'y a pas de directive pour retarder la
> visite...
Tu as sitemap qui permet de signaler au robot qui va le chercher
quelle est la période de mise à jour de chaque page.
C'est reconnu par google et, il me semble, par quelques autres.
--
Olivier B
<http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html>
Olivier Miakinen
Le 01/10/2010 17:49, Pierre-Alain Dorange répondait à Gerald :
>> >
>> > En PHP, comme c'est interprété, le robot ne connaît pas la date de
>> > création de la page.
>>
> A ma connaissance il n'y a pas de directive pour retarder la visite...
> [...]
>
> Après si c'est pour retarder tu peux essayer de jouer avec les dates de
> mises à jour du fichiers HTML, mais là encore tout les robots ne sont
> pas égaux et ils n'utilisent pas forcément cette date...
>
> Quand aux pages généré en PHP elle ont aussi une date de page, qui
> normalement (si le moteur php est standard) correspond au moment de la
> création de la page par le script PHP.
En PHP, il est tout-à-fait possible en principe de préciser à la fois la
date de dernière modification d'une page et sa date d'expiration :
<http://www.php.net/manual/fr/function.header.php#94646>.
De mémoire, on doit pouvoir jouer aussi sur des paramètres de cache
(Cache-Control, Etag, etcsdc que je ne maîtrise absolument pas).
Cordialement,
--
Olivier Miakinen
Denis Beauregard
(Pierre-Alain Dorange) écrivait dans fr.comp.infosystemes.www.auteurs:
>Quand aux pages généré en PHP elle ont aussi une date de page, qui
>normalement (si le moteur php est standard) correspond au moment de la
>création de la page par le script PHP.
Et normalement, la page est générée lors de la visite de cette page,
donc la date est la date courante. Je viens de regarder sur mon site
et la page d'accueil, modifiée il y a au moins quelques semaines, a
comme date celle d'aujourd'hui.
Denis