Jump to content

Ovh le serveur plante


Recommended Posts

Bonjour

De temps en temps, je dirais une fois par mois maxi 2, mon dédié plante, si je suis présent je me rends sur manager puis j'effectue un reboot, puis il redémarre,

parfois comme ce matin il plante, je reçois le mail de monitoring et 10 minutes après, il redémarre alors qu'aucun technicien d'Ovh n'est intervenu

avez-vous aussi ce genre de problème, comment connaitre la cause de cela (Plesk)

dans l'attente de votre aide

Cordialement

TrocWeb

Link to comment
Share on other sites

As tu regardé si un de tes softs ne générait pas une erreur dans le /var/log ?

Personnellement, un serveur entier qui plante, je n'ai jamais eu ca par contre, un processus qui tombe, la oui ;)

EDIT: regarde aussi plus particulièrement dans le /var/log/messages Tu dois trouver des infos sur ce qui aurait (si c'est le cas) pu planté ton kernel ;)

Link to comment
Share on other sites

merci pour ton aide

un beau charabia ce fichier lolll

de ce que je connais il y a des tentatives de connection FTP en grand nombre

puis le server redemarre

May 21 09:04:32 nsxxxx proftpd[21740]: nsxxx.ovh.net (85.114.135.137[85.114.135.137]) - FTP session opened.

May 21 09:04:32 nsxxx proftpd[21740]: nsxxx.ovh.net (85.114.135.137[85.114.135.137]) - FTP session closed.

May 21 10:05:05 nsxxxx syslogd 1.4.1: restart.

et plein de d'éssai de log Root

May 21 03:59:25 nsxxx sshd[22686]: Authentication started for user root

May 21 03:59:29 nsxxxx sshd(pam_unix)[22705]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=212.150.133.249 user=root

May 21 03:59:29 nsxxxx sshd[22705]: Authentication started for user root

May 21 03:59:32 nsxxxx sshd(pam_unix)[22724]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=212.150.133.249 user=root

May 21 03:59:32 nsxxxxx sshd[22724]: Authentication started for user root

May 21 03:59:36 nsxxxxx sshd(pam_unix)[22744]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=212.150.133.249 user=root

Edited by TrocWeb
Link to comment
Share on other sites

Oui ce genre de chose arrive souvent avec un serveur (je parle des attaques ;) )

Moi par securité je met déja mon ssh sur un autre port mais en restant prudent avec ca ;) Genre garder un shell root ouvert a côté en cas de mauvaise manipulation...

Tu as souvent des robots qui scannent le port 22 pour trouver des machines mal sécurisées.

Par exemple laisser le root en acces direct par ssh sans passer par un simple utilisateur suivi d'un su ou encore, d'utiliser des mots de pass faciles (dictionnaire).

Pour le FTP, moi j'utilise vsftpd pcq j'avais eu une sale blague en debian 3.1 avec proftpd mais bon, maintenant je sais qu'il marche bien ;)

En fait il me lancait des thread mais ne les coupaient pas...

Par contre de la a aller planter ta machine ainsi, ca me semble assez spécial...

Essaie un ps aux | grep proftpd pour voir si il tue bien les thread qu'il peut lancer. Si tu vois une liste de 3km, la je crois qu'il y a souci...

Je dis ca par expérience pcq ce que je suppose sans pour autant être celà, ca serait une saturation de la ram par des thread non arrêtés.

Aussi, regarde l'ip qui cause cela a chaque fois et regarde si c'est la même ou si jamais elle est dynamique, de chez quel FAI ca provient.

Si c'est toujours la même et quelle est statique, moi je la mettrais dans iptables le temps que la tempête passe...

EDIT: oula sorry, je viens de voir, regarde l'heure entre la dernière tentative FTP et ton restart, je viens seulement de voir :-/

Ca laisse quasi une heure... A mon avis, ca n'est pas ca...

Quand tu as redémarré ton serveur, tu l'as bien fait a 10h05? C'est juste pour moi être certain que ca vient de toi...

Link to comment
Share on other sites

pas simple tous ca... :mad2:

quand le site décollera et générera des rentrés (car gratuit en ce moment) , je passerai par l'infogérance de Dan, j'en profiterai pour passer sur un offre encore plus puissant ce jour la

dans l'immédiat faut que je parade a tous cela :shutup:

Link to comment
Share on other sites

Oui c'est sur mais n'ayant jamais rencontré un tel problème, j'essaie aussi de trouver une solution... :unsure:

Tu sais a quelle heure ton serveur a planté exactement ou du moins, quand il ne répondait plus?

Link to comment
Share on other sites

oui à 10 h et des...

par contre j'ai taper ta commande ps aux | grep proftpd (tel que) et me dit bad command (j'ai surement fait une boulette :sick: )

edit cest pas: ps -aux ?

Edited by TrocWeb
Link to comment
Share on other sites

Hmmm... pourtant chez moi, elle passe sans souci...

C'est sous quelle distribution que tu es?

Un truc m'étonne, c'est que si tu avais eu un kernel panic ou autre, on devrait trouver plus d'informations je pense.

Je ne sais pas si tu sais récupérer ton /var/log/messages , /var/log/auth.log et celui de proftpd.

Je veux bien les éplucher chez moi tranquillement pour voir si je trouve quelque chose dedans...

EDIT: ps -aux va aussi mais il me sort une erreur de syntaxe du ou - devant le aux chez moi sous une debian...

Link to comment
Share on other sites

En cinq minutes peut-être pas.

Mais j'ai eu un serveur infogéré qui rebootait sans raison toutes les heures... :(

Un simple changement de noyau pour un noyau avec grsecurity a résolu son problème.

Link to comment
Share on other sites

Ha je ne connaissais pas grsecurity :P

Faudra que je regarde ca quand j'aurai fini mon blocus ;)

"A restriction that allows a user to only view his/her processes"

Waiiii je cherchais justement comment ils faisaient ca chez OVH !

Merci Dan ! :D

Link to comment
Share on other sites

salut Dan

comme l'indique Gecko64

la mémoire est peut-être saturé, enfin je ne sais pas trop, ce reboot et aléatoire.. une fois par mois, 2 ou 3 fois par mois, parfois 2 mois sans rien, je pense donc qu'à un moment ou à un autre, une sécurité et touché et le serveur se coupe automatiquement, enfin c'est mon avis, j'ai transmis le fichier messages à Gecko64 qui est surement plus calé que moi

pour ce qui concerne le changement de noyaux lol..... heuuuuuu, quand je passerais commande à ton niveau tu pourras éventuellement t'en occuper, car, pour moi .....,je viens de jeter un oeil :sick: ... je vais m'en passer :shutup:

Edited by TrocWeb
Link to comment
Share on other sites

J'ai regardé mais je vois rien de spécial... :nonono:

Avant chaque redémarrage du système, on a toujours des événements différents...

Une fois c'est une tentative de résolution de DNS qui échoue, une autre fois c'est une tentative d'intrusion ssh par dictionnaire ou encore par FTP...

L'idéal je crois serait de voir tous les log du /var/log ;)

Ca me donnerait plus d'informations pour chercher une cause pouvant aboutir à ce genre d'ennui...

Pour la compilation d'un kernel, oui il vaut mieux tester ca sur un PC de test à domicile avant de se lancer la dedans, crois moi :D

Je m'y suis moi même plusieurs fois brulé les ailes au début ;)

Link to comment
Share on other sites

merci pour ton aide

je vais te joindre le fichier demandé, pour ce qui est de changer le noyau....... oublions cela :sick:

Edi: je n'ai pas de fichier log

Edited by TrocWeb
Link to comment
Share on other sites

Non je parlais du dossier /var/log complet ;)

Tu fais une archive tar et ainsi dedans je pourrai consulter les log de tous les services qui tournent pour voir si ca n'est pas un d'entres eux qui est en cause... ;)

N'oublie pas de la compresser avant, ca compresse bien le texte :P sinon ca risque de peser lourd :-/

Link to comment
Share on other sites

Oui je sais... :-/ C'est pour ca qu'il est mieux de compresser en créant l'archive pour que cela prenne beaucoup moins de place :unsure:

Sinon, je te fais un accès sur un PC chez moi et on se le file en scp ;)

Ca permet de faire des transfères de données entre 2 serveurs au travers un tunnel sécurisé (ssh) :)

Link to comment
Share on other sites

non t'embête pas je vais te le mettre sur le ftp ........

question n'y a t-il pas des donnés sensibles dans ce dossier comme des mots de pass utilisateurs, root ou autres... ?

Link to comment
Share on other sites

A ma connaissance non...

Les fichiers sensibles en général sont /etc/shadow et /etc/passwd ainsi que ceux qui sont pour la db mysql dans /var/lib/mysql

Le /etc/shadow contient en fait la liste des utilisateurs du système et il est en lien intime avec /etc/passwd qui lui contient les mots de pass des utilisateurs.

A l'époque, les mots de pass étaient aussi dans /etc/shadow mais par sécurité, cela a été modifié vers un autre fichier.

Le /var/log lui contient que des logs système sans plus... ;) Ce sont juste des événements qui viennent des différents processus tournant sur ton système.

Tiens, je te met la commande scp si tu veux regarder:

scp -r /var/log user_AT_host:/rep/ou/fichier/distant

-r c'est quand on veut copier un répertoire complet d'un serveur vers un autre :) Dans notre exemple, il s'agira du dossier /var/log

user étant l'utilisateur distant et le host est l'ip du serveur distant sur lequel on veut envoyer les données.

Ensuite, il y a juste a respecter l'arborescence des répertoires ;)

Pour le ftp ca va alors mais je ne promet pas de regarder ce soir pcq il se fait déjà un peu tard ^^

EDIT: A mon avis tu n'es pas sous Linux Debian pcq le dossier de log apache est httpd chez toi alors que sous Debian, ils le nomme tout simplement apache2.

C'est une Fedora même.

Enfin ca ne change rien, du linux et des log ca reste le même.

Je jette un oeil rapidement.

EDIT2: Apparemment ton souci daterait du 12 aout 2007 si je ne me trompe pas.

070812 11:05:50 InnoDB: Database was not shut down normally!

On remarque que mysql a plusieurs reprise a été mal arrêté dans le fichier de log.

Je vois plusieurs causes possibles comme un kernel panic ou alors une saturation des ressources qui entrainerait le plantage complet du système...

Je vais consulter le reste et donnerai des news si je trouve du nouveau, ou pas...

EDIT3: J'ai bon faire le tour de tout les log, on voit juste qu'il se coupent brusquement a des moments mais sans laisser la moindre trace.

Je me demande si la machine ne nous fait pas un kernel panic.

Sinon note au passage, tu en ramasses des attaques pour rentrer par phpmyadmin, xamp et j'en passe.

Ce genre de chose quand je le met sur un serveur, je sécurise toujours par un htacces par dessus.

Une webradio ou j'étais admin adjoint avait eu ce genre de souci sauf que la, on s'était fait avoir. Enfin, ca n'était pas la partie du serveur que je gérais :P

Link to comment
Share on other sites

merci pour tes analyses

il est normalement impossible de ce connecter sur phpmyadmin sans passer par le plesk, j' ai essayé à plusieurs reprises, je n'ai jamais trouvé comment

concernant les attaques, je ne vois pas trop quoi faire pour bloquer cela, il est certains que ce n'est pas bon et que cela doit aussi ralentir le server

Edited by TrocWeb
Link to comment
Share on other sites

S'il s'agit vraiment d'un "kernel panic" un moyen de limiter la casse est d'ajouter un panic=N coté bootloader afin d'indiquer au kernel de rebooter après N secondes.

Mais s'il s'agit d'un kernel OVH, la probabilité que ça coince sur leur matos me semble faible.

Là comme ça, s'il n'y a absolument aucune trace dans les logs j'aurais plutôt vu un problème hardware...

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...