LinuxFr.org n'aime pas la rentrée et la fin de l'été

Posté par  (site web personnel) . Modéré par j.
Étiquettes :
32
1
sept.
2009
LinuxFr.org
Hier soir 31 août, en protestation envers la rentrée et la fin de l'été, le serveur LinuxFr.org (le vserver de la partie web en fait) a connu une corruption SQL sur une des tables de la base de données. Le temps d'être averti et d'intervenir, nous n'avons pu que constater que la machine hôte et l'ensemble des vservers (web, courriel, Jabber/XMPP, développement, ...) de l'association avaient disparu du monde IP.

Ne disposant pas de carte d'administration distante sur l'hôte, nous avons contacté le NOC de la fondation Free (qui nous héberge) pour obtenir plus d'infos. À 2h du matin, nous avons eu confirmation que la baie concernée n'avait pas connu de souci et que le problème venait de notre serveur. Aujourd'hui, le NOC a confirmé ce que nous pressentions, un kernel panic sur la console (un problème sur le RAID apparemment) et le serveur a été redémarré.

Après analyse des logs (identification d'une saturation disque sur un des vservers par exemple), vidage des files d'attente courriel notamment et lancement des tâches cron en retard, le retour à la production a été possible (sinon vous ne liriez pas cette dépêche d'ailleurs).

Bref, une bonne occasion de tester nos adminsys, la politique de sauvegarde (ah les révisions à la rentrée), l'utilité d'une carte d'administration distante (ah les fournitures à la rentrée...). Et merci au NOC pour son efficacité et la rapidité des réponses.

Aller plus loin

  • # Merci !

    Posté par  (site web personnel) . Évalué à 10.

    Merci à tous pour avoir bien taffé afin de remettre d'aplomb notre joujou à tous...

    • [^] # Re: Merci !

      Posté par  (site web personnel) . Évalué à 10.

      Purée une matinée au boulot sans pouvoir aller sur linuxfr...j'ai cru mourir !

      • [^] # Re: Merci !

        Posté par  (site web personnel) . Évalué à 5.

        Merci, pour la réactivité et réparer les dégâts collatéraux du Oops kernel (en espérant qu'il ne se reproduise pas...).

        J'étais bien embêté ce matin, depuis hier soir, j'étais à jour de slashdot, xkcd et consors :/

      • [^] # Re: Merci !

        Posté par  . Évalué à 6.

        Lol, j'utilise souvent LFR pour tester la connexion à Internet d'un poste (car google et yahoo sont trop souvent dans le cache).

        D'autre sites plantés sur l'ordinateur sur lequel on m'avait demandé jeter un oeil, j'ai donc tout envisagé :
        - problème DNS
        - problème de cache du navigateur
        - problème iptables

        avant de me dire, c'est peut être LFR qui a planté :).

        • [^] # Re: Merci !

          Posté par  . Évalué à 2.

          Et vider le cache avant d'effectuer une requête vers un site, ce n'est pas plus fiable? Non parce que DLFP peut aussi être dans le cache d'un browser... et tu n'auras rien prouvé en l'affichant ;-)

  • # Plus de peur

    Posté par  (site web personnel) . Évalué à 6.

    Plus de peur que de mal, youpi !
    La journée a été très longue, sans DLFP.

    Maintenant, c'est pas la première fois que ça se passe.
    Pourrait-on envisager un autre site (hébergé *ailleurs* donc) qui mette une courte indication en cas de problème ?
    Une simple page HTML qui dit "oui, c'est en rade, on est au courant, et on y travaille (après la pause pastis)", afin qu'internet cesse de ramer devant tous ces gens qui demandent "linuxfr répond pas chez moi, chez toi c'est pareil ?"
    Un nom de domaine simple comme linuxfrestilenpanne.fr (et qui affiche "non" quand dlfp est bien fonctionnel).

    Allez, faites votre cartable, élève Moule, et à demain !

    • [^] # Re: Plus de peur

      Posté par  . Évalué à 10.

      http://downforeveryoneorjustme.com/linuxfr.org

      • [^] # Re: Plus de peur

        Posté par  (site web personnel) . Évalué à 2.

        Oui, j'ai vu ça.
        C'est bien. Mais un message des admins "on est au courant", c'est mieux.
        Ça fait plus pro, c'est plus rassurant.

        • [^] # Re: Plus de peur

          Posté par  (site web personnel) . Évalué à 5.

          Et bien sûr tu consultes linuxfr.org pour trouver quelle est l'URL la page qui signale que linuxfr.org est "en rade" ...

          C'est comme envoyer un email à l'admin/fai pour dire que la connexion internet est en rade ;-)

          • [^] # Re: Plus de peur

            Posté par  . Évalué à 2.

            Il y a d'autres solutions, pour qu'une page minimaliste réponde. Je citerai la modif dns (ça implique un TTL bas et c'est mal), et le anycast + BGP (ça m'étonnerait que free propose ça, vu ce que ça implique en terme d'infrastructure).

            Après il y a d'autres méthodes, mais ça implique de multiplier les serveurs, c'est pas le même prix. Il vaut mieux investir dans une carte de prise de contrôle à distance. et éventuellement prévoir une page d'attente statique pendant qu'on répare la base de données, ça coute moins cher [1] :-)

            (D'autant que les pertes d'exploitation liées à l'indispo de linuxfr sont faible, même si les dommages en terme d'image existent bel et bien).

            [1] D'ailleurs, je me demande combien ça coûte en standalone, les seules que je connais sont celles qui sont intégrées dans les serveurs Dell, IBM et compagnie... C'est du même ordre ce que vous envisagez ici ?

            • [^] # Re: Plus de peur

              Posté par  (site web personnel) . Évalué à 2.

              > [1] D'ailleurs, je me demande combien ça coûte en standalone, les seules que je connais sont celles qui sont intégrées dans les serveurs Dell, IBM et compagnie... C'est du même ordre ce que vous envisagez ici ?

              Apparemment 275 € TTC hors livraison une carte Dell DRAC5.

            • [^] # Re: Plus de peur

              Posté par  . Évalué à 9.

              (D'autant que les pertes d'exploitation liées à l'indispo de linuxfr sont faible, même si les dommages en terme d'image existent bel et bien).

              Ca depend, moi je dirais que nombre d'entreprises y trouvent un gain de productivite significatif :+)

          • [^] # Re: Plus de peur

            Posté par  (site web personnel) . Évalué à 10.

            Keyboard error: press F1 to continue

        • [^] # Re: Plus de peur

          Posté par  (site web personnel) . Évalué à 2.

          >>> C'est bien. Mais un message des admins "on est au courant", c'est mieux.
          Ça fait plus pro, c'est plus rassurant.

          Ben chez google ils sont pas pro alors. Gmail a l'air d'être méchamment down :

          http://farm3.static.flickr.com/2632/3878479843_793161c23b_o.(...)

      • [^] # Re: Plus de peur

        Posté par  . Évalué à 2.

        Il n'y a pas que DLFP qui n'aime pas la rentrée !

        http://downforeveryoneorjustme.com/www.gmail.com

        It's not just you! http://www.gmail.com looks down from here.

  • # IIS

    Posté par  (site web personnel) . Évalué à 10.

    Et comme par hasard ça tombe le jour où on découvre une faille dans IIS:
    http://www.pcinpact.com/actu/news/52833-faille-iis-microsoft(...)

    Je pense plutôt que LinuxFR nous cache des choses.

    • [^] # Re: IIS

      Posté par  . Évalué à 8.

      Pas possible, la faille ne touche pas IIS7 et on sait tous que linuxfr tourne sur Windows Server 2008

      • [^] # Re: IIS

        Posté par  . Évalué à 3.

        Et templeet fonctionne avec une base access et le code est en VBA !

  • # Oh

    Posté par  . Évalué à 10.

    Ah, c'était un problème serveur, je croyais que c'était la journée mondiale de la productivité au travail.

    Merci pour la réactivité des admins sinon :).

  • # linux fr hacké

    Posté par  . Évalué à 3.

    Certains font un amalgame rapide, sans avoir pris en compte les symptômes visibles:
    http://www.nicosphere.net/hacking%C2%A0%C2%A0archlinux-org-e(...)

    • [^] # Re: linux fr hacké

      Posté par  (site web personnel) . Évalué à 5.

      Il est dans le vrai : linuxfr s'est fait hacké par ses admins pour se remettre en fonctionnement correctement.
      Pas de cracker identifié sur l'action en tout cas, hormis le Oops constaté.
      Pas de pirate à l'horizon non plus, la mer étant suffisamment loin du datacenter :-)

    • [^] # Re: linux fr hacké

      Posté par  (site web personnel) . Évalué à 5.

      J'apporte tellement de crédibilité aux blogs bourrés de fautes...
      Je cite : "c’est-il fait hacker à son tour ? il est quand même à noté [...]"

      • [^] # Re: linux fr hacké

        Posté par  . Évalué à 3.

        Le "Quand à linuxfr" est pas mal aussi ...

        • [^] # Re: linux fr hacké

          Posté par  (site web personnel) . Évalué à 3.

          Je comprends que l'orthographe soit important, et j'essaye de faire des efforts sur ce point.
          En effet j'ai écrit ça vite fait hier soir, sans relire (à tord), cela dit pour un blog qu'y n'a que trois semaine, normalement personne ne lit.
          Pour l'amalgame, c'était peut être certes un peu facile. Juste une question que je me posais, de faire le rapprochement entre les deux.
          QuanT à la crédibilité, je ne fais aucune conclusion non plus.

          Pour sûr, je ferais plus attention à mon orthographe, même si je pense que personne ne me lira.

          • [^] # Re: linux fr hacké

            Posté par  (site web personnel) . Évalué à 3.

            "je ferais plus attention à mon orthographe"
            => je ferai... (futur et pas conditionnel)

            On veut pas te démotiver dans ta volonté de blogguer sur le libre mais si tu ne fais pas l'effort de t'appliquer sur ton orthographe, tu ne vas pas progresser. Moi-même je suis à la base mauvais, mais j'ai des amis qui m'ont tellement fait chier avec ça que maintenant j'en fais beaucoup moins.

          • [^] # Re: linux fr hacké

            Posté par  . Évalué à 5.

            Fais attention, le tort tue ...

          • [^] # Re: linux fr hacké

            Posté par  (site web personnel, Mastodon) . Évalué à 2.

            Si on constate qu'en plus Google GMail a été inaccessible pendant de longues minutes, on ne peut plus éviter la théorie du complot contre Google et Linux, initiés par les chinois du FBI basés à Redmond...

            http://gmailblog.blogspot.com/2009/09/todays-gmail-problems.(...)
            http://gmailblog.blogspot.com/2009/09/more-on-todays-gmail-i(...)

            La Guerre est en marche.

          • [^] # Re: linux fr hacké

            Posté par  (site web personnel) . Évalué à 1.

            Détrompe toi...
            linuxfr ne fonctionnant pas, j'ai cherché dans les moteurs de recherche des sites parlant de linuxfr ce jour même..
            ton blog était le premier lien...
            je l'ai consulté..

            (et en effet, les fautes, tout de suite, tu perds énormément de crédibilité.. c'est con.. mais c'est comme ça)
            courage pour l'orthographe, tu verras, c'est quand même mieux quand un texte est à peu près bien écrit..

  • # Hypothèses expliquant le problème ?

    Posté par  (site web personnel) . Évalué à 5.

    « Après analyse des logs (identification d'une saturation disque sur un des vservers par exemple) » signifie-t-il que la panne a simplement été causée par un disque saturé ? Ou y a-t-il une défaillance matérielle, un driver défectueux ou un bug dans le kernel ?

    • [^] # Re: Hypothèses expliquant le problème ?

      Posté par  (site web personnel) . Évalué à 3.

      La saturation d'un système de fichiers dans un vserver peut bloquer le Mysql concerné, à la rigueur ralentir jusqu'à l'insoutenable tout le vserver, à l'extrême limite ralentir l'hôte, mais pas provoquer un plantage noyau a priori. Bref le souci RAID et la saturation locale d'un système de fichiers me semblent décorrélés. Ensuite sur le plantage noyau, ça va être difficile d'avoir plus d'infos autrement que par divination.

      • [^] # Re: Hypothèses expliquant le problème ?

        Posté par  . Évalué à 6.

        Ben non, suffit de le reproduire... histoire qu'on se marre :)

      • [^] # Re: Hypothèses expliquant le problème ?

        Posté par  (site web personnel) . Évalué à 1.

        Ba si vous avez vu le oops vous devriez bien avoir une copie du backtrace quelque part.

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: Hypothèses expliquant le problème ?

          Posté par  (site web personnel) . Évalué à 6.

          Quand l'accès aux disques se plante, le log du crash n'est pas stocké sur... le disque. Donc il est juste sur la console. Et comme la machine a été redémarrée (c'est pas le boulot du NOC de débugger notre serveur), pffiou, aucune trace du oops. Et quand bien même, on n'a pas non plus de kernel debugger sur un port série, c'est pas facilement utilisable.

          • [^] # Re: Hypothèses expliquant le problème ?

            Posté par  . Évalué à 5.

            si vous étiez sous aix, le dump aurait été copié automatiquement dans un lv dédié que vous auriez pu récupérer ultérieurement....

            linux c'est vraiment pas prêt pour l'entreprise, heureusement que vous êtes une association /o\

            • [^] # Re: Hypothèses expliquant le problème ?

              Posté par  (site web personnel) . Évalué à 3.

              Je n'en doute pas... je suis sûr que lorsque le noyau d'un système propriétaire aix plante, il renaît spontanément de ses cendres en autorécupérant via le « Void which binds » les dernières paroles du décédé qu'il inscrit alors soigneusement dans le grand registre des extraits de dernières paroles pour les générations futures. Bref quand le coeur du système (ici le noyau de l'hôte) plante, ben ça plante...

              • [^] # Re: Hypothèses expliquant le problème ?

                Posté par  . Évalué à 4.

                en fait dans le cas d'aix, c'est le "service processor" de la machine qui vide la mémoire sur le disque, donc c'est une particularité du hardware /o/ ce n'est pas complètement lié à aix même si le sysdump ça se paramètre sous aix.

            • [^] # Re: Hypothèses expliquant le problème ?

              Posté par  (site web personnel) . Évalué à 6.

              Linux sait faire ça. Ça s'appelle kdump. Le problème c'est que c'est généralement pas configuré par défaut (et apparement pas encore dans toutes les distros) : http://lse.sourceforge.net/kdump/

              Il n'y a rien de magique et il peut arriver que le noyal soit tellement mal barré que kdump ne sache pas récupérer ni backtrace ni vmcore mais c'est plutôt rare. À recommander sur les systèmes pour lesquels on a envie de savoir pourquoi il s'est crashé.

              pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: Hypothèses expliquant le problème ?

            Posté par  (site web personnel) . Évalué à 2.

            Pas besoin d'un debugger sur le port série mais juste de quoi logguer les messages qui y passent. Sinon kdump ça marche bien aussi. Ou même diskdump selon la distro/version.

            pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # les mauvaises langues

    Posté par  . Évalué à 4.

    et dire que des mauvaises avaient déjà accusé templeet de ce sabotage

  • # Le sondage ?

    Posté par  . Évalué à 10.

    Le sondage sur les sauvegardes, c'était pour savoir comment font les pros ?



    ====> [ ]

    • [^] # Re: Le sondage ?

      Posté par  (site web personnel) . Évalué à 10.

      La dernière sauvegarde hors site du site avait moins de 48h. On a deux sites distants de sauvegardes, des sauvegardes journalières et des hebdomadaires, ce n'était pas vraiment ça le souci...

      • [^] # Re: Le sondage ?

        Posté par  . Évalué à 3.

        Je plaisantais bien-sur, je sais très bien que les gens de linuxfr sont pas kéké...!
        Total respect pour l'équipe de linuxfr !

  • # Gmail copie linuxfr !

    Posté par  . Évalué à 2.

    Mais ils sont en retard de 24 heures !

    • [^] # Re: Gmail copie linuxfr !

      Posté par  . Évalué à 10.

      C'est juste que les admin Gmail utilise linuxfr pour tester la connexion internet (voir ci-dessus) et comme ça marchait pas, ils ont pensé qu'Internet était mort et on éteint les serveurs pour faire des économies d'énergie. Et ils ont mis un peu de temps pour se rendre compte de leur erreur.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # google ouned by peer

    Posté par  . Évalué à 1.

    pitetre que c'est la faut a google aussi

  • # Cartes d'administration distante

    Posté par  . Évalué à 2.

    Un commentaire précédent de Benoît Sibaud fait mention de la carte Dell DRAC5. Quelqu'un aurait-il d'autres références de carte d'administration distante à nous faire partager ?

    • [^] # Re: Cartes d'administration distante

      Posté par  . Évalué à 2.

      Le fabricant de cartes mères supermicro en a une à "seulement" 90€ ht (https+applet java dans un navigateur pour l'accès kvm)...
      Bon, après, les CM SM c'est pas donné mais c'est du bon matos pour faire un serveur "assemblé" qui tienne la route (et ça roule très bien sous Debian).

    • [^] # Re: Cartes d'administration distante

      Posté par  (site web personnel) . Évalué à 1.

      La carte DELL marche-t-elle sur d'autres types de serveur que les DELL ?

      En gros, ce genre de carte est-il universel ?

      • [^] # Re: Cartes d'administration distante

        Posté par  (site web personnel) . Évalué à 2.

        Pas du tout, elles exploitent des fonctions spécifiques de la carte mère (pour le kvm, le serial over ip, config bios etc.), certaines utilisent d'ailleurs un port propriétaire...

        • [^] # Re: Cartes d'administration distante

          Posté par  (site web personnel) . Évalué à 1.

          Un petit kvm IP de chez minicom sinon ça marche pas trop mal.
          Attention toutefois certains ont besoin d'un client Windows (activeX).

          • [^] # Re: Cartes d'administration distante

            Posté par  . Évalué à 2.

            Au prix de l'emplacement en datacenter, je vois pas l'interet de gaspiller de la place avec un slot kvm.

            L'avantage des cartes de management, c'est qu'elles se greffent dans le serveur et communiquent avec le même port éthernet. Avec ou sans, la prise en compte dans l'infrastructure est la même.

      • [^] # Re: Cartes d'administration distante

        Posté par  . Évalué à 2.

        Non. Dell c'est dell: connecteur proprio, etc.

        Les cartes supermicro c'est de l'IPMI standard. Certains fabricants font par ailleurs des cartes clientes IPMI compatibles.

  • # J'ai eu peur !

    Posté par  (site web personnel) . Évalué à 0.

    Ca ressemblait beaucoup à l'execution de ce qui avait été dit là : http://linuxfr.org/2009/04/01/25253.html

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.