L'édition 2012 de la première présentation d'une série de 6 sur l'introduction aux systèmes GNU/Linux est disponible à la rubrique présentations. J'ai essayé de rendre «le propos» plus attrayant que lors des éditions précédentes réalisées avec Magicpoint.

Cette nouvelle publication a entraîné une révision des règles de construction des documents. La génération du fichier PDF correspondant au document source ODP se fait par un appel direct à libreoffice dans une règle de Makefile.

$(MAIN_DIR)/pdf/%.pdf: %.odp
        @if [ -z $(libreoffice) ]; then echo 'libreoffice indisponible'; exit 1; fi
        # Génération du fichier imprimable PDF
        @$(libreoffice) --headless --invisible --convert-to pdf -outdir $(MAIN_DIR)/pdf $?

Pour la création des images associées à chaque vue, pdftoppm a été abandonné au profit de convert, un des outils de la famille imagemagick. Avec convert, il est possible de contrôler la qualité du rendu des photos et autres graphiques en les «échantillonnant» avec des résolutions différentes. Pour les présantations publiées ici, la règle est la suivante.

$(OUTPUT)/$(BASENAME)-00.png: $(MAIN_DIR)/pdf/$(BASENAME).pdf
        # Génération d'un fichier image par vue
        @if [ ! -d $(OUTPUT) ]; then mkdir $(OUTPUT); fi
        @convert -density 720 $? -resample 150 $(OUTPUT)/$(BASENAME)-%02d.png

Le temps de traitement est le seul défaut de cette méthode.

Toutes les règles de traitement sont données dans le fichier Makefile.Rules.

Voilà pour ce court billet. Comme pour tous les autres documents du site, si vous avez des remarques sur la forme et le contenu, n'hésitez pas !

Voir la présentation ...

• RFC 5737 : IPv4 Address Blocks Reserved for Documentation

  Les blocs d'adresses réservées sont : TEST-NET-1 : 192.0.2.0/24 | TEST-NET-2 : 198.51.100.0/24 | TEST-NET-3 : 203.0.113.0/24

• RFC 3849 : IPv6 Address Prefix Reserved for Documentation

  Le préfixe réservé est le : 2001:db8::/32

En plus du contexte strict de la documentation, il est aussi possible d'utiliser les adresses privées ou locales qui ne doivent pas être routées sur l'Internet.

• RFC 1918 : Address Allocation for Private Internets

  Les blocs d'adresses privées sont : 10/8 | 172.16/12 | 192.168/16

• RFC 4193 : Unique Local IPv6 Unicast Addresses

  Le préfixe réservé est le : fc00::/7

Après avoir usé et abusé de la traduction d'adresses IPv4 ces dernières années, le fait d'utiliser des adresses IPv6 publiques routables dans une infrastructure de travaux pratiques semble «bizarre». Heureusement, le filtrage avec ip6tables permet de bloquer les accès depuis l'extérieur du périmètre. Du point de vue rédaction de documentation, on n'utilise que les adresses issues de son propre préfixe et on ne risque pas empiéter sur le plan d'adressage d'autrui.

Si vous êtes à la recherche de préfixes IPv6, la valeur des services tels que SixXS - IPv6 Deployment & Tunnel Broker ou Hurricane Electric Free IPv6 Tunnel Broker est inestimable. Le service SixXS distribue même gratuitement des préfixes /48 ; soit 65536 réseaux en /64. Voilà de quoi monter quelques maquettes d'interconnexion réseau.

Le document ne contient vraiment rien d'extraordinaire pour un développeur chevronné. L'objectif ici est de démystifier ce type de développement et d'amener un étudiant de niveau bac+2 à considérer que l'utilisation des sockets est tout à fait abordable.

Je suis satisfait de l'idée des échanges de chaînes de caractères entre deux hôtes réseau. Les étudiants voient ça comme une sorte de chat et «accrochent» plutôt bien. Pour cette édition 2012, je suis passé à un code 100% C puisque les entrées/sorties formatées doivent être réutilisées par la suite dans d'autres enseignements.

Je suis cependant embarrassé avec l'utilisation de scanf pour la saisie de chaînes de caractères comprenant des espaces ou des tabulations. J'ai abouti à la syntaxe suivante, qui n'est pas vraiment adaptée au débutant en Langage C. Je n'ai pas voulu faire de compromis avec les éventuels débordements de la mémoire tampon du flux d'entrée standard.

#include <stdio.h>

#define MAX_MSG 100
// 2 caractères pour les codes ASCII '\n' et '\0'
#define MSG_ARRAY_SIZE (MAX_MSG+2)
// Utilisation d'une constante x dans la définition
// du format de saisie
#define str(x) # x
#define xstr(x) str(x)

int main() {

  char msg[MSG_ARRAY_SIZE];

// snip
  puts("Saisie du message : ");
  memset(msg, 0x0, MSG_ARRAY_SIZE); // Mise à zéro du tampon
  scanf(" %"xstr(MAX_MSG)"[^\n]%*c", msg);
// snip

  return 0;
}

L'utilisation de ce support la semaine prochaine viendra clore la série de cours, travaux dirigés et travaux pratiques sur les réseaux de télécommunications en seconde année de DUT Génie Électrique & Informatique Industrielle à Toulouse. Certains supports comme celui sur la technologie Ethernet sont à retravailler. Bref, j'ai encore du pain sur la planche.

Mes recherches ont été infructueuses et je n'ai pas trouvé d'option adaptée pour le type inet6 ni dans les pages de manuels du fichier interfaces ni dans les exemples fournis avec le paquet ifupdown.

J'ai finalement obtenu un fonctionnement correct avec la syntaxe suivante :

# cat /etc/network/interfaces 
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet6 manual
    post-up ip link set dev eth0 up

Après redémarrage, on obtient bien le résultat attendu :

# ip -6 addr ls
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2001:db8:feb2:1:b8ad:ff:feca:fe02/64 scope global dynamic 
       valid_lft 2591527sec preferred_lft 604327sec
    inet6 fe80::b8ad:ff:feca:fe02/64 scope link 
       valid_lft forever preferred_lft forever

Chers lecteurs, toute proposition est la bienvenue.

Relativement aux pages classiques telles que celle du LARTC Routage avec plusieurs accès Internet/fournisseurs d'accès, chaque fonction introduite est accompagnée d'une analyse réseau avec une démarche de test précise.

La progression est l'autre point intéressant. On débute par la répartition de trafic sur les deux liens entre l'aire OSPF et le routeur opérateur puis les fonctions supplémentaires de tolérance aux pannes réseau viennent s'ajouter une à une ce qui permet une caractérisation pas à pas.

Les notions abordées sont tout à la fois «simples», comme l'illustration du fait que chaque paquet IP peut suivre un chemin propre au niveau réseau tout en préservant une connexion de bout en bout au niveau transport, ou plus «élaborées» comme le marquage de paquets et l'enregistrement des communications qui montrent qu'il est possible d'utiliser ces mécanismes sans nécessairement avoir recours à la traduction d'adresses. Sujet au combien polémique.

Bien entendu, toutes les relectures, les critiques et autres remarques sont les bienvenues.

Le support utilisé lors des éditions précédentes sur le routage Inter-VLAN comprenait à la fois la présentation de la technologie, un exemple d'implémentation et une partie travaux pratiques. J'ai essayé de rendre le contenu plus digeste en séparant la présentation de l'implémentation.

• L'article Introduction au routage inter-VLAN présente les concepts élémentaires sur les réseaux locaux virtuels et le routage associé.
• Le support de travaux pratiques du même nom couvre un exemple d'implémentation utilisant des commutateurs Cisco au niveau liaison et un système GNU/Linux au niveau réseau.
• Le support Introduction au routage dynamique avec OSPF s'appuie aussi le routage inter-VLAN. Il permet de caractériser la différence entre une topologie physique étoile et une topologie logique triangle.

Avec le buzz actuel sur OpenFlow, l'utilisation de Debian GNU/Linux et des logiciels de routage comme Quagga Routing Suite au niveau Control Plane est plus que jamais d'actualité.

Si les supports listés ci-dessus vous intéressent, toutes les relectures, les critiques et autres remarques sont les bienvenues.

Outre le fait de démystifier la compilation du noyau Linux auprès des étudiants, le but de ce support est de mettre en relation les fonctions réseau au sens large (routage, commutation, protocoles) et l'architecture du système d'exploitation associé à une plateforme matérielle. Avec l'évolution des architectures des équipements réseau, il est de plus en plus difficile d'identifier les fonctions qui sont traitées au niveau logiciel ou au niveau matériel. Je tente ici un rapprochement entre l'architecture d'un routeur et d'un serveur.

Dans un routeur, la couche Control Plane correspond à des fonctions purement logicielles telles que les démons de protocoles de routage par exemple. Une fois la décision logicielle d'acheminement d'un paquet vers une nouvelle destination prise, cette décision est mémorisée pour être exploitée de façon optimale par le matériel de la couche Data Plane.

C'est au niveau de cette couche Data Plane que les capacités de traitement des composants matériels sont prépondérantes dans le choix d'un équipement. Les composants doivent permettre le transit d'un maximum de flux réseau en parallèle. On parle ici de commutation de paquets et les composants spécialisés sont là pour «garantir» la bande passante par port comme le font les composants d'un commutateur de trames Ethernet au niveau liaison de données.

Lorsqu'il est question d'architecture, nous sommes bien souvent noyés dans le jargon. Forwarding Plane, Data Plane, et autres Crossbar Fabrics sont autant de noms différents pour un même principe général. Les seuls acronymes qui sont devenus à peu près standard et transversaux entre différents systèmes sont RIB pour Routing Information Base (au niveau Control Plane) et FIB pour Forwarding Information Base (au niveau Data Plane).

Challenge à 2€cts : retrouver l'algorithme proposé pour le traitement des entrées de la Forwarding Information Base dans la rubrique routage avancé des options du noyau Linux.

Maintenant, si l'on se réfère à l'architecture d'un PC datant d'une dizaine d'année, les performances ne pouvaient pas être comparables à celles de l'architecture décrite ci-dessus. En effet, chaque paquet devait transiter deux fois sur un bus partagé unique entre l'interface réseau et le processeur ; une fois à la réception et une fois à l'émission. Les évolutions dans l'architecture des serveurs ont conduit à une augmentation du nombre des cœurs et du nombre des bus. Tant et si bien qu'il est devenu légitime de se poser la question du choix entre les deux architectures lorsque le nombre d'interfaces est limité à 4 ou 8 ports.

Dans l'image ci-dessus, j'ai essayé de transposer l'architecture d'un routeur sur le modèle Nehalem utilisé dans de nombreux serveurs rackés. C'est une simplification dont le but est de montrer que le traitement de multiples flux réseau en parallèle est possible sur des chemins dédiés à cet usage. Il existe de nombreuses autres représentations possibles.

Puisque les deux familles d'architectures tendent à se «neutraliser», la différence devrait se faire sur les services proposés en plus des deux niveaux Control Plane et Data Plane. C'est ici qu'intervient le thème à la mode qui assure un bon clivage : la virtualisation. Dans un routeur, la virtualisation est généralement directement intégrée dans le système. La solution Virtual Routing and Forwarding en est un exemple chez Cisco. À l'opposé, une société comme Vyatta a bâti son portefeuille de solutions sur les fonctions de virtualisation présentes dans le noyau Linux ; le tout étant intégré dans des serveurs rackés.

On peut imaginer que lors des évolutions à venir les différences de conception sur la virtualisation vont s'estomper (une fois que KVM aura été adopté par tous les acteurs) et qu'un nouveau sujet clivant émergera. Il est donc essentiel de chercher à assimiler les mécanismes de fonctionnement du noyau Linux pour préparer cet avenir radieux ... où pas.

Lire la suite ...

Côté Debian GNU/Linux, je suis content d'être parvenu à poursuivre l'exploitation de systemimager grâce à alien. Le truc à consisté à passer par une étape intermédiaire dans la conversion des paquets .rpm en .deb. Après avoir téléchargé les paquets snapshots à l'adresse http://download.systemimager.org/~bli/systemimager/, il était impossible de faire une conversion directe du fait de l'emploi du caractère '_' dans le champ version du paquet. En passant par un paquet .tgz, la notion de version disparaît et le tour est joué.

$ fakeroot alien --to-tgz --scripts systemimager-server-4.1.99.svn4556_bli-1.noarch.rpm
$ fakeroot alien --to-deb systemimager-server-4.1.99.svn4556_bli.tgz

On répète l'opération pour tous les paquets à installer sur le système. L'exploitation de systemimager présente quelques limites qui vont certainement devenir critiques dans le futur. Seul le noyau 2.6.32 de la version stable (Squeeze) de Debian est supporté et il faut encore utiliser l'ancienne génération de grub via le paquet grub-legacy. Malgré ces limitations, systemimager conserve tous ses atouts dans la gestion d'un parc de postes de travaux pratiques. Avec l'architecture mise en place, il est possible d'enchaîner les séances de travaux pratiques système au cours desquelles la configuration des postes est sévèrement malmenée. Au début d'une nouvelle séance, la restauration de tous les postes de la salle ne dépasse pas le temps du laïus de lancement.

Pour faire dans le grandiloquent pompeux, on peut dire que le fait que l'étudiant soit à l'initiative de la restauration de son poste est l'acte pédagogique fondateur de l'enseignement système et réseau.

Lire la suite ...

Voici la liste de ces documents :

• Le syllabus du projet définit les conditions d'organisation et d'évaluation du projet.
• L'article sur les concepts élémentaires en sécurité de l'information sera utilisé pour lancer la partie cours du projet.
• Le tableau des présentations et rapports des sessions précédentes constitue une base de départ pour cette nouvelle année universitaire.

Avec quelques mois de recul, je trouve que le ton de la présentation de l'équipe attaque 2010 est un tantinet fanfaron. Néanmoins, le niveau d'investissement des étudiants des trois équipes a globalement été excellent et les résultats très bons tant sur le plan technique que sur le plan sensibilisation à la sécurité des systèmes d'information.

Les retours des anciens étudiants montrent que le vol de ses identifiants dans un cadre pédagogique défini est une expérience formatrice assez efficace. C'est certainement plus efficace qu'un cours magistral sur le même thème ; et ce quelles que soient les qualités du prof !

Voir la présentation ...