Aldevar

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

J’ai longuement hésité à mettre ce rapport de stage en ligne pour plusieurs raisons. Tout d’abord, ce rapport n’est pas vraiment représentatif du travail fournit. La majorité des solutions expliquées m’ont demandées beaucoup de temps de recherche et d’arrachage de cheveux (notamment pour la migration des comptes sous Lotus Notes). Ensuite, la qualité rédactionnel est loin d’être au rendez-vous. On m’a beaucoup reproché que ce rapport était trop technique et c’est plutôt vrai. Enfin, ce document ne décrit pas vraiment l’installation de Squid et d’Egroupware. Ces parties sont survolées et je m’attarde plus sur la résolution des problèmes rencontrés (résoudre un conflit de schéma LDAP quand on a jamais vu OpenLDAP de sa vie n’est pas chose aisée).

Un mois après la fin de la formation, je me décide tout de même à le mettre en ligne. Je pense que ce rapport décrit plutôt bien ce que peut être le métier de technicien réseau dans une administration ou une PME. Le problème lors de la mise en place d’un nouveau service n’est pas l’installation et la configuration de ce service mais la migration des anciens services utilisés vers les nouveaux. Surtout lorsque l’ancien service est un système propriétaire vieillissant (Je veux parler ici de Lotus Notes 5).

Squid est un proxy http très utilisé, dont j’ai pu découvrir une partie des possibilités. Egroupware est un groupware fournissant un agenda, un client mail, un carnet d’adresses, un système de réservations des ressources et plusieurs autres choses, le tout dans une interface web. Je vous invite à tester la demo sur le site du projet.

Ce rapport fait 38 pages et voici son sommaire :

1. Remerciements
2. Objectif du stage
3. L’entreprise
   1. Historique
   2. La structure actuelle
   3. Le service informatique
4. Spécifications
   1. Environnement de travail
   2. L’existant
   3. Besoins et contraintes
      1. Squid
      2. Egroupware
5. Mise en œuvre
   1. Proxy
      1. Planning prévisionnel
      2. Mise en œuvre
         1. Squid
         2. Sarg
         3. Squidguard
      3. Problèmes rencontrés
      4. Annexes
   2. eGroupware
      1. Schéma fonctionnel
      2. Planning previsionnel
      3. Mise en œuvre
         1. Configuration de openldap
      4. Problèmes rencontrés
         1. Conflit de schéma openldap
         2. Configuration de felamimail
      5. Préparation de la migration des utilisateurs
         1. Création du carnet d’adresses principal
         2. Importation des agendas Lotus Notes
         3. Importation des carnet d’adresse Lotus Notes
         4. Exportation des mails depuis LotusNotes dans eGroupware
         5. Importation mail depuis roundcube
      6. Annexes
6. Procédure de migration serveur
   1. Sur Revy
   2. Sur Revnew

Lien de téléchargement (pdf)

Suite de la Question Réseau Qui Va Bien, nouveau billet purement réseau donc. Je comptais me lancer dans la description des paquets TCP, mais je pense qu’il est plus intéressant de se pencher d’abord sur UDP avant d’appréhender TCP.

UDP (Pour User Datagram Protocol) se situe dans la couche 4 du modèle OSI (couche transport). Pour rappel, au niveau de la couche 3 (IP), les datagrammes sont routés d’une machine à une autre en fonction des adresses IP (en fait, le routage se fait en fonction de l’adresse réseau, voir QRQVB : L’adresse IP). Lors de cette opération de routage, aucune distinction n’est faite entre les différents services pour lesquels ces paquets peuvent être destinés. Que ce soit pour une connexion SSH (port 22) ou HTTP (port 80) ou autre, les datagrammes IP sont tous indifféremment mélangés.

La couche 4 du modèle OSI ajoute un mécanisme qui permet l’identification du service  concerné. Plusieurs programmes de plusieurs utilisateurs pouvant simultanément circuler sur le réseau, il est indispensable de faire un tri entre les applications. Ici, l’idée est d’associer la destination du paquet à une fonction. L’identification de cette fonction ce fait à l’aide d’un chiffre nommé Port.

En tête UDP

Lors de l’étude des datagramme IP, nous avions vu le contenu de l’entête du paquet (partie verte). Ici,  nous allons observer le contenu de l’entête du message (partie jaune) lorsque l’on traite un paquet UDP.

Le paquet UDP est composé de 8 octets.

Les 2 premiers octets contiennent le port source. Codé sur 16 bits donc. C’est le numéro de port de l’émetteur du paquet. C’est aussi le numéro de port sur lequel le destinataire doit envoyer sa réponse.

Les octets 3 et 4 stockent le port de destination. C’est sur ce port que sera remis le paquet lors de sa livraison à la machine ciblée.

Le port étant un entier positif de 16 bits, on en déduit que les bornes sont 0 – 65535 (2^16). Cependant, le port 0 n’est pas exploitable.

Les octets 5 et 6 contiennent la longueur de l’entête UDP et du message. Sa longueur minimal est 8 (entête UDP avec 0 données à transporter) et sa longueur maximal 2^16 = 65535 (64ko).

Les 2 derniers octets contiennent le cheksum. C’est la somme de contrôle de l’entête UDP et des données qui suivent.

Ports réservés

Toute machine qui utilise la pile TCP/IP se doit de connaitre un certains nombre de services bien connus, aussi appelé « well known port number » pour pouvoir dialoguer avec les autres machines sur internet. Sur une machines Unix, cette liste est placée dans le fichier /etc/services et se doit d’être lisible par tous les utilisateurs et toutes les applications. Voici un extrait du contenu de ce fichier :

Nom             Port/Protocol     Commentaire

netstat		15/tcp
 qotd		17/tcp		quote
 msp		18/tcp		# message send protocol
 msp		18/udp
 chargen	19/tcp		ttytst source
 chargen	19/udp		ttytst source
 ftp-data	20/tcp
 ftp		21/tcp
 fsp		21/udp		fspd
 ssh		22/tcp		# SSH Remote Login Protocol
 ssh		22/udp
 telnet		23/tcp
 smtp		25/tcp		mail
 time		37/tcp		timserver
 time		37/udp		timserver
 rlp		39/udp		resource	# resource location
 nameserver	42/tcp		name		# IEN 116
 whois		43/tcp		nicname
 tacacs		49/tcp				# Login Host Protocol (TACACS)
 tacacs		49/udp
 re-mail-ck	50/tcp				# Remote Mail Checking Protocol
 re-mail-ck	50/udp
 domain		53/tcp				# name-domain server
 domain		53/udp
 mtp		57/tcp				# deprecated
 tacacs-ds	65/tcp				# TACACS-Database Service
 tacacs-ds	65/udp
 bootps		67/tcp				# BOOTP server
 bootps		67/udp
 bootpc		68/tcp				# BOOTP client
 bootpc		68/udp
 tftp		69/udp
 gopher		70/tcp				# Internet Gopher
 gopher		70/udp
 rje		77/tcp		netrjs
 finger		79/tcp
 www		80/tcp		http		# WorldWideWeb HTTP
 www		80/udp				# HyperText Transfer Protocol

Les ports 1 à 1023 sont réservés aux « well known ports ». Ils ne peuvent être utilisés que par des applications qui s’exécutent avec des droits privilégiés (root). Les autres ports peuvent être utilisés librement sans privilège particulier et sont en général employés par les applications clientes. Par exemple, sur ma machine, en ce moment, mon client IRC utilise le port 59175 pour communiquer avec le serveur irc holmes.freenode.net.

Mode non connecté

Contrairement à TCP, UDP est conçu pour permettre un échange de données entre 2 applications sans échange préliminaire. UDP est utilisé si les données à transmettre n’ont pas besoin d’être fragmentées en plusieurs paquet. La paquet est ainsi envoyé sans s’assurer qu’il arrive bien à destination. UDP est appelé mode de transport non connecté par opposition à TCP. Plus particulièrement, les paquets a destination d’une application UDP sont conservés dans une pile de type FIFO. Si l’application destinatrice ne les “consomme” pas assez rapidement, les plus anciens paquets risquent d’être écrasés par les plus récents… Un risque supplémentaire de perte de données.

Nous verrons comment TCP peut palier à ce problème dans la prochaine QRQVB