[technique] lxc.network.type = phys

Joris Michaux joris.michaux at gmail.com
Mer 1 Oct 17:31:02 CEST 2014 

Bon, la restauration au 26 septembre a tout remis en ordre. J'ai demandé
une copie de la VM cassée, et je vais mettre à jour les paquets un a un
pour voir si quelque chose fait planter le truc... C'est incompréhensible.

L'update que j'ai effectuée le 27 a concerné :

  acpi-support-base (0.140-5+deb7u2 => 0.140-5+deb7u3)
  apt (0.9.7.9+deb7u2 => 0.9.7.9+deb7u5)
  apt-utils (0.9.7.9+deb7u2 => 0.9.7.9+deb7u5)
  bash (4.2+dfsg-0.1 => 4.2+dfsg-0.1+deb7u3)
  bind9-host (9.8.4.dfsg.P1-6+nmu2+deb7u1 => 9.8.4.dfsg.P1-6+nmu2+deb7u2)
  curl (7.26.0-1+wheezy9 => 7.26.0-1+wheezy10)
  dnsutils (9.8.4.dfsg.P1-6+nmu2+deb7u1 => 9.8.4.dfsg.P1-6+nmu2+deb7u2)
  file (5.11-2+deb7u3 => 5.11-2+deb7u5)
  gnupg (1.4.12-7+deb7u4 => 1.4.12-7+deb7u6)
  gpgv (1.4.12-7+deb7u4 => 1.4.12-7+deb7u6)
  host (9.8.4.dfsg.P1-6+nmu2+deb7u1 => 9.8.4.dfsg.P1-6+nmu2+deb7u2)
  libapt-inst1.5 (0.9.7.9+deb7u2 => 0.9.7.9+deb7u5)
  libapt-pkg4.12 (0.9.7.9+deb7u2 => 0.9.7.9+deb7u5)
  libbind9-80 (9.8.4.dfsg.P1-6+nmu2+deb7u1 => 9.8.4.dfsg.P1-6+nmu2+deb7u2)
  libcurl3 (7.26.0-1+wheezy9 => 7.26.0-1+wheezy10)
  libdns88 (9.8.4.dfsg.P1-6+nmu2+deb7u1 => 9.8.4.dfsg.P1-6+nmu2+deb7u2)
  libisc84 (9.8.4.dfsg.P1-6+nmu2+deb7u1 => 9.8.4.dfsg.P1-6+nmu2+deb7u2)
  libisccc80 (9.8.4.dfsg.P1-6+nmu2+deb7u1 => 9.8.4.dfsg.P1-6+nmu2+deb7u2)
  libisccfg82 (9.8.4.dfsg.P1-6+nmu2+deb7u1 => 9.8.4.dfsg.P1-6+nmu2+deb7u2)
  liblwres80 (9.8.4.dfsg.P1-6+nmu2+deb7u1 => 9.8.4.dfsg.P1-6+nmu2+deb7u2)
  libmagic1 (5.11-2+deb7u3 => 5.11-2+deb7u5)
  procmail (3.22-20 => 3.22-20+deb7u1)

Mais elle a été faite sur l'ensemble des 5 machines, je ne vois pas
pourquoi elle aurait impacté qu'une des 5...

À suivre !

Merci pour ton aide en tout cas.

Joris

Le 1 octobre 2014 14:50, Joris Michaux <joris.michaux at gmail.com> a écrit :

> Impossible pour SFR de booter sur un noyau différent. On tente une
> injection d'un backup full du 26, avant l'upgrade et le reboot, espérons
> ancien noyau.
>
> Merci pour ton temps en tout cas.
>
> Joris
>
> Le 1 octobre 2014 12:45, Emmanuel Thierry <ml at sekil.fr> a écrit :
>
>
>> Le 1 oct. 2014 à 12:26, Joris Michaux a écrit :
>>
>> Kernel version : 3.2.0-4-amd64
>> LXC version : 0.8.0-rc1
>>
>> Ces deux versions sont les mêmes sur les 5 machines. Fonctionnelles sur 4
>> d'entre elles.
>>
>> La seule variante est : 3.2.57-3+deb7u1 contre 3.2.60-1+deb7u3, du au
>> redémarrage d'une machine est pas de l'autre. Mais le problème était
>> survenu avant le reboot.
>>
>> Je n'ai pas accès à l'écran de boot de la machine ("administration"
>> SFR...), est-ce que ce test pourrait être probant ? Malgré la faible
>> différence ?
>>
>>
>> On sait jamais, tu peux regarder en revenant au noyau précédent.
>> Sinon là je sèche, je manque un peu d'infos pour t'aider... Tu peux
>> regarder du côté de la ML lxc-users.
>>
>> Manu
>>
>>
>> Le 1 octobre 2014 12:15, Emmanuel Thierry <ml at sekil.fr> a écrit :
>>
>>> Quel noyau ?
>>> Est-ce que ça marche si tu changes de noyau ?
>>>
>>> Manu
>>>
>>> Le 1 oct. 2014 à 12:05, Joris Michaux a écrit :
>>>
>>> En lançant le container sans "-d" je suis en console dessus. Mon
>>> interface est bien là, mes services tournent, mais rien en sort, rien ne
>>> rentre.
>>>
>>> Joris
>>>
>>> Le 1 octobre 2014 12:03, Emmanuel Thierry <ml at sekil.fr> a écrit :
>>>
>>>> Si tu le lances et que tu fais un lxc-console dessus, qu'est ce que ça
>>>> te donne ?
>>>>
>>>> Manu
>>>>
>>>> Le 1 oct. 2014 à 11:58, Joris Michaux a écrit :
>>>>
>>>> Les logs LXC en DEBUG ne donnent aucune ERROR, juste en boucle :
>>>>
>>>>
>>>> *lxc-start 1412157298.238 DEBUG    lxc_utmp - got inotify event 2 for
>>>> utmplxc-start 1412157298.238 DEBUG    lxc_utmp - utmp handler - run level
>>>> is N/3lxc-start 1412157298.238 DEBUG    lxc_utmp - Container running*
>>>>
>>>> DMESG n'est pas beaucoup plus bavard...
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *[64378.699884] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow
>>>> Control: None[64378.702417] ADDRCONF(NETDEV_UP): eth1: link is not
>>>> ready[64378.703358] ADDRCONF(NETDEV_CHANGE): eth1: link becomes
>>>> ready[64389.514779] eth1: no IPv6 routers present[64947.736211] e1000: eth1
>>>> NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None[64947.738740]
>>>> ADDRCONF(NETDEV_UP): eth1: link is not ready[64947.739686]
>>>> ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready[64958.343388] eth1: no
>>>> IPv6 routers present*
>>>>
>>>> Joris
>>>>
>>>> Le 1 octobre 2014 11:48, Emmanuel Thierry <ml at sekil.fr> a écrit :
>>>>
>>>>>
>>>>> Des logs lxc ou dmesg lorsque le container est lancé ?
>>>>>
>>>>> Manu
>>>>>
>>>>> Le 1 oct. 2014 à 11:45, Joris Michaux a écrit :
>>>>>
>>>>> J'ai oublié de préciser que quand les containers sont éteints, les 3
>>>>> interfaces fonctionnent correctement. (ping, ssh...)
>>>>>
>>>>> C'est à l'allumage des containers que le réseau tombe sur l'interface
>>>>> concernée.
>>>>>
>>>>> Typiquement :
>>>>>
>>>>> *Container 1 :*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *lxc.utsname = frp2007culxc.network.type = physlxc.network.flags =
>>>>> uplxc.network.link = eth1lxc.network.ipv4 = 10.170.2.187/28
>>>>> <http://10.170.2.187/28>lxc.network.ipv4.gateway =
>>>>> 10.170.2.190lxc.network.hwaddr = 00:1E:01:61:5B:86*
>>>>>
>>>>> eth1 cesse de fonctionner lorsqu'elle est mappée à l'allumage du
>>>>> container. (du mode "phys")
>>>>>
>>>>> *Les commandes avant allumage du container :*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *root at frp1007cu:/var/run/network# ip l1: lo: <LOOPBACK,UP,LOWER_UP>
>>>>> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT     link/loopback
>>>>> 00:00:00:00:00:00 brd 00:00:00:00:00:002: eth0:
>>>>> <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode
>>>>> DEFAULT qlen 1000    link/ether 00:50:56:85:67:17 brd ff:ff:ff:ff:ff:ff3:
>>>>> eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
>>>>> mode DEFAULT qlen 1000    link/ether 00:1e:01:61:5b:86 brd
>>>>> ff:ff:ff:ff:ff:ff4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
>>>>> pfifo_fast state UP mode DEFAULT qlen 1000*
>>>>>     link/ether 00:1e:fd:d8:a3:44 brd ff:ff:ff:ff:ff:ff
>>>>>
>>>>> *Après :*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *root at frp1007cu:/var/run/network# ip l1: lo: <LOOPBACK,UP,LOWER_UP>
>>>>> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT     link/loopback
>>>>> 00:00:00:00:00:00 brd 00:00:00:00:00:002: eth0:
>>>>> <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode
>>>>> DEFAULT qlen 1000    link/ether 00:50:56:85:67:17 brd ff:ff:ff:ff:ff:ff4:
>>>>> eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
>>>>> mode DEFAULT qlen 1000    link/ether 00:1e:fd:d8:a3:44 brd
>>>>> ff:ff:ff:ff:ff:ff*
>>>>>
>>>>> Ce comportement me parait normal, et est confirmé sur les autres hosts
>>>>> de LXC.
>>>>>
>>>>> Joris
>>>>>
>>>>> Le 1 octobre 2014 11:34, Emmanuel Thierry <ml at sekil.fr> a écrit :
>>>>>
>>>>>>
>>>>>> Le 1 oct. 2014 à 11:28, Joris Michaux a écrit :
>>>>>>
>>>>>> Manu,
>>>>>>
>>>>>> Le problème est survenu à 7h12 hier. Heure à laquelle le trafic a
>>>>>> balancé sur le deuxième serveur fonctionnel. Sans redémarrage. Depuis j'ai
>>>>>> redémarré le container plusieurs fois, et même une fois la machine.
>>>>>>
>>>>>> # ip netns et ip netns list ne revoient rien.
>>>>>>
>>>>>>
>>>>>> Il faut commencer par ça. S'il n'y a rien c'est que le problème vient
>>>>>> de là vu que la création des namespace réseau a échoué.
>>>>>> Du coup les interfaces doivent encore exister sur le namespace de
>>>>>> l'hôte, si ce n'est pas le cas c'est que le problème vient du matériel ou
>>>>>> des drivers ethernet.
>>>>>>
>>>>>> Que donne un simple :
>>>>>> # ip l
>>>>>>
>>>>>> Par ailleurs, tu dois vérifier que les interfaces sont bien
>>>>>> initialisées dans le dmesg :
>>>>>> # dmesg
>>>>>>
>>>>>> Manu
>>>>>>
>>>>>>
>>>>>> Aucune iptables en place sur le host (ni le fonctionnel, ni l'autre).
>>>>>>
>>>>>>
>>>>>> J'ai des iptables sur deux hosts hébergeant les Reverse-Proxy Nginx,
>>>>>> mais pas sur les deux hosts hébergeant les webservers. Je tape sur le bon
>>>>>> via des tunnels ssl (stunnel4). Le fait qu'ils aient chacun une interface
>>>>>> dédiée m'évite les iptables à ce niveau.
>>>>>>
>>>>>> PS : la machine à problèmes a une sœur jumelle fonctionnelle sur
>>>>>> laquelle je peux comparer les configurations, ce que je n'arrête pas de
>>>>>> faire depuis hier.
>>>>>>
>>>>>> Merci !
>>>>>>
>>>>>> Joris
>>>>>>
>>>>>> Le 1 octobre 2014 11:11, Emmanuel Thierry <ml at sekil.fr> a écrit :
>>>>>>
>>>>>>> Bonjour,
>>>>>>>
>>>>>>> As-tu redémarré les container ou bien le problème a-t-il eu lieu
>>>>>>> durant leur exécution ?
>>>>>>>
>>>>>>> Peux-tu exécuter les commandes suivantes ?
>>>>>>> # ip netns
>>>>>>> (pour chaque entrée de la liste => ${ns})
>>>>>>> # ip netns exec ${ns} ip l
>>>>>>> # ip netns exec ${ns} ip a
>>>>>>> # ip netns exec ${ns} ip r
>>>>>>> # ip netns exec ${ns} ip -6 r
>>>>>>> (et toute autre information utile comme les règles netfilter ou
>>>>>>> consors)
>>>>>>>
>>>>>>> Manu
>>>>>>>
>>>>>>> Le 1 oct. 2014 à 11:05, Joris Michaux a écrit :
>>>>>>>
>>>>>>> Bonjour à tous,
>>>>>>>
>>>>>>> Je vous écrit du fond de mon trou, je creuse depuis hier, et bientôt
>>>>>>> je ne pourrai plus sortir...
>>>>>>>
>>>>>>> *Contexte : *
>>>>>>> - 1 machine Debian 7 avec 3 interfaces :
>>>>>>>   |_ eth0 = 10.170.2.189
>>>>>>>   |_ eth1 = 10.170.2.187
>>>>>>>   |_ eth2 = 10.170.2.185
>>>>>>> - Rôle de la machine : héberger 2 containers LXC intégrant chacun un
>>>>>>> Apache
>>>>>>> - Configuration network des LXC : lxc.network.type = phys
>>>>>>>
>>>>>>> Le comportement du type "phys" de LXC est que l'interface ciblée est
>>>>>>> "aspirée" par le LXC (elle disparaît du ifconfig sur le host), et le
>>>>>>> container en bénéficie sans autre configuration.
>>>>>>>
>>>>>>> *Mon problème :*
>>>>>>> J'utilise ce mode de fonctionnement sur 5 machines en prod depuis 8
>>>>>>> mois, sans aucun problème. Depuis hier matin, les 2 LXC d'une des 5
>>>>>>> machines ont perdu le réseau, alors que les 8 autres continuent de
>>>>>>> fonctionner. Les configurations sont pupettisées, je ne vois pas comment
>>>>>>> elles auraient pu casser, sur une seule machine.
>>>>>>>
>>>>>>> Depuis hier je compare les fichiers de configuration des hôtes, des
>>>>>>> containers, les iptables, les routes, les tables arp... Je ne vois pas où
>>>>>>> est le problème.
>>>>>>>
>>>>>>> *Dernière chance :*
>>>>>>> J'ai créé un nouveau container sur ladite machine, et même tout
>>>>>>> neuf, il n'a pas de réseau.
>>>>>>>
>>>>>>>
>>>>>>> *Ma demande :Que vous ayez ou non déjà utilisé LXC, si vous avez
>>>>>>> n'importe quelle question bête à poser sur la configuration, ça peut
>>>>>>> m'éclairer sur un truc que je rate, et je vous en serai vraiment
>>>>>>> reconnaissant !*
>>>>>>>
>>>>>>> Merci à ceux qui me donneront quelques minutes !
>>>>>>>
>>>>>>> Joris M., un admin désemparé...
>>>>>>> _______________________________________________
>>>>>>> technique mailing list
>>>>>>> technique at lists.tetaneutral.net
>>>>>>> http://lists.tetaneutral.net/listinfo/technique
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.tetaneutral.net/pipermail/technique/attachments/20141001/80bc0f85/attachment.htm>

Plus d'informations sur la liste de diffusion technique