Suis-je le seul à avoir le sentiment que le second évènement médiatique tombe curieusement au bon moment pour éclipser le premier ?

La Constitution Française modifiée

Le (re-)mariage du petit nicolas[1]

Décidément, notre beau pays n'a pas fini de m'étonner..


[1] Et pendant ce temps-là, au siège du parti socialiste.. ah bah non rien, ils se sont abstenus.

Pour continuer sur le ServerIron, voici une information qui pourra peut-être éviter à quelqu'un de s'arracher les cheveux en salle blanche de 4h à 6h du matin (vécu).

Dans le cas où vous utilisez un ServerIron de chez Foundry directement connecté à un routeur, et que du VRRP [1] est actif sur celui-ci, il se produit un conflit entre les adresses MAC[2] virtuelles utilisées par le VRRP et celles utilisées par le ServerIron pour dialoguer avec les serveurs réels. Ce conflit résulte en une absence pure et simple de réponse du ServerIron aux requêtes http.
La solution est tout simplement d'indiquer au ServerIron qu'il est directement connecté à un routeur sur ce port, à l'aide de la directive :

si votre routeur est connecté sur le premier port Ethernet du ServerIron.

La description de cette option dans la documentation Foundry[3] est pour le moins succinte :


[1] Virtual Router Redundancy Protocol. Protocole permettant de mettre en place une redondance entre deux routeurs. Si le premier ne répond plus, le second routeur prend le relais. Plus d'infos sur l'article de Wikipedia.
[2] http://en.wikipedia.org/wiki/Mac_address
[3] http://www.foundrynetworks.co.jp/services/documentation/siFWLB/ServerIron_FWLB_400-800.html

Pour ceux qui arriveraient ici sans savoir ce qu'est un ServerIron, il s'agit d'un load-balancer (répartiteur de charge) de marque Foundry. Cet équipement est généralement utilisé comme serveur Web "virtuel" placé en frontal, redistribuant les requêtes à un ou plusieurs serveurs Web "réels". Cela permet non seulement de répartir la charge entre plusieurs machines, mais également d'assurer une certain forme de haute disponibilité (High Availability ou HA) puisque cet équipement sait détecter la bonne santé des serveurs "réels", et répartir les requêtes sur les serveurs fonctionnels.

Comme indiqué précédemment, la configuration par défaut n'implique qu'un seul virtuel, qui aura ici comme adresse externe 10.0.0.1 et 192.168.0.1 comme adresse interne, et par exemple deux serveurs réels, 192.168.0.51 et 192.168.0.52. En imaginant que nous ne répartissons que le protocole HTTP sur le port 80, la configuration se rapportant à ce serveur virtuel se présenterait ainsi :



Imaginons maintenant que nous avons besoin de créer un second serveur virtuel, 10.0.0.2, qui utilisera les mêmes serveurs réels que le premier, également sur le port http. La configuration qui vient naturellement à l'esprit est la suivante :



Sauf que cela ne fonctionne pas. Le ServerIron vous indique poliment que le port http de ces deux serveurs est déjà lié à un autre serveur virtuel. Cette limitation est dûe à la façon dont les ports sont liés entre eux au niveau de la table de translation du ServerIron. Il est donc nécessaire de ruser, en indiquant un autre port de destination (180 dans notre exemple) sur les serveurs réels, de la manière suivante :



Là, pas d'erreurs, ces ports ne sont pas déjà utilisés donc tout se passe bien. Mais bien sûr, il n'est pas question de faire tourner votre serveur Web sur des ports différents sur les serveurs réels. Vous devez donc utiliser la directive no port <port> translate. Cette directive permet d'indiquer au ServerIron qu'il ne doit pas tenir de compte du port de destination que vous avez indiqué, mais bien utiliser le même port que celui sur lequel les requêtes arrivent au serveur virtuel. La configuration devient donc :



De cette façon, les requêtes arrivant sur le port http du ServerIron à l'adresse 10.0.0.2 seront donc bien renvoyées vers les ports http des serveurs réels.

J'ai essayé de rendre cette explication la plus claire possible, mais n'hésitez pas à vous réferrer à la documentation[1] si ce n'était pas le cas, voir la rubrique Many-To-One TCP/UDP Port Binding.



[1] http://www.foundrynetworks.co.jp/services/documentation/siug/ServerIron_Server_Load_Balancing.html

Si, comme moi, vous avez encore une ou plusieurs machines en parfait état de marche mais dotées de cartes graphiques de marque NVIDIA vieillissante, vous risquez de rencontrer un jour le problème suivant.

Vous venez, pour une raison ou pour une autre, de mettre à jour votre noyau linux vers une version plus récente[1]. Vous devez utiliser la version "Old Legacy Chipsets"[2] des drivers nvidia, ce dernier ayant décidé de ne plus assurer le support de ces cartes "dépassées"[3] dans les nouveaux drivers. Et là, c'est le drame.



Et oui, bien que le fichier config.h présent dans les sources des versions antérieures des noyaux soit clairement indiqué comme à ne plus utiliser, le driver[4] fait toujours appel à lui. Et bien sûr ce fichier n'existe plus dans les versions récentes du noyau.

La solution la plus simple à ce problème est, à mon sens, de recréer ce fichier dans les sources de votre noyau, [path vers votre kernel]/include/linux/config.h avec le contenu suivant :



Voilà, fin de l'astuce, l'installation du driver NVIDIA devrait maintenant se dérouler normalement. Et vous n'avez pas besoin de racheter un Bi-Xeon Dual Core Woodcrest avec 4 Go de RAM et une GeForce 8800 pour remplacer une machine qui fait tout ce dont vous avez besoin sans nécessiter la construction d'une centrale électrique pour elle seule.


[1] dans mon cas un kernel 2.6.19.2 vanilla
[2] 1.0-7184 dans mon cas : http://www.nvidia.com/object/linux_display_ia32_1.0-7184.html
[3] comprenez ne leur rapportant plus assez d'argent
[4] ou plus exactement la glue entre le kernel et le module binaire nvidia, mais ne chipotons pas

Vendredi 24 novembre 2006. Centre culturel de Compiègne, espace Jean Legendre.

Le président de l'Université de Technologie de Compiègne, assisté du président de PSA Peugeot Citroën et de divers comparses, va avoir le plaisir d'orchestrer la cérémonie de remise des diplômes de la promotion 2006, dont je fais partie.

Un par un, les ingénieurs fraîchement diplômés vont être appelés sur l'estrade et recevoir leur diplôme ainsi que les félicitations d'usage. Un moment unique qui restera gravé dans leurs mémoires.

Ou pas.


En bon geek, j'ai préféré me rendre à la neuvième réunion du FRnOG[1] et assister à diverses conférences données par Interoute, Cisco, Dédibox et HSC. Pour être honnête, seules les conférences de Cisco sur les performances des routeurs IPv6 et celles d'arnaud de Bermingham[2] m'ont semblé réellement intéressantes, le consultant d'HSC n'ayant probablement jamais mis les pieds sur le terrain, et l'intervention du CTO d'Interoute étant trop marketing à mon goût.

Mais bon, c'était l'occasion de croiser plusieurs connaissances du milieu de l'hébergement, donc je n'ai pas perdu mon temps. Par contre, j'aurai bien aimé voir Bao qui, bien qu'inscrit, n'était pas présent :'(

J'entends d'ici certaines mauvaises langues dire que je n'ai pas pu me retenir de sécher une dernière fois les amphis de l'UTC, mais je démens. Je n'avais tout simplement pas envie d'apporter ma contribution à ce type d'évènement bien trop formel pour moi.


[1] French Network Operators Group : http://frnog.org
[2] L'homme derrière dedibox