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

Discussion dans 'Administration d'un site Web' créé par bigs32, 11 Février 2009.

  1. bigs32
    bigs32 WRInaute occasionnel
    Inscrit:
    8 Mai 2006
    Messages:
    451
    J'aime reçus:
    0
    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 ?
     
  2. blman
    blman WRInaute accro
    Inscrit:
    5 Septembre 2003
    Messages:
    2 740
    J'aime reçus:
    2
    Si un dédié est bien infogéré, il ne plante pas. Donc aucune crainte à ce sujet.
     
  3. serval2a
    serval2a WRInaute accro
    Inscrit:
    21 Mars 2005
    Messages:
    2 578
    J'aime reçus:
    0
    Salut,
    Et il n'y a aucune contre-indication pour le ref. ;)
     
  4. SpeedAirMan
    SpeedAirMan WRInaute passionné
    Inscrit:
    2 Juin 2007
    Messages:
    2 391
    J'aime reçus:
    0
    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)
     
  5. dmathieu
    dmathieu WRInaute accro
    Inscrit:
    9 Janvier 2004
    Messages:
    5 626
    J'aime reçus:
    0
    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.
     
  6. bigs32
    bigs32 WRInaute occasionnel
    Inscrit:
    8 Mai 2006
    Messages:
    451
    J'aime reçus:
    0
    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
     
  7. Leonick
    Leonick WRInaute accro
    Inscrit:
    8 Août 2004
    Messages:
    19 417
    J'aime reçus:
    0
    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é
     
  8. julienr
    julienr WRInaute impliqué
    Inscrit:
    5 Août 2003
    Messages:
    941
    J'aime reçus:
    0
    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...
     
  9. Leonick
    Leonick WRInaute accro
    Inscrit:
    8 Août 2004
    Messages:
    19 417
    J'aime reçus:
    0
    oui mais il retrouvera les mêmes problèmes quand il faudra faire des mises à jour de sécurité des serveurs.
     
  10. julienr
    julienr WRInaute impliqué
    Inscrit:
    5 Août 2003
    Messages:
    941
    J'aime reçus:
    0
    les mises à jour de sécurités des serveurs c'est un peu pour les banques, non ? :)
     
  11. Leonick
    Leonick WRInaute accro
    Inscrit:
    8 Août 2004
    Messages:
    19 417
    J'aime reçus:
    0
    non, juste pour éviter que ton serveur ne se transforme en serveur de spam, de phishing, de propagation de virus, etc...
     
  12. julienr
    julienr WRInaute impliqué
    Inscrit:
    5 Août 2003
    Messages:
    941
    J'aime reçus:
    0
    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 ...
     
  13. dmathieu
    dmathieu WRInaute accro
    Inscrit:
    9 Janvier 2004
    Messages:
    5 626
    J'aime reçus:
    0
    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.
     
  14. bigs32
    bigs32 WRInaute occasionnel
    Inscrit:
    8 Mai 2006
    Messages:
    451
    J'aime reçus:
    0
    merci julien pour cette astuce .et merci tout le monde
     
  15. Topsitemaker
    Topsitemaker WRInaute impliqué
    Inscrit:
    19 Novembre 2006
    Messages:
    536
    J'aime reçus:
    0
    Bonjour,
    ou "yum update" pour les Redhat :wink:
     
  16. DaviXX
    DaviXX Nouveau WRInaute
    Inscrit:
    14 Août 2005
    Messages:
    23
    J'aime reçus:
    0
    Bonsoir,

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

    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...

    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.


    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.

    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
     
  17. Leonick
    Leonick WRInaute accro
    Inscrit:
    8 Août 2004
    Messages:
    19 417
    J'aime reçus:
    0
    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).
     
  18. DaviXX
    DaviXX Nouveau WRInaute
    Inscrit:
    14 Août 2005
    Messages:
    23
    J'aime reçus:
    0
    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
     
  19. Leonick
    Leonick WRInaute accro
    Inscrit:
    8 Août 2004
    Messages:
    19 417
    J'aime reçus:
    0
    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)
     
  20. julienr
    julienr WRInaute impliqué
    Inscrit:
    5 Août 2003
    Messages:
    941
    J'aime reçus:
    0
    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 ?
     
  21. DaviXX
    DaviXX Nouveau WRInaute
    Inscrit:
    14 Août 2005
    Messages:
    23
    J'aime reçus:
    0
    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
     
  22. DaviXX
    DaviXX Nouveau WRInaute
    Inscrit:
    14 Août 2005
    Messages:
    23
    J'aime reçus:
    0
    Doublon. A Supprimer.
     
  23. DaviXX
    DaviXX Nouveau WRInaute
    Inscrit:
    14 Août 2005
    Messages:
    23
    J'aime reçus:
    0
    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
     
  24. julienr
    julienr WRInaute impliqué
    Inscrit:
    5 Août 2003
    Messages:
    941
    J'aime reçus:
    0
    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 ...
     
  25. Leonick
    Leonick WRInaute accro
    Inscrit:
    8 Août 2004
    Messages:
    19 417
    J'aime reçus:
    0
    entièrement d'accord. En fait, je répondais à
    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.
     
Chargement...
Similar Threads - Peur basculer serveur Forum Date
developpeur web et web mobile Développement d'un site Web ou d'une appli mobile 6 Février 2020
Responsabilité du développeur dans la mise en conformité CNIL en terme de sécurité des mots de passe Droit du web (juridique, fiscalité...) 13 Janvier 2020
Rech developpeur Wordpress pour optimisation perf Développement d'un site Web ou d'une appli mobile 16 Avril 2019
2 sites d'une entreprise pour 2 localités - peur de duplicate content Référencement Google 21 Octobre 2016
Recherche formation Prestashop (développeur) Le café de WebRankInfo 6 Mars 2016
Besoin d'aide : Enquête Développeurs et SEO ;) Débuter en référencement 11 Janvier 2016
Développeur, va en fraude dans l'admin de son client qui lui en avais interdit l'accès Droit du web (juridique, fiscalité...) 23 Novembre 2015
Droits d'exploitation développeur Droit du web (juridique, fiscalité...) 19 Mai 2015
Site perso - Développeur Web Demandes d'avis et de conseils sur vos sites 11 Mai 2015
Apports en industrie / Web Développeur Droit du web (juridique, fiscalité...) 10 Avril 2015