Peur de tout basculer sur un serveur dédié !

WRInaute occasionnel
bonjour
j'ai autour de 8 sites avec autour de 3000 VU/j .
pour l'instant mes 8 sites sont réparties sur 2 mutualisé 1and1
j'ai un peu peur de basculer tous mes sites sur mon serveur dédié car quand s'il y a plantage du serveur,tous mes sites ne seront pas visibles .
et puis pour le référencement c'est pas tres conseillé.
d'après vous faut que je tranfère tout ou pas ?
 
WRInaute passionné
serval2a a dit:
Et il n'y a aucune contre-indication pour le ref. ;)
Je dirai même : "au contraire". La performance (rapidité d'affichage des pages) est (à mon avis personnel) un élément pris en compte par Google pour le positionnement.

Mais avant de passer au serveur dédié, tu peux toujours prendre un hébergement mutualisé "+ gros", genre Infomaniak par exemple.

Sinon; 2 solutions :
a. soit tu sais administrer un serveur dédié, tu as le temps, et donc tu t'en occupes toi même
b. soit tu ne sais pas administrer un dédié, alors tu le fais infogérer (payant)
 
WRInaute accro
Une bonne solution si tu a un peu de temps devant toi, c'est de prendre une vieille machine ou d'investir dans un truc pas cher en y mettant du linux et en t'en servant de machine de tests.
Cela te permettra notamment de tester une première fois les mises à jour que tu désire faire et d'éviter de te planter sur la machine de production en cassant tout ensuite.
 
WRInaute occasionnel
je connais un petit peu en dédié .j'y ai passé presque 2 mois à tester sur du kimsufi et apprendre linux .Vraiment prise de tête quand même.pas mal de bugs de compatibilité pour le passage du mutualisé vers le dédié .Un site marche impeccable sur du mutualisé et ne marche pas sur du dédié .Vraiment pénible à chercher d'ou vient les bugs.
j'ai pas encore fini de tout migrer j'hésite encore vu le nombre de bugs
 
WRInaute accro
bigs32 a dit:
Un site marche impeccable sur du mutualisé et ne marche pas sur du dédié .Vraiment pénible à chercher d'où vient les bugs.
ajoute error_reporting(E_ALL); dans ton code sur ton serveur de tests et tu verras plein d'erreurs apparaître. Quand elles seront corrigées tu ne devrais avoir quasiment plus d'erreurs sur ton dédié
 
WRInaute impliqué
sinon sans forcément par de l'infogérence, qui coute un max, tu te trouves une compétence qui va te compiler la même version de php avec les mêmes extensions, la même version d'apache, et aussi la même version de mysql, le tout à partir de ton phpinfo de ton mutualisé. C'est 2 / 3 heures de boulot max pour quelqu'un qui sait faire, après tu es tranquille, tu reprends la main sur ton serveur, pour les mises à jour de tes sites...
 
WRInaute accro
julienr a dit:
les mises à jour de sécurités des serveurs c'est un peu pour les banques, non ? :)
non, juste pour éviter que ton serveur ne se transforme en serveur de spam, de phishing, de propagation de virus, etc...
 
WRInaute impliqué
sans rentrer dans le détail si c'est juste un serveur apache (fail2banned) / ssh (sur un autre port) / mail (sans open relay), le risque il est plutôt du coté l'applicatif tout comme il pourrait l'être sur son mutualisé actuel ...
 
WRInaute accro
Euh même sans être une banque, il est indispensable de maintenir sa machine à jour.
Cependant avec une Debian et en installant les applications avec apt-get, un apt-get update et upgrade de temps en temps est bien suffisant.
 
WRInaute occasionnel
julienr a dit:
sinon sans forcément par de l'infogérence, qui coute un max, tu te trouves une compétence qui va te compiler la même version de php avec les mêmes extensions, la même version d'apache, et aussi la même version de mysql, le tout à partir de ton phpinfo de ton mutualisé. C'est 2 / 3 heures de boulot max pour quelqu'un qui sait faire, après tu es tranquille, tu reprends la main sur ton serveur, pour les mises à jour de tes sites...
merci julien pour cette astuce .et merci tout le monde
 
WRInaute impliqué
Bonjour,
kazhar a dit:
Euh même sans être une banque, il est indispensable de maintenir sa machine à jour.
Cependant avec une Debian et en installant les applications avec apt-get, un apt-get update et upgrade de temps en temps est bien suffisant.

ou "yum update" pour les Redhat :wink:
 
Nouveau WRInaute
Bonsoir,

Si je puis me permettre d'apporter quelques éclaircissements :

bigs32 a dit:
j'ai un peu peur de basculer tous mes sites sur mon serveur dédié car quand s'il y a plantage du serveur,tous mes sites ne seront pas visibles

Comme dis blman ; un serveur infogéré ne plante pas ; en fait pour être plus précis, un serveur infogéré ne plante pas sans raisons. N'oublions pas que, quelque soit le prestataire, l'infogérance inclue du monitoring pro-actif, c'est à dire qu'en cas de problème, une alerte se déclenche et le(s) technicien(s) en charge de l'infogérance de ton serveur vous intervenir...

SpeedAirMan a dit:
Sinon; 2 solutions :
a. soit tu sais administrer un serveur dédié, tu as le temps, et donc tu t'en occupes toi même
b. soit tu ne sais pas administrer un dédié, alors tu le fais infogérer (payant)

Les solutions infogérés sont en effet payantes dans 100% des cas où on fait entrer la notion de "sur-mesure".
Mais il existe aussi des solutions clef en mains où l'infogérance (mises à jours de sécurités, bugs et monitoring) est offerte.


Leonick a dit:
ajoute error_reporting(E_ALL); dans ton code sur ton serveur de tests et tu verras plein d'erreurs apparaître. Quand elles seront corrigées tu ne devrais avoir quasiment plus d'erreurs sur ton dédié

Les erreurs PHP (scripts hébergés) n'ont pas de rapport avec le "dédié" lui-même.
Je veux dire par là que, même si il est évidement conseillé d'avoir des scripts PHP qui génèrent peu ou pas d' erreurs PHP ; cela n'a rien a voir avec le dédié lui même. Le dédié va juste se "pré-occuper" de la charge généré par les scripts en questions, leurs consommations de mémoire, etc... et ces derniers point ne sont pas "visibles" avec les erreurs PHP.

julienr a dit:
les mises à jour de sécurités des serveurs c'est un peu pour les banques, non ? :)

J'ai bien peur que non, aujourd'hui, le problème numéro un ce sont les vers; des scripts qui se propagent de serveurs en serveurs en exploitant une ou plusieurs failles connues.

Inutile d'avoir un ennemi qui t'en veux pour que ton serveur soit hacké, ton site déffacé, etc... Il faut que les failles de sécurités connues soient corrigés.

Ceci dis, d'autres mises à jours sont elles aussi nécéssaires, prennons l'exemple de PHP et/ou MySQL en restant dans la même branche des fuites de mémoires sont corrigés, des traitements sont améliorés ou allégés, des bugs résolus...

Pour revenir un petit coup sur la sécurité, on notera que dans une partie non négligeables de cas, les serveurs sont hackés car les utilisateurs et/ou administrateur utilisent ou tolèrent des identifiants faibles ; avec des mots de passes triviaux... Attention donc à ce dernier point.


Voila...

--
David CHANIAL
 
WRInaute accro
DaviXX a dit:
Leonick a dit:
ajoute error_reporting(E_ALL); dans ton code sur ton serveur de tests et tu verras plein d'erreurs apparaître. Quand elles seront corrigées tu ne devrais avoir quasiment plus d'erreurs sur ton dédié

Les erreurs PHP (scripts hébergés) n'ont pas de rapport avec le "dédié" lui-même.
Je veux dire par là que, même si il est évidement conseillé d'avoir des scripts PHP qui génèrent peu ou pas d' erreurs PHP ; cela n'a rien a voir avec le dédié lui même.
sauf que sur le dédié, par défaut, le but est de n'autoriser les écritures que juste quand nécessaire et aux utilisateurs nécessaires (alors que sur des mutus, du moins chez OVH) on a un accès complet sur toute l'arborescence. Ce qui fait qu'une erreur d'écriture dans un répertoire, va se traduire par un temps d'exécution plus long (et des logs erreurs incroyables).
 
Nouveau WRInaute
Leonick a dit:
sauf que sur le dédié, par défaut, le but est de n'autoriser les écritures que juste quand nécessaire et aux utilisateurs nécessaires (alors que sur des mutus, du moins chez OVH) on a un accès complet sur toute l'arborescence. Ce qui fait qu'une erreur d'écriture dans un répertoire, va se traduire par un temps d'exécution plus long (et des logs erreurs incroyables).

Je ne suis pas sûr de te suivre.
Tel que je le comprends, je pense que tu fais erreur :

  • Pour commencer tu parlais d'erreurs PHP ; là tu parles plus préciséments d'erreurs décritures.
  • Ensuite une erreur d'écriture (comme je peux l'imaginer) ne sera pas plus lente ou plus rapide en fonction des droits que tu as dans l'arborescence.

Ce qui peux changer entre un serveur et un autre (un hébergeur ou un autre) c'est de savoir si php est exécuté en module (et donc avec les droits d'apache, généralement nobody:nobody) où bien si il est exécuté sous un uid dédié à chaque utilisateur grâce à suexec ou suphp.

Ou bien, en dernier lieu, le safe_mode de php permet de restreindre les fonctions de lectures/ecritures sur les fichiers hors d'un répertoire donné (en général le homedir de l'utilisateur concerné).

Mais encore une fois, sauf si tu as un exemple plus précis, je peux t'assurer que la majorité des erreurs qui apparaissent en faisant un error_reporting(E_ALL) ne sont pas liés a des erreurs entrainants une lenteur particulière sur un serveur dédié.

Tu as des infos plus précises sur le problème que tu énnonces ?

--
David CHANIAL
 
WRInaute accro
DaviXX a dit:
  • Pour commencer tu parlais d'erreurs PHP ; là tu parles plus préciséments d'erreurs décritures.
  • Ensuite une erreur d'écriture (comme je peux l'imaginer) ne sera pas plus lente ou plus rapide en fonction des droits que tu as dans l'arborescence.
un script php doit écrire dans un répertoire. Mais sur ce répertoire on n'a pas mis de droits suffisants pour l'écriture, ce qui fait que php va indiquer une erreur lors de son essai d'écriture avortée. Et si dans le programme, aucune exception n'est programmée, on va se retrouver à écrire dans un fichier qui n'a pas été ouvert, d'où, encore une erreur
Et quand on commence à utiliser certains scripts d'annuaires, par exemple, on est vite effaré par le nombre d'erreurs qui apparaissent dès que l'on met un error_reporting(E_ALL)
 
WRInaute impliqué
DaviXX a dit:
julienr a dit:
les mises à jour de sécurités des serveurs c'est un peu pour les banques, non ? :)
J'ai bien peur que non, aujourd'hui, le problème numéro un ce sont les vers; des scripts qui se propagent de serveurs en serveurs en exploitant une ou plusieurs failles connues.
[...]

c'est un peu la flippe çà pour quelqu'un qui voudrait se lancer et louer son premier dédié ... concrètement c'est quoi ce fléau ?
 
Nouveau WRInaute
Leonick a dit:
un script php doit écrire dans un répertoire. Mais sur ce répertoire on n'a pas mis de droits suffisants pour l'écriture, ce qui fait que php va indiquer une erreur lors de son essai d'écriture avortée. Et si dans le programme, aucune exception n'est programmée, on va se retrouver à écrire dans un fichier qui n'a pas été ouvert, d'où, encore une erreur
Et quand on commence à utiliser certains scripts d'annuaires, par exemple, on est vite effaré par le nombre d'erreurs qui apparaissent dès que l'on met un error_reporting(E_ALL)

Je comprends mieux le problème auquel tu pensais. Mais je ne suis toujours pas sûr que ça donne lieu à s'inquieter pour la lenteur du serveur.

Le script va renvoyer des echecs - visibles même sans faire error_reporting(E_ALL). Et effectivement le script risque de tenter des écritures sur des fichiers qu'il n'a pas reussi a ouvrir. Mais au final l'application PHP ne rempliera pas son role et dans la plus part des cas, le webmaster devrait s'en rendre compte ; puis résoudre le problème.

Cependant dans ce cas, il faut sérieusement s'inquieter au sujet du développeur ; lorsque on développe un script on DOIS le faire avec certaines contraintes de qualité - entre autre - gérer les erreurs/exceptions ; et pour cela, on ne dois pas attendre de passer ou non sur un serveur dédié.

Pour finir, je dirais que même si les scripts "mal" développés sont utilisés sur un serveur dédié, il n'y a pas lieu de s'inquieter... Ou bien, si effectivement un ensemble de scripts arrivent a consommer toutes les ressources du serveur dédié ; jusqu'à le faire planter ; il n'y a pas lieu de remettre en question l'utilisation d'un serveur dédié, mais plutôt l'utilisation des scripts concernés :)

Voilà :)

--
David CHANIAL
 
Nouveau WRInaute
julienr a dit:
c'est un peu la flippe çà pour quelqu'un qui voudrait se lancer et louer son premier dédié ... concrètement c'est quoi ce fléau ?

Ce n'est pas un fléau, c'est juste le résultat d'un fait : lorsque une technologie (PHP, un serveur dédié, ...) est accéssible (grâce à son cout, sa documentation, ...) l'utilisateur pense qu'il à suffisement de compétences pour l'utiliser. Ceci n'a rien de critique, en un sens je pense que cela à de bon coté de manière globable ; mais une de ses facheuses conséquences c'est que on se retrouve avec des développeurs qui utilisent des scripts existants développés par d'autres ; et cela sans avoir un gage de qualité/sécurité.

Ces scripts là sont généralement OpenSource, et des failles de sécurités sont régulièrement découvertes ; jusque là pas de problèmes, si le webmaster joue bien son rôle, il se sera (par exemple) abonné au fil RSS, ou aux news des éditeurs des scripts qu'il utilise, et aura été notifié de l'existence d'une mise à jours de sécurités. Si cette mise à jours est appliqué assez rapidement ; on ne rencontre pas ou peu de soucis.

Mais la plus part du temps, ce n'est pas le cas, les scripts avec telle ou telle version ont des failles de sécurités connues, une poingée de développeurs macabres (j'exagère, c'est voulu) créent des scripts qui arrivent à exploiter ces failles ; et l'exploit conciste généralement à installer les dits scripts sur le compte vulnérable, pour en faire un nouveau point d'attaques pour d'autres exploits/scan flood.

Une bonne manière de réduire ça c'est de :
  • maintenir à jour vos scripts PHP
  • utiliser suphp sur votre serveur dédié pour isoler l'impact d'une vulnérabilité exploité sur l'un des comptes de votre serveur
  • Ne ré-inventez pas la roue, mais ne prennez pas le premier script qui semble répondre à votre besoin, recherchez sur google si la dernière version connue n'est pas exploitable, si la communauté autour de ce script est un minimum active, etc...
  • Infogérer ou faire infogérer votre serveur de manière à ce que - entre autre - en cas de hack, les comptes vulnérables soient détectés, néttoyés, et isolés. - Comme je le disais, dans le cas où vous seriez prêt à faire infogérer votre serveur dédié, il existe bien évidement des solutions sur-mesure payantes, mais il existe des solutions infogérés clef-en-main, gratuites, comme ServerGear

--
David CHANIAL
 
WRInaute impliqué
ah ok tu parles de pb applicatif donc tout comme cela pourrait être la cas sur son mutualisé actuel ... J'avais cru comprendre des vers qui s'attaquait au faille des derniers kernel, et là j'étais curieux d'en savoir plus, mais bon çà doit aussi exister ...
 
WRInaute accro
DaviXX a dit:
Pour finir, je dirais que même si les scripts "mal" développés sont utilisés sur un serveur dédié, il n'y a pas lieu de s'inquieter... Ou bien, si effectivement un ensemble de scripts arrivent a consommer toutes les ressources du serveur dédié ; jusqu'à le faire planter ; il n'y a pas lieu de remettre en question l'utilisation d'un serveur dédié, mais plutôt l'utilisation des scripts concernés :)
entièrement d'accord. En fait, je répondais à
bigs32 a dit:
pas mal de bugs de compatibilité pour le passage du mutualisé vers le dédié .Un site marche impeccable sur du mutualisé et ne marche pas sur du dédié .Vraiment pénible à chercher d'ou vient les bugs.
j'ai pas encore fini de tout migrer j'hésite encore vu le nombre de bugs
et c'était pour, justement, montrer que le problème ne venait pas du dédié (ou alors certains paramétrages apache/php) mais plutôt des scripts.
 
Discussions similaires
Haut