Aldevar

Nous avons récemment installé une nouvelle machine qui sert de serveur principal pour notre nouveau système de sauvegarde. Lors des tests des sauvegardes complètes du week end, le chipset réseau du serveur s’écroulait lamentablement sous la charge du nombre de paquets qui arrivaient. Même si le réseau semblait toujours fonctionnel (service réseau lancé, ifconfig ne signal rien d’anormal), la machine était injoignable et ne répondait pas au ping. Dans certains cas, un redémarrage du service réseau ne suffit pas à retrouver une connectivité.

A l’heure où la sauvegarde s’arrêtait, voici ce qu’on pouvait trouver dans /var/log/messages :

server1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
server1 kernel: bnx2: eth0 NIC Copper Link is Down

La résolution du problème passe par une mise à jour du pilote.

On trouve le pilote pour ce chipset à cette page : http://www.broadcom.com/support/ethernet_nic/netxtremeii.php

Après avoir extrait l’archive, on installe les sources :

rpm -ivh netxtreme2-<version>.src.rpm

Installation de kernel-devel pour pouvoir compiler les sources du pilotes :

yum install kernel-devel

Construction du paquet :

cd /usr/src/redhat
rpm -bb SPECS/netxtreme2.spec

Installation du paquet fraichement installé :

rpm -ivh RPMS/<arch>/netxtreme2-<version>.<arch>.rpm

déchargement de l’ancien module :

rmmode bnx2

Chargement du nouveau module :

modprobe bnx2

Suite à cette petite manipulation, plus de soucis de chipset réseau qui ne répond plus. Problème résolu

La ville de Rennes a décidé de mettre à la disposition de ses citoyens les données publiques de son réseau de transport. Ces données comportent les horaires et circuits des bus et métro ainsi que les points de regroupement des Vélos Star (le vélib rennais). Sont également concernés les coordonnées et horaires des associations de quartier. Toutes ces données sont disponibles sous licence Creative Commons.

Rennes métropole espère grâce à cela que les développeurs en herbe créent des applications pour smartphones afin de faciliter la vie dans la capitale bretonne. Selon Noël Philippe, directeur général des services urbains de Rennes Métropole « Le processus classique d’appel à projets pour une collectivité est très lourd. Il faut lancer un appel à candidatures, rédiger un cahier des charges, etc. Dans un an, nous aurions peut-être juste sélectionné nos partenaires. Grâce à l’open source, nous espérons que des applications seront disponibles d’ici quelques mois. »

Dans un premier temps, un usage commercial de ces données devrait être interdit. Il est envisagé d’autoriser par la suite l’usage commercial pour que les développeurs puissent vendre leurs applications.

Toutes les données de transport sont disponibles depuis le 1er Mars à l’adresse data.keolis-rennes.com. Elles seront complétées dans le courant de l’année 2010 par les données des organismes publics et des associations puis seront toutes regroupées sur le portail data.rennes.fr. Les documents seront proposés au format XML avec une API documentée afin de faciliter le développement.
Afin de lancer le projet, la ville de Rennes devrait organiser durant le printemps 2010 une concours d’applications dont les modalités et les lots sont encore à définir.

Ce projet est une première en France. Il a été inspiré par des initiatives similaire à l’étranger (Londre, San Francisco, Portland) et il est possible, suivant son impacte et sa réussite qu’il créé des émules dans d’autres ville française.

Source : http://www.rennes-metropole.fr/espace-presse,76701/

Ksplice Uptrack est une technologie permettant de mettre son kernel Linux à jour sans avoir à redémarrer le système d’exploitation. Depuis peu, cette application est utilisable par le grand public. On peut ainsi télécharger une version d’essai pour 6 versions de Linux ou une version totalement gratuite pour Ubuntu 9.04 et 9.10 (ne me demandez pas ce qui a justifié ce choix…).

Cette version d’essai fonctionne avec les distributions suivantes :

• Red Hat Entreprise Linux (RHEL) 4 et 5
• CentOS 4 et 5
• Debian 5.0 Lenny
• Ubuntu LTS 8.04 Hardy
• Parallels Virtuozzo Containers (3.0 et 4.0)
• OpenVZ (El 5).

Une fois la version d’essai arrivée à échéance, les tarifs mensuels pour continuer à profiter de ses services vont de 3,95 à 9.95 $ US. D’après Ksplice, les différentes distributions GNU/Linux requièrent en moyenne 1 redémarrage par mois afin de profiter pleinement des mises à jour de sécurités du noyau. Leur service permettrai donc de sauver du temps et de diminuer les pertes de performances dues aux redémarrages.

Les sources sont également disponibles sur cette page.

Nouvelle QRQVB et pas des moindres, le protocole TCP (Transmission Control Protocol, Protocole de Contrôle de Transmission).  Comme son petit frère UDP, TCP se situe en couche 4 du modèle OSI.

Caractéristique de TCP

TCP est bien plus compliqué qu’UDP examiné au chapitre précédent. Il apporte en contrepartie des services beaucoup plus élaborés.

• TCP contient un mécanisme pour assurer le bon acheminement des données. Cette possibilité est absolument indispensable dès lors que les applications doivent transmettre de gros volumes de données de façon fiable. Cette fonction est assurée par un mécanisme d’acquittement (ou accusé de réception). Les paquets de données sont acquittés de bout en bout et non de point à point. C’est à dire que ce sont les machines sources et machines de destinations qui s’occupent de cela et non les routeurs qui se situent entre les 2.
• Le protocole TCP permet l’établissement d’un circuit virtuel entre les 2 machines qui échangent de l’information (Voir a ce propos le commentaire de Guizmo.7). On dit aussi que TCP  fonctionne en mode connecté (par opposition à UDP qui est en mode non connecté). En pratique, l’une des 2 machine doit effectuer un appel que l’autre doit accepter. S’en suit une discutions afin d’établir certains paramètres de communication. Une fois les préliminaires terminés, les protocoles informent les applications respectives que la connexion est établie et que le transfert peut débuter. Durant le transfert, le dialogue entre les protocoles continue, pour vérifier le bon acheminement des données.
• TCP a la capacité de mémoriser les données. Les paquets pouvant prendre chacun un chemin différent pour arriver à destination, il arrive que ceux ci n’arrivent pas dans le bon ordre. Grâce à cette capacité de mémorisation, TCP garde les paquets un certains temps et les reconstitue lorsqu’ils sont tous arrivés afin de présenter les données à l’application.
• TCP simule une connexion en « full duplex ». Pour chacune des 2 machines en connexion, l’opération qui consiste à lire des données peut s’effectuer indépendamment de celle qui consiste à en écrire.

Entête TCP

L’entête TCP est codé sur 20 octets hors options.

• Port Source (16 bits): Port utilisé par l’application sur la machine source.
• Port Destination (16 bits): Port de destination.
• Numéro d’ordre (32 bits): Correspond au numéro du paquet. Cette valeur permet de situer à quel endroit du flux de données le paquet, qui est arrivé, doit se situer par rapport aux autres paquets.
• Numéro d’accusé de réception (32 bits): Acquittement pour les paquets reçus. Cette valeur signale le prochain numéro de paquet attendu. Par exemple, si il vaut 1500, cela signifie que tous les datagrammes <1500 ont été reçus
• Offset (4 bits): Le champ Offset est codé sur 4 bits et définit le nombre de mots de 32 bits dans l’entête TCP. Ce champ indique donc où les données commencent.
• Réservé (6 bits): Champ inutilisé actuellement. Il était à l’origine prévu pour l’avenir. On peut dire aujourd’hui que ce champ restera vide.
• Drapeaux (flags) (6×1 bit): Les drapeaux représentent des informations supplémentaires :
  URG: si ce drapeau est à 1 le paquet doit être traité de façon urgente.
  ACK: si ce drapeau est à 1 le paquet est un accusé de réception.
  PSH (PUSH): si ce drapeau est à 1, le paquet fonctionne suivant la méthode PUSH.
  RST: si ce drapeau est à 1, la connexion est réinitialisée.
  SYN: Le Flag TCP SYN indique une demande d’établissement de connexion.
  FIN: si ce drapeau est à 1 la connexion s’interrompt.
• Fenêtre (16 bits): Champ permettant de connaître le nombre d’octets que le récepteur souhaite recevoir sans envoyer d’accusé de réception.
• Somme de contrôle (Checksum ou CRC): La somme de contrôle est réalisée en faisant la somme des champs de données de l’en-tête, afin de pouvoir vérifier l’intégrité de l’en-tête
• Pointeur d’urgence (16 bits): Indique le numéro d’ordre à partir duquel l’information devient urgente.

Établissement d’une connexion

Une ouverture de connexion TCP s’effectue en 3 temps.

L’émetteur du premier paquet doit avoir connaissance du couple IP : Port de l’application de la machine réceptrice (par exemple, on contact un serveur HTTP sur le port 80 qui lui est dédié). L’émetteur de ce premier paquet est à l’origine de l’établissement du circuit virtuel. C’est une attitude qualifiée de « cliente« .

Le récepteur du premier paquet accepte l’établissement de la connexion, ce qui suppose qu’il était prêt à le faire avant que le client en prenne l’initiative. C’est une attitude de « serveur« .

Le client envoie un segment comportant le drapeau SYN à 1. Le serveur répond avec sa propre séquence (SYN = 1) mais il doit aussi acquitter le paquet précédent, ce qu’il fait avec ACK. Le client répond alors avec un acquittement de la séquence du serveur (ACK = 1).

Une fois achevée cette phase appelée « Three-way handshake », les 2 applications sont en mesure d’échanger des données.

Conclusion

Voilà pour une première partie sur TCP. La seconde partie permettra de voir comment fonctionne la clôture d’une connexion ainsi que l’acquittement des paquets durant les transferts de données.  TCP est bien plus compliquer à aborder qu’UDP et c’est pourquoi je préfère le faire en 2 parties. J’essaierai d’ajouter dans la seconde partie quelques captures de trames afin d’illustrer ceci plus clairement. N’hésitez pas à laisser des commentaires si certaines notions vous paraissent mal expliquées ou trop survolées dans ce billet.

Après une semaine de travaux, le site de la communauté francophone de LinuxMint réouvre avec une toute nouvelle interface. Dorénavant propulsé par Joomla, le site met en avant l’esprit communautaire et social avec notamment la possibilité d’ajouter des utilisateurs en tant qu’amis, ou encore de rejoindre des groupes d’utilisateurs comme les groupes KDE, Gnome, France, Belgique etc…

S’ajoute à ça un système permettant de donner des points aux utilisateurs sur le forum.

Je vous invite donc tous à vous y rendre, ne serait-ce que pour tester toutes ces nouvelles fonctionnalités peu communes sur les sites des communautés des différentes distributions.

www.linuxmint-fr.org

Hier, le NRO (Number Resolution Organization), représentant officiel des 5 Registres Internet Régional (Regional Internet Registries – RIR) qui sont en charge de l’allocation des plages d’adresses IP, a annoncé que moins de 10% des adresses IPv4 sont encore disponibles. Ce stock devrait s’épuiser d’ici 2011 ou 2012. Le problème est connu depuis longtemps et les FAI comme les entreprises mettent du temps à passer à IPv6. Pour rappel, la norme IPv6 a été créée en 1994. Les FAI ont donc largement eu le temps de le prendre en compte et de s’y préparer.

La solution pour pallier au manque d’adresses IPv4 semble donc clair pour tout le monde : switcher vers IPv6. Cette solution inéluctable a pour l’instant pu être retardée grâce à 2 technologies : DHCP et NAT. DHCP pour qu’un appareil éteint de conserve pas une adresse IPv4 inutilisée, permettant de réatribuer cette adresse à un autre appareil. Le NAT quant à lui permet à des machines possédant une adresse privée d’accéder à internet par un système de transformation d’adresse IP. Je reviendrai plus en détail sur cette technologie dans un prochain article.

Pour ne pas s’embêter avec IPv6, les FAI nous sortent donc un nouveau lapin de leur chapeau : le NAT « globalisé ». L’idée est la suivante : partager une adresse publique IPv4 entre plusieurs abonnés. Les box des abonnés recevraient chacune une adresse privée et le FAI s’occuperait du NAT. Ça n’a l’air de rien comme ça, mais ça signifie l’arrêt des serveurs perso hébergés à la maison et du peer to peer car l’abonné serait alors incapable de mettre en place une redirection de port vers sa machine comme on le fait actuellement lorsqu’on configure sa box.

Les sources :

L’annonce du NRO

Le NAT élargie