UUNet (update)

Posté par  (site web personnel, Mastodon) . Modéré par Fabien Penso.
Étiquettes : aucune
0
20
juil.
2001
LinuxFr.org
Ma société (DBee) héberge à titre gracieux le DNS de LinuxFr ainsi que quelques autres. UUNet étant notre fournisseur d'accès (LS dédiée) nous avons aussi le droit à des services supplémentaires tels que l'hébergement en tant que secondaire de nos zones.

Nous avions besoin d'élargir la plage d'adresse IP qui nous était jusque là attribuée, et il était obligatoire d'en changer. J'avais donc prévu le changement depuis une semaine. Le DNS primaire ne serait temporairement pas accessible, du moins pendant un temps de propagation obligatoire, aussi court que celui là pourrait être. Mais le secondaire lui ne changerait pas, et je comptais sur UUNet pour simplement lui indiquer de récupérer ses zones sur le nouveau primaire et non l'ancien. Le changement ne se serait même pas fait sentir. Et bien non, ça n'a pas été possible, et j'ai vu tout au long de la journée leur secondaire passer par différents états. D'abord il ne connaissait plus nos zones, puis il les connaissait ... mais elles étaient complêtement faussées ! Le serveur de mail était le leur (d'ou le problème que vous avez dû avoir pour nous joindre) et notre DNS primaire avait disparu de la liste des NS. J'ai évidemment envoyé un message à leur service client.

Update: Il semblerait qu'une mauvaise compréhension sur la manière de faire l'upgrade, ainsi qu'un 'expire' trop faible (2h pour certaines zones, 10m pour une, et 4 semaines pour les autres) aient provoqués cet incident. UUNet voulait ne modifier le secondaire que bien après, pensant que le cache jouerait son rôle. C'était sans compter que j'avais fixé un expire plus faible. Conclusion, si vous effectuez ces mêmes manips chez vous, conservez les anciennes adresses quoi qu'on vous dise.

  • # Broken link

    Posté par  . Évalué à 0.

    Le lien vers le courrier de marche pas.

    C'est tout ;)

    • [^] # Re: Broken link

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

      Il marche. Sans doute un soucis de DNS. Quelle erreur as-tu ?

      • [^] # Re: Broken link

        Posté par  . Évalué à 0.

        Bah, quand je clique dessus, ça n'aboutit nulle part..

        Comme si le lien pointait vers une adresse inexistante tout simplement.

        Si le courrier n'est pas trop long, ce serait sympa de le mettre en fichier attaché.

        • [^] # Re: Broken link

          Posté par  . Évalué à 0.

          (je me réponds :)

          Merci Fabien pour avoir attaché le mail à la news.

      • [^] # Re: Broken link

        Posté par  . Évalué à -1.

        J'ai:

        Cannot find server or DNS Error
        Internet Explorer

        (je n'ai pas posté le premier message).

        • [^] # Fabien...

          Posté par  . Évalué à -1.

          Tu nous laissera lire leur réponse svp ?

          Merci !

      • [^] # Re: Broken link

        Posté par  . Évalué à 1.

        erreur 500
        le serveur ne répond pas
        c'est comme ça sur perso.linuxfr.org depuis que dlfp est revenu hier

        bon courrage

        Bruno

        • [^] # ça y est, c'est revenu

          Posté par  . Évalué à 1.

          ça vien à l'instant de revenir chez moi, alors que j'etait en train d'essayer www.dacode.org qui ne répondait pas non plus

          pouvu que ça tienne

          Bruno

    • [^] # Re: Broken link

      Posté par  . Évalué à 0.

      et le serveur de news (news.linuxfr.org) ne fonctionne toujours pas non plus à 10h45.

  • # [HS] bite couille poil

    Posté par  . Évalué à -1.

    Dans le sujet voici quelques idées de noms pour les futurs bécanes de linuxfr. C'est pour dire que j'aime bien les noms des machines (prout.linuxfr.org, zobe.linuxfr.org (dans ma petite enfance on écrivait zob)).

    Qui les choisit ?

  • # Reply...

    Posté par  . Évalué à 0.

    Il serait intéressant de connaitre la réponse de UUNet concernant ce mail.

    Fabien, si tu as du nouveau, n'hésite surtout pas à nous faire un petit résumé de la suite des événements.

    • [^] # Re: Reply...

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

      Le plus intéressant c'est que je devais avoir un coup de fil hier soir, je n'ai jamais rien eu, et même ce matin, après avoir envoyé ce mail (hier soir), il est 11h et j'ai toujours aucunes nouvelles.

      Je suis passablement énervé, le mot est faible.

      • [^] # Re: Reply...

        Posté par  . Évalué à 2.

        Pour avoir travaillé avec eux de maniere professionelle pendant plus d'un an.
        pour un grand site internet >250000/jours
        je peux te dire mon cher fabien qu'ils n'en sont pas à leur coup d'essai...
        ils ne savent meme pas quand leur machines tombent, ou quand la ligne se coupe, c'est nous avec les outils que nous avions mis en place qui les en informions...
        Quand à la durée des 'pannes' leurs temps est plus court que le notre...
        Mais bon...
        UUnet (UU tu begayes ?)

      • [^] # Re: Reply...

        Posté par  . Évalué à 0.

        Comment que je te les harcelerai au tél moi :)

        Te laisse pas faire ;)

        Sinon, il semblerait que http://linuxfr.org(...) fonctionne bien, par contre tout ce qui est www.linuxfr.org, perso.linuxfr.org, etc... ne fonctionne pas (pour répondre au tout premier post qui dit que le lien vers le mail ne peut pas être atteinds)

        • [^] # Re: Reply...

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

          Et emacsfr.org ne marche toujours pas....

          • [^] # Re: Reply...

            Posté par  . Évalué à 1.

            Ah? T'as remarqué aussi? :)
            Si ça se trouve, il a planté hier quand tout le monde s'est rendu compte que Linuxfr n'était plus accessible. L'a pas supporté l'invasion cette fois-ci, ptet :)

            • [^] # Re: Reply...

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

              héhé, toutes les moules ont du se précipiter sur ce site quand linuxfr n'était plus accessible !
              Mais ce n'est pas ça, c'est parce qu'il est sur le même DNS que linuxfr, et pour cause :

              whois emacsfr.org
              domain: emacsfr.org
              owner-address: Fabien Penso
              nserver: harbor.dbee.com 194.98.196.10
              nserver: NS1.NAN2.INETWAY.NET 194.98.65.69

          • [^] # Re: Reply...

            Posté par  . Évalué à -1.

            debianfr.org non plus :-)

    • [^] # Re: Reply...

      Posté par  . Évalué à 1.

      Ouai...c'est pas parcequ'il y a une pomme pourrie sur l'arbre qu'elles le sont toutes.
      J'ai jamais ue de problèmes avec UUNET, enfin pas de problèmes majeurs...lorsqu'ils devaient couper pour maintenance (year 2K etc...), nous avons toujours été prévenu longtemps à l'avance.
      Ils nous ont même laisser un ptit rab de temps avant de couper quand on est passé chez Oléane...histoire de pas nous laisser sans ligne, pendant que les FT loosers tentait désespérement de faire fonctionner notre connection ADSL.

  • # mouais...

    Posté par  . Évalué à 0.

    Enfin bon...déja si tu laisse gerer des trucs comme le dns secondaire ou autre à ton fournisseur faut pas te plaindre d avoir des problèmes ensuite ...
    on est jamais mieux servi que par soi meme hein ?

    en plus sans vouloir etre mechant pour uunet si tu avais besoin de fiabilité on se demande ce que tu fais chez eux... enfin si tu aimes quand ca tombe je te conseille aussi isdnet, un service technique plus cretin ,meme chez uunet, ils ont pas.

    • [^] # Re: mouais...

      Posté par  . Évalué à 0.

      la palm reviendrait aussi à Oléane ..
      ils sont pas mal aussi

    • [^] # Re: mouais...

      Posté par  . Évalué à 1.

      ok, mais bon, un DNS secondaire, tertiaire etc... c'est quand meme mieux quand il est placé à distance du principal, au cas où , justement, la connexion est coupée avec le pricipal. Donc à moins d'avoir un réseau (société) tres étendu(e), ton FAI est une bonne solutions. Mais cela etant dit, c'est vrai que quand c'est un FAI de merde...
      Pour ma part, j'ai également eu des probleme DNS avec UUNet il fut un temps... ( deux semaine pour créér une zone !!!!) depuis j'ai changé... ;))

  • # dns en suisse ? :)

    Posté par  . Évalué à 1.

    Fabien, si tu veux je peux ajouter un secondary dns sur un de mes serveurs en suisse, à la meme place que linuxch.org :)

  • # Une société qui ne répond pas...

    Posté par  . Évalué à 0.

    ... ça peut arriver à tout le monde. Par exemple, un jour quelqu'un a posté des insultes en mon nom à des inconnus sur un forum de http://www.developpez.com(...) - et certains m'en ont informé. J'ai envoyé un e-mail à chaque membre de la rédaction (50 !), dans l'heure qui a suivi, toutes les insultes étaient supprimmées. Je suis désolé d'avoir envoyé 50 e-mails d'un coup (ils m'en voulaient beaucoup après) (avec eux, un seul e-mail aurait suffit) mais dans la majorité des cas, si tu ne te fais pas entendre, personne ne se penchera pour t'écouter. Dans ce cas-ci, peut-être est-ce ce qu'il faut faire ? Gueuler, injurier, harceler, menacer... Peut-être que ceux d'entre vous qui ont des adresses d'e-mails de chez UUNet pourraient les poster sous ce thread (si ça intéresse DLFP, bien sûr) ?

    P-S: mon petit conflit avec http://www.developpez.com(...) s'est finalement bien terminé: ils ont supprimé les insultes, je me suis excusé et eux aussi, et j'ai découvert un merveilleux site sur la programmation en général.

  • # Methodologie

    Posté par  . Évalué à 0.

    Plusieur questions me viennent a l'esprit:
    - Aviez vous fait des test pour vous assurer de la bonne configuration des DNS de UUNET avant le changement ? A vu de nez il semblerait que UUNET n'ai jamais leur DNS configure correctement, ce qui arrive TRES souvent de la part de gros ISP.
    - Pourquoi UUNet ne vous a-t-il pas laisse votre ancienne allocation pour le temps du transfer ? (seule explication que je peux voir pour expliquer la justification de la disparition de votre DNS) Ne me dites pas qu'ils ne savent pas ajouter une IP secondaire sur un routeur !

    Anonyme Thomas

    PS : Ne jamais croire les grosse societe quand vous n'avez pas (au moins) quatre numero personnel de technicien competent. ;*)

    • [^] # Re: Methodologie

      Posté par  . Évalué à 0.

      Ne jamais croire les sociétés tout court. si le client appele pour un probleme, la société va toujours dire que c'est en cours, qu'on sait faire, que ça va être bientot reparé. Elle ne va bien sur pas dire : "ha? ça marche pas? rien vu" ou "on sais pas faire" ou "en fait tous les techniciens sont en vacances, on peut rien pour vous"

      Ce qui est logique en fait puisque s'ils disaient la vérité, les clients partiraient :)

    • [^] # Re: Methodologie

      Posté par  . Évalué à 1.

      Cet anonyme à bien parlé...
      aviez vous reduit le TTL de vos enregistrements DNS pour que les caches s'adaptent plus vite ?
      ne pouviez vous pas garder la meme IP en doublon sur votre DNS primaire le temps du switch ?
      ne pouviez vous pas demander une seconde plage d'adresse IP au lieu de changer d'adresses juste pour en avoir plus ?
      Avez vous fait le changement avec un technicien de UUNET en ligne ?
      Quand je fais des modifs avec UUNET et ATT, je decris les operations dans un doc par mail et je leur donne RV au telephone pour que les manips soient faites en meme temps de leur coté et du mien ...
      Ces boites (UUNET, ATT, ...) ne font rien qui ne soit pas explicitement demandé par le client. Si vous ne leurs soufflez pas des idées, ils ne proposeront rien ...

      PLuG qui pense que UUNET a bien merdé, mais que l'opération aurait pu être mieux préparée...

      • [^] # Re: Methodologie

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

        Oui le TTL avait été baissé sur les zones les plus importantes.

        Une personne de uunet m'avait dit que conserver l'autre mask en même temps était chiant. Comme je pensais que les secondaires marcheraient...

        Demander une autre plage nous posait des soucis internes, et les plages à côté de celle qu'on utilisait étaient déjà prises.

        Les modifications ont été effectuées avec les personnes de uunet constamment au téléphone, ils gèrent le routeur qui se trouve de notre côté.

        J'avais préparé cette modification depuis une semaine, j'avais déjà envoyé l'access list à appliquer sur le routeur, ainsi que la liste des zones dont ils sont secondaires et qu'il fallait modifier pour faire pointer vers la nouvelle ip du primaire.

        J'avais, la veille, annoncé le changement d'IP du host qui est enregistré au NSI. Le changement était pris immédiatement.

        J'ai, pendant le changement, modifié toutes les zones qui se trouvaient sur gandi mais ca n'a pas d'importance (cf le support gandi), c'était juste un soucis de syncro de base whois.

        • [^] # Re: Methodologie

          Posté par  . Évalué à 0.

          Pour information, aviez-vous change le TTL le jour avant le transfert. DNS prend du temps pour s'updater. Ca pourrait expliquer pourquoi UUNET n'avez pas vos changement. le TTL de leur zone n'etant pas passe (ce qui n'explique pas le reste)

          Thomas

        • [^] # Re: Methodologie

          Posté par  . Évalué à 0.

          "Une personne de uunet m'avait dit que conserver l'autre mask en même temps était chiant. Comme je pensais que les secondaires marcheraient... "

          Note bien le nom de ce gars, car il est vraiment pas competent.
          Tu ajoute l'address secondaire :
          conf t
          int <INTERFACE>
          ip address <IP> <NETMASK> secondary
          exit
          ip route <NETWORK> <NETMASK> <INTERFACE>
          exit

          Voila, c'est fait !!
          Et si tu veux enleve l'autre tu te connecte sur la nouvelle IP et :

          conf t
          int <INTERFACE>
          ip address <IP> <NETMASK>
          exit
          no ip route <OLD NETWORK> <OLD NETMASK> <INTERFACE>
          exit

          L'ancienne IP gigle ! (et tu reste connecte :*)
          Apres tu peux toujours reajouter l'ancienne IP si besoin en tant que secondaire !

          Si le technicient UUNET savez pas ca, tu peux commencer a avoir peur !!

          Thomas

      • [^] # Re: Methodologie

        Posté par  . Évalué à 0.

        Pour le TTL, la reponse doit etre oui car dig reporte : ns.beemotion.com. 1H IN A 194.98.196.10
        1H doit signifier 1 hour (je ne suis pas un fan de DIG)

        Je dois superviser des changement de range toute les semaines. Et je peux dire que c'est pas toujours du gateau (j ai vraiment des clients neuneu des fois ;*)

        Pour le changement de plage, RIPE demande a ce qu'on retourne les address sous "3 mois" (des fois ca devient 3 ans :-).

        Ne pensez pas que j'essaye de couvrir UUNET. Il ont serieusement bacle le boulot. Il FAUT toujours surveiller son ISP (comme on surveille des enfants, meme pire !!! ).

        Quand je fais des changement sur mon reseau, je fait attention mais je ne peux pas toujours prevoir toutes les consequence, Je compte donc sur mes utilisateur pour me geuler apres si quelque chose tourne mal.

        Comme DBee ne doit pas etre dans le TOP 1000 des clients UUNET, il n'ont pas du etre tres rapide a reagir. Il est des fois preferable d'avoir des partenaire/supplier pas trop disproportionne en taille par rapport a votre propre entreprise. Ca aide quand vous devez geuler !! ;*)

        Thomas

        • [^] # Re: Methodologie

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

          Oui, le problème c'est quand tu tentes de contacter quelqu'un, et qu'on te dit que tout le monde est absent, ensuite qu'on te rappelera, ensuite que tu n'as finalement toujours rien!

          Il est 14h45, je n'ai toujours eu aucune nouvelle sur l'avancé de la configuration de leur dns secondaire, j'étais censé être rappelé hier. no comments.

          Je vais regarder de ce pas les tarifs des LS chez les concurrents.

          • [^] # Re: Methodologie

            Posté par  . Évalué à 0.

            une baie chez level3 ?

            • [^] # Re: Methodologie

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

              C'est une LS dont on a besoin, pas d'une baie. Le soucis c'est qu'on est à Boulogne et que tout le monde ne vient pas chez nous (enfin il y a 1.5 an en tout cas). Mais je vais voir quand même le tarif et les services que me proposent les différents concurrents. Sans doute ISDNet, etc.

          • [^] # Re: Methodologie

            Posté par  . Évalué à 1.

            Ta préparation etait nickel, je reviens sur mon avis de tout à l'heure :-))
            Par contre je ne comprends pas ton probleme pour les joindre puisque tu avais un mec au bout du fil lors de la modification ?
            Quand aux tarifs, à mon avis ils se sont tous mis d'accord :-) c'est le même partout quoi.
            qui va tu consulter ? ATT, Oleane, Colt, ...

            Il faut aussi garder à l'esprit que ca arrive de se planter... En ce moment, la plupart des mecs sur site sont surement des back-up à cause des congés ... Tu devrais surtout mettre en avant la pub qu'ils sont en train de se faire sur ton site frequenté principalement par des informaticiens ... clients potentiels, consultants, techniciens !! pas bon pour eux ca !!

            Bonne chance en tout cas. Une journée sans linuxfr c'etait long :-) [et pourtant je consulte avec un lien UUNET ... ca devrait rouleze c'est quasi de l'intranet :-)]

  • # alias www

    Posté par  . Évalué à 0.

    l'alias www vers prout n'est apparemment plus defini pour le domaine linuxfr.org

    • [^] # Re: alias www

      Posté par  . Évalué à 0.

      je pense que c'est plutot un pb dans le VirtualHost

    • [^] # Re: alias www

      Posté par  . Évalué à -1.

      Prout, j'imagine bien d'ou il sort. Zobe je situe bien aussi.
      Dans la mesure ou ca doit etre aussi rapide pour les deux serveur, www serait-t'il au milieu ?

  • # J'ai eu un truc chiadé aussi !

    Posté par  . Évalué à 1.

    Pour te dire Fabien, j'ai eu droit à 2 classes C; et bien ils ont trouvé le moyen de revendre à d'autres clients à eux 16 ! La folie, ces 16 adresses n'etaient plus routé, et leur service technique m'a gentiment répondu... " ah oui, on les a attribués à quelqu'un d'autre !!!!" Temps de résolution: 48 heures !
    clap clap UUNET !

Suivre le flux des commentaires

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