Je ne sais pas si ce petit tutoriel servira à quelqu’un d’autre que moi, car c’est vraiment quelque chose de assez particulier. Mais étant donné que cela m’a fait perdre un peu de temps vendredi dernier, je me suis dit qu’il valait mieux le mettre par écrit. Et quitte à le faire, autant le mettre sur le blog, où ça peut peut-être depanner quelqu’un dans la même situation.

Le problème, à la base, c’est que j’ai tendance à oublier les possibilités offertes par les tunnels SSH. Ou plutôt, j’ai tendance à les considérer plus compliqués qu’ils ne le sont et du coup ne songer à les utiliser qu’en dernier ressort.

Mais à chaque fois que je me décide à les utiliser, je constate que les tunnels SSH en plus d’être très puissants ne sont pas compliqués, il suffit d’avoir les idées claires.

Description du problème

Vendredi dernier j’étais confronté à un problème en apparence simple mais qui m’a pris la tête pendant un moment.

J’avais un gros volume de données (en occurrence un fichier grosfichier.tgz de plusieurs gigas) à copier entre deux machines distantes. Ces deux machines étaient dans deux VLANs différentes et elles ne se voyaient pas. Appelons sourcetux à la machine qui a le fichier et cibletux à la machine sur laquelle on veut le copier.

J’avais sous la main une troisième machine, que nous appellerons passepartouttux, qui avait accès aux deux machines précédentes, mais où je ne pouvais pas stocker des données (pas de place disque).

Comment faire donc pour transférer mon gros fichier entre les deux machines ?

La solution

La solution la plus simple (et la moins efficiente) aurait été de copier le fichier sur passepartouttux et de le renvoyer ensuite vers cibletux. Mais passepartouttux étant une machine avec un petit disque déjà surchargé, cette solution ne risquait pas de marcher.

Ma première idée était d’utiliser scp depuis passepartouttux pour copier de sourcetux à cibletux, mais j’ai vite remarqué que cela ne pourrait pas marcher, car il aurait besoin d’établir SSH entre sourcetux et cibletux.

J’ai ensuite cherché des possibles alternatives simples, mais aucune ne convenait.

Lorsque j’ai posé la question à mon collègue Fred, il m’a dit sans hésiter d’utiliser des tunnels SSH. Ma première réaction a été plutôt négative, ça me semblait une procédure assez lourde pour une toute petite opération. Mais lorsque j’ai bien réfléchi, je me suis rendu compte de que Fred avait (encore une fois) raison, utiliser des tunnels SSH était non seulement une bonne solution mais aussi une solution simple.

La seule particularité du cas c’est que depuis passepartouttux on peut se connecter à sourcetux et à cibletux, mais depuis sourcetux et cibletux on ne peut pas se connecter à aucune des autres deux machines. En conséquence, passepartouttux devait être à l’origine des deux tunnels.

Des passepartouttux on ouvre donc un tunnel dont l’entrée est le port 10000 de sourcetux et la sortie le port 10000 de passepartouttux :

Ensuite on ouvre un autre tunnel depuis passepartouttux, cette fois avec son entrée dans le port 10000 de passepartouttux et la sortie le port 10000 de cibletux :

On vient donc de créer un tunnel virtuel entre le port 10000 de sourcetux et le port 10000 de cibletux.

Maintenant il suffit d’aller sur cibletux et se mettre à l’écoute sur le port 10000, redirigeant la sortie vers un fichier, et d’aller sur sourcetux pour envoyer le fichier vers son propre port 10000. Pour les deux opérations, la commande magique est netcat, nc.

Côté récepteur :

Côté émetteur :

Et le tour est joué !

Ah, le printemps ! Les premiers beaux jours, la nature en fleur (et les allergies qui explosent) les journées de plus en plus longues, les filles qui changent les lourds manteaux d’hiver par des tenues bien plus saillantes…

Et oui, le printemps est une belle saison par plein de raisons. Parmi lesquelles il y a, bien sur, la sortie prochaine d’une nouvelle version d’Ubuntu, comme vous pouvez voir dans le petit widget de compte à rebours qui accompagne ces lignes.

Fidèle à son rythme de deux nouvelles versions par an, aux mois d’avril et octobre, Ubuntu 9.04 Jaunty Jackalope sortira le 23 avril 2009.

Comme d’habitude, cette nouvelle version apportera plein de nouveautés. Parmi elles il faut citer le noyau linux 2.6.28, GNOME 2.26, X.Org Server 1.6, l’outil Eucalyptus pour expérimenter avec le cloud computing ou le support au filesystem Ext4, mais aussi des chose plus terre à terre comme le démarrage plus rapide ou le nouveau système de notifications.

Je vous raconterai avec plus de détail ces nouveautés dans un prochain billet.

Mais je veux tester !

Jaunty Jackalope est encore en béta, mais si vous voulez voir déjà à quoi cela va ressembler, vous pouvez toujours aller télécharger la béta de la 9.04 et la tester en mode liveCD ou l’installer dans une partition à part.

Et si vous avez le goût du risque, vous pouvez simplement faire migrer votre Ubuntu 8.10 Intrepid Ibex à 9.04 Jaunty Jackalope. Il suffit de démarrer l’Update Manager (Gestionnaire de mises à jour) en mode développement, depuis la ligne de commandes :

C’est d’ailleurs ce que je compte faire ce weekend si j’ai un peu de temps. Je vous raconterai le résultat…

Quoi de mieux pour me relancer dans les actualisations du blog que commencer par l’un de mes sujets fétiches : les illusions d’optique et plus concrètement, les anamorphoses.

Je vous ai déjà parlé de Julian Beever et des ses superbes anamorphoses sur le trottoir.

Aujourd’hui, en me baladant sur le net, je suis tombé sur son site et j’y ai passé une bonne partie de ma soirée. Je n’ai donc pas pu résister la tentation de vous montrer certains de mes favoris.

L’effet est formidablement réussi, comme d’habitude lorsqu’on parle des maîtres de cette technique, mais pour se rendre vraiment compte de la complexité de ces trompe-l’oeil, le meilleur moyen reste de le voir depuis un angle différent.

Prenons par exemple cette anamorphose de Beever pour une campagne de lutte contre la faim lors du sommet du G8 à Edinburgh :

et voyons ce que ça donne si on la regarde du côté :

Ou quoi dire de celui-ci, qui ajoute à la perfection technique une bonne dose d’humour et une touche geek :

Bref, comme je vous conseille toujours dans ces billets, allez faire un tour sur son site et vous ne serez pas déçus.

Les photos de ce billet sont propriété de Mr. Beever (pas de licence Creative Commons pour elles donc), et si il me demande de les enlever je le ferai dans le plus bref délai.

J’ai emprunté le terme Code Rouge à Maître Eolas, sauf que dans mon cas la classification serait plutôt :

• Code Rouge :Il reste quelques jours avant la mise en prod, il y a encore beaucoup de travail à faire, les journées deviennent extrêmement longues et intenses et le soir la seule activité permise est regarder la télé pour se vider la tête.

Et demain ça risque de devenir Code Noir…

En septembre dernier j’ai commencé à préparer la certification SCJP (Sun Certified Java Programmer), avec l’idée de qu’elle soit une première étape dans la chaîne des certifications Sun, suivie par d’autres certifications jusqu’à éventuellement culminer dans la SCEA (Sun Certified Enterprise Architect).

Après avoir passé la certification SCJP en novembre, je m’étais donc engagé dans la phase suivante, la préparation de la SCWCD (Sun Certified Web Component Developer).

Mon manque de temps de ces derniers mois, et le conséquent ralentissement du blog, ont fait que je n’ai pas parlé de la préparation de cette certification comme j’avais fait avec la précédente.

J’ai donc passé l’examen mardi dernier, à Rennes cette fois, et je l’ai obtenu ma certification SCWCD avec 84% de bonnes réponses.

Comme pour la dernière fois, les derniers jours de préparation ont été assez intenses, sauf qu’à différence de la dernière fois, je n’ai pas pu encore trop me reposer, car j’ai une semaine assez chargé au travail. Vivement le week-end !

Avant de finir le billet, je tiens à féliciter mon collègue Raphaël, qui a aussi obtenu sa SCWCD avec un très remarquable score de 97% !