[technique] lxc.network.type = phys

Joris Michaux joris.michaux at gmail.com
Lun 6 Oct 15:35:04 CEST 2014 

Bonjour à tous,

C'est lundi ! Et le lundi, c'est cauchemars !

Le problème vient de survenir sur 2 machines en simultané !

Je relance une batterie de tests, mais ça ne donne toujours rien...
Personne n'a eu d'illumination ?

Le backup d'une des deux machines est en court, je garde l'autre pour
expérimenter...

Joris

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

> 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/20141006/f7ed7bbe/attachment.htm>

Plus d'informations sur la liste de diffusion technique