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

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

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

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

pas simple tous ca...

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

Oui c'est sur mais n'ayant jamais rencontré un tel problème, j'essaie aussi de trouver une solution...
Tu sais a quelle heure ton serveur a planté exactement ou du moins, quand il ne répondait plus?

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 )

edit cest pas: ps -aux ?

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

merci pour ton aide, je quitte le pc pour plusieurs heures, je te tiens au courant dès mon retour

avec mes remerciements par avance

Oui je fais de mon mieux sur ce coup la...
Je pense qu'on devrait attendre Dan.
Je parie qu'il va nous sortir la solution en 5min...

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.

Ha je ne connaissais pas grsecurity
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 !

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 ... je vais m'en passer

J'ai regardé mais je vois rien de spécial...
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
Je m'y suis moi même plusieurs fois brulé les ailes au début

merci pour ton aide

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

Edi: je n'ai pas de fichier log

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 sinon ca risque de peser lourd :-/

c'est immense tout les dossier et fichier la dedans....

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

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

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

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

Bha effectivement, ca fait des requêtes mais ca n'est pas non stop donc ca va encore

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