X-Space

Aller au contenu | Aller au menu | Aller à la recherche

samedi, avril 19 2008

Quelques heures dans la peau de TitaX, suite et fin

Avec 6 mois de retard, voici la suite et la fin de mes aventures (partie 1, partie 2).

Lors de mon dernier billet, de nombreuses questions restaient en suspend : problème matériel (mon opinion) ou problème d'OS (Dell).

Comme je le prévoyais le serveur est retombé mi aout. L'OS est donc clairement hors de causes, mais le technicien Dell (toujours le même) ne voulait toujours rien savoir.

J'ai lancé des stress tests (thrash, bonnie++) sur les disques durs sans résultats.

J'ai alors soumis le problème à mes colistiers de SOS-Admin, qui flairaient eux aussi le problème hardware. Du fait de l'absence de syslog, Stephane B. m'a suggéré d'externaliser les logs.

Externaliser les logs, mais qu'est ce donc ?

Et bien c'est tout simple, les logs sous linux sont gérer par un petit démon qui s'appelle syslogd. Ce petit démon possède une fonctionnalité plutôt intéressante : il permet d'envoyer les logs d'une machine sur une autre machine (externaliser !). Plutôt pratique lorsque la machine à des problèmes de disques durs et donc que rien ne s'écrit dans les fichiers logs.

Voyons maintenant comment configurer le bouzin.

Coté émetteur :

C'est assez simple : il suffit de configurer syslogd afin de lui dire quel type de log on veut envoyer sur le serveur distant. Dans mon cas, on log tout.

$ cat /etc/syslog.conf | grep "x-space"
*.*                                                     @x-space.net

Coté destinataire c'est un peu plus compliqué :

Tout d'abord, il faut demander au démon d'écouter sur le réseau (désactivé par défaut):

# tail -n1 /etc/default/syslogd
SYSLOGD="-r"

Puis on ouvre la parefeu en UDP sur le port de syslog (voir /etc/services):

iptables -A INPUT -s IP_EMETTEUR -p udp --dport 514  -j ACCEPT

Ne reste plus qu'a redémarrer les démons de chaque coté.

Et la magie :

Aug 28 19:02:47 ******* kernel: sd 0:2:0:0: SCSI error: return code = 0x00040000
Aug 28 19:02:47 ******* kernel: end_request: I/O error, dev sda, sector 242365
Aug 28 19:02:47 ******* kernel: sd 0:2:0:0: SCSI error: return code = 0x00040000
Aug 28 19:02:47 ******* kernel: end_request: I/O error, dev sda, sector 242381
Aug 28 19:02:47 ******* kernel: lost page write due to I/O error on dm-0
Aug 28 19:03:18 ******* kernel: sd 0:2:0:0: SCSI error: return code = 0x00040000
Aug 28 19:03:18 ******* kernel: end_request: I/O error, dev sda, sector 94319189
Aug 28 19:03:18 ******* kernel: lost page write due to I/O error on dm-0

Epilogue

Le technicien Dell (toujours le même) a alors voulu exclure un dysfonctionnement lié au disque 2 vu que c'est que lui qui remontait des erreurs donc il m'a demandé de faire fonctionner le RAID en mode dégradé (on retire un disque). Ça a marché jusqu'à que le serveur retombe "définitivement" : le raid s'est effondré et n'a pas pu se remonter sur deux disques. J'ai du donc gueuler la sérieusement sur un autre technicien Dell qui a bougé cette fois et a fait changer le contrôleur RAID rapidement (J+1). Depuis le serveur fonctionne très bien.

jeudi, juillet 5 2007

Quelques heures dans la peau de TitaX

Je suis actuellement en stage de 2ième année et dans le cadre de ce stage, avec un collègue, je développe un site web / espace collaboratif mais dois aussi installer et configurer le serveur web qui accueillera le site. La machine est un PowerEdge 2950 ( Père Noël si tu passes dans le coin ) sur lequel on a installé Debian Etch ( oui je sais j'ai toujours pas publié mes notes d'installation de ce serveur ). Sauf que, gros problème, le système de fichier se met de temps en temps en lecture seule.

Lire la suite...