Ours & Hippy — le blog

L'infirme, ou la joute poétique

2010-03-12T13:44:09+01:00

Récemment, on m’a demandé de composer quelques vers pour le Post’IT, le journal de l’école. Et puisque je me suis remis à écrire un peu, je me permets de poster ici un vieux billet, vieux d’octobre dernier !

En octobre dernier donc, dans le sombre hall de l’Ensimag, près de l’endroit qui sent le paté… On me fit remarquer, là, dans un coin, accroché sur le panneau réservé aux associations, un poème. Et quel poème ! « L’amoureux ! » Il fallait réagir ! Ramener à ce micro-monde la Vérité !

Et le lendemain, ce fut chose faite ; encore aujourd’hui, vous pouvez trouver, accroché près de ces vers, les miens, signés de ma vraie fausse signature. Pour ceux qui ne peuvent malheureusement se déplacer, voici tout de même, en guise de consolation, mon œuvre ! :-°

L’infirme
Je suis l’amoureux !
Là, ne vois-tu pas, dans mes yeux ?
Cette larme de mots, invisible,
Demandant à mouiller ton reflet ?
Et là, les chants muets !
N’agonisent-ils pas, à mes lèvres
    suspendus,
Guettant une illusion de ta gorge
    dévêtue ?
Ne suis-je pas l’amoureux ?
Au fond de mon lit, malheureux,
Bercé de désirs impossibles.
Dérivant de fantasme impuni
En crime inassouvi,
Ne devines-tu pas où l’esprit vagabonde,
Égaré par ses propres passions infécondes ?
Suis-je l’amoureux ?
L’aube m’est venue, le cœur creux.
Ma plume est sèche,
Mes pages défigurées ;
J’y parle d’amours éthérées.
Ton image,
    ce doux spectre, toujours me poursuit ;
Mais déjà,
    mon regard se confond dans l’ennui.
Pourrais-je être l’amoureux ?
Tu le sais ! Dis moi ! Je le peux.
Ta chair est fraîche,
Et ma nature invincible.
Je sais que les voix inaudibles
Souffleront à mes sens, quand enfin viendra l’heure,
De m’en faire à nouveau le gardien, le voleur.

Matin de projet

2010-01-13T10:30:13+01:00

Accroupie au bord du chemin, cigarette à la main. Derrière mes vitres, à l’abri, j’esquisse du regard une silhouette solitaire, seule nuance jusqu’à l’horizon blanc, aventureuse, bravant les humeurs inhospitalières d’un âpre matin, féminine. Détournant son regard, parfois, par-ci, par-là, elle ne me voit pas. A-t-elle froid ? Sans doute… Réflexion banale. Je n’y pense plus, déjà.

Une petite voix m’interrompt ; mon corps pivote machinalement. Assise au bout de la table, la demoiselle me sourit. Son discours m’échappe. Je ne l’ai pas écouté. Mais, obéissant à ses demandes inaudibles, je m’approche sans rien dire, et, laissant mes doigts glisser sur quelques feuilles égarées, brise le silence qui seul m’ensorcelle.
« Tu travailles… sur quoi, déjà ? »
Un regard gentiment accusateur m’interroge. J’ai oublié… Mais qui donc pourrait m’en vouloir, quand l’attrait de la tâche ne tient qu’à la récompense ; celle-là qui, derrière le labeur, se cache et se moque ?

Les explications ne se font pas attendre. Scrutant au hasard l’écran qui nous fait face, j’ingurgite, résigné, les données qui m’assaillent. Telle ligne semble fautive. Tel symbole joue le disparu, tel autre est l’accusé. La petite charade informatique devant nous se découvre, et ses charmes d’antan qui m’avaient séduit, enfant, sous sa robe ne sont plus que perverses allusions et traîtreuses paroles.

J’agite le curseur, change de fichier, reviens sur mes pas. Je prends la pose, fronce à peine les sourcils, me donne un air sévère. Je fais signe, légèrement : que l’on ne me dérange pas. Je pense. Chassé par quelque espoir que je vienne en justicier rétablir le tort fait à l’homme par la machine, sa suivante, je m’enfuis dans ma parade.

Mais l’expérience bientôt vient me sauver. Quand même l’esprit vagabonde par-delà ces murs, les yeux, par les ans entraînés, encore me guident. Sans seigneur pour les soumettre, les doigts, désunis, déjà prennent d’assaut le terrain étranger : ce clavier fort commun sur lequel, pour autant, je ne sais pianoter.

La porte s’ouvre. J’ai terminé. Profitant de la diversion, je rejoins ma place, près de la fenêtre. Je jette un coup d’œil, avant de lui tourner le dos. La rue déserte et immobile me dévisage ; je lui interdis.

Arthur, qui a refermé la porte derrière lui, s’est installé à un mètre de moi. Les diligents muscles de son visage, qui me semblent prêts à tout instant à renfrogner sur commande, témoignent assez de son humeur. Il n’y a rien à discuter. Je me tais. Je fais certainement mieux de compter les minutes qui nous séparent de la pause déjeuner. Quatorze… Treize… Douze… Je la devine déjà : cette longue journée…

Premiers pas vers un environnement de test NetBSD/Xen

2009-12-20T15:50:01+01:00

Loin des préoccupations über-théoriques de bluestorm, ces temps-ci, moi, j’ai essayé de bosser un peu, pour la Junior Entreprise locale. Autant dire que ça ne se passe pas tellement bien : on manque de main d’œuvre compétente et sérieuse, et honnêtement, ça m’irrite au plus haut point que le client soit perpétuellement déçu de notre travail ; c’est comme si je faisais du mauvais travail, mais franchement, si je savais que je me taperais autant de glands à gérer et autant de boulot pour lequel je n’ai pas signé, je n’aurais jamais accepté ce job. Bref, paraît qu’il y a des années avec et des années sans, bah là c’est clairement une année sans.

Tout ceci me mène à une petite anecdote : au cours de mon travail, je suis amené à tester le produit que je développe (la nature duquel est un secret…) dans une perspective de déploiement sur serveur. Récemment, je me suis heurté à des bugs que je n’arrive pas à reproduire sur ma machine de développement, pour une raison ou pour une autre (je n’ai pas encore réglé le souci), qui semble être liée au déploiement lui-même, du moins la configuration employée. Du coup, pour bien faire, je me suis dit que j’allais monter un petit serveur de test… un petit serveur virtuel !

Et ça tombe bien, j’ai toujours trouvé que Xen, ça avait l’air sympa ! Et en plus, chez NetBSD, on semble accorder une certaine importance au support Xen, ce qui est plutôt cool. Je me suis donc mis en tête de configurer un joli petit environnement NetBSD+Xen, le but étant d’avoir un serveur virtuel tournant sur une NetBSD vanilla, avec le minimum de paquetages nécessaires au déploiement de mon application. Bref, un truc propre.^α

α : Le véritable serveur tourne sous Linux, mais pour du test rapide, il est beaucoup plus simple pour moi de virtualiser du NetBSD ; j’écrirai peut-être un autre billet, si je me fais un test Linux+Xen.

Xen pour les innocents

Pour me la jouer à la blueblue, je vais dire deux mots pour ceux qui ne connaîtraient pas le principe. Ahem, donc pour ceux qui ne connaîtraient pas, Xen est une solution de virtualisation,^β comme VirtualBox… mais pas tellement en fait.

β : … principalement destinée aux serveurs, mais hey !

Avec VirtualBox, vous avez votre système normal et par-dessus, un petit logiciel qui fait tourner en son sein un autre système d’exploitation.

Xen est un peu différent. Vous ne pouvez pas simplement lancer Xen depuis votre système préféré, comme vous lanceriez un programme quelconque… c’est en fait plutôt l’inverse : Xen est une espèce de méta-système (un hyperviseur) qui va se charger de lancer vos systèmes d’exploitation un à un ! Si donc avant vous aviez, disons une Ubuntu avec une NetBSD dans votre VirtualBox, vous auriez maintenant l’hyperviseur Xen, et deux domaines (c’est comme ça que ça s’appelle dans Xen) : votre Ubuntu, et votre NetBSD.^γ

γ : Pour tout vous dire, ce n’est probablement pas le meilleur choix… Ubuntu ne semble pas intégrer, dans sa ligne de développement centrale le support de Xen. Voyez la documentation communautaire d'Ubuntu sur Xen pour plus de détails.

Tous les domaines ne sont pas égaux pour autant : il y a toujours un système principal, appelé dom0 (domaine 0) ; les autres sont les domaines U (domU). Le dom0, c’est un peu le root de tous vos domaines : il a tous les pouvoirs, tandis que les autres ont des droits restreints, notamment concernant l’accès au réseau et au matériel. Au démarrage, Xen lance le dom0, qui a à sa charge de créer les domU qu’il désire (ou plutôt d’ordonner à Xen de les créer). Dans notre exemple, Ubuntu est le dom0, et NetBSD, le seul domU.

La dernière chose à savoir est que pour pouvoir être géré par Xen, il faut que le noyau soit conçu pour dialoguer avec l’hyperviseur, qui fait office d’abstraction entre la machine et le système. Il y a des noyaux dom0 et des noyaux domU. NetBSD propose dans sa distribution officielle des noyaux dom0 et domU ; sous Gentoo, compiler un noyau Xen est juste une histoire de changer de paquetage sources ; je ne sais pas trop ce qu’il en est des autres distributions Linux…

Bref, si vous ne connaissiez pas Xen, voilà qui est réglé. Il est temps de passer aux choses sérieuses…

Notes d’installation

Peut-être parce que c’est destiné à des mecs un peu underground, des sysadmins et tout, il n’y a pas beaucoup de tutos sur Xen… du moins, il y en a, mais beaucoup ne sont plus à jour et offrent des informations périmées. Notamment, le howto officiel de NetBSD/xen est, en l’état, incorrect.^δ C’est fort dommage car mettre en place un environnement Xen avec NetBSD est en réalité très simple… pour peu que l’on sache comment s’y prendre.

J’offre ici mes humbles notes d’installation. Sait-on jamais, peut-être mon expérience servira-t-elle à quelqu’un.

δ : Si je mets la main sur ces permissions de commit un jour, je devrais ptet y faire quelque chose… Normalement, je fais signer ma clef GPG ce lundi !

Si NetBSD est livré avec tout ce qu’il faut pour le faire tourner comme domaine Xen, Xen lui-même (l’hyperviseur et les outils pour le contrôler depuis le dom0) est à installer via pkgsrc. Il y a un jeu de paquetages par version majeure de Xen. Dans mon cas, j’ai pris la 3 :
```
# cd /usr/pkgsrc/xenkernel3 && make install
# cd /usr/pkgsrc/xentools3 && make install
```
Le noyau Xen s’installe très logiquement dans la hiérarchie /usr/pkg. À l’heure où j’écris ces lignes, le fichier en question est /usr/pkg/xen3-kernel/xen.gz.
On aura aussi besoin de scripts de démarrage pour les démons Xen xend et xenbackendd. J’ai simplement recopié ceux fournis à l’endroit habituel :
```
# ln -s /usr/pkg/share/examples/rc.d/xend /etc/rc.d/
# ln -s /usr/pkg/share/examples/rc.d/xenbackendd /etc/rc.d/
```
Pour l’instant, ces démons ne font rien ; ils ne peuvent même être lancés (mais on peut déjà les ajouter dans le rc.conf, histoire de ne pas oublier). Il nous manque un dom0…
Concernant le dom0, la bonne nouvelle, c’est que seul le noyau a besoin d’être modifié : juste en changeant de noyau au démarrage, on peut décider d’utiliser Xen ou pas, tout ça avec le même jeu de programmes, les mêmes disques et systèmes de fichiers, etc.
Pour se faire un noyau dom0, rien de plus simple : un noyau dom0 est fourni avec NetBSD (XEN3_DOM0) ; en partant de sa configuration, j’ai simplement modifié le fichier à ma convenance (comme j’ai fait pour le noyau GENERIC, pour obtenir ma configuration non Xen), puis config et make ont fait le reste, comme d’habitude :
```
# cd /usr/src/sys/arch/conf/
# cp XEN3_DOM0 ELHAYM_DOM0
# emacs ELHAYM_DOM0
# config ELHAYM_DOM0
# cd ../compile/ELHAYM_DOM0
# make depend && make
# cp netbsd /netbsd-dom0
```
Pour avoir testé, il est sensiblement plus difficile de partir de la configuraiton personnalisée (dérivée de GENERIC) pour la rendre compatible avec Xen, que de partir de la configuration Xen pour l’adapter à la machine…
Quelques défauts remarquables du noyau compatible Xen par rapport à un noyau NetBSD normal :
- pas de SMP ;
- pas de changement de fréquence SpeedStep du processeur (corrigé dans NetBSD-current, il me semble) ;
- l’ACPI a quelques soucis chez moi (le poweroff ne fonctionne pas et la machine s’arrête simplement, sans s’éteindre)…
Une fois le nouveau noyau fraîchement compilé, il suffit d’ajouter la ligne correspondante dans le boot.cfg. Autrefois, il fallait passer par Grub, à la place du bootloader NetBSD ; ce n’est plus le cas aujourd’hui, et tant mieux ! Les manips sont d’autant plus simple.
À noter que la ligne à ajouter ne lance pas le nouveau noyau directement ; elle doit lancer l’hyperviseur, en lui indiquant le chemin du dom0. Quelque chose comme ceci (dans boot.cfg, il faut placer les instructions sur une seule ligne en les séparant par des points-virgules, bien sûr) :
```
load /netbsd-dom0 console=pc
multiboot /usr/pkg/xen3-kernel/xen.gz dom0_mem=max:1536M
```
Limiter la mémoire pouvant être allouée au dom0 permet d’être sûr de pouvoir créer les domU quand on en a besoin. Je n’ai pas trouvé d’autre moyen de réduire la mémoire consommée par un domaine.
Vient ensuite le domU, la configuration duquel est contrôlée par un fichier, que j’ai, pour ma part, simplement emprunté aux exemples fournis avec le paquetage :
```
# cp /usr/pkg/share/examples/xen/netbsd1 /usr/pkg/etc/xen/test
```
Le fichier est commenté, et c’est plutôt explicite. Cependant, quand on débute dans ce vaste monde, comme moi, ce n’est pas forcément évident pour autant…
1. Tout d’abord, ça paraît stupide, mais domU, au départ, correspond à une machine vierge, sans système d’exploitation. Cela ne sert donc pas à grand chose de charger un noyau domU (par exemple le noyau XEN3_DOMU standard de NetBSD) vu qu’il ne trouvera rien sur le disque… Il faut en fait charger un noyau d’installation (INSTALL_XEN3_DOMU), qui contient un ramdisk avec sysinst.
```
#kernel = '/netbsd-domu'
kernel = '/netbsd-install-domu'
```
2. La seconde variable d’intérêt s’appelle disk. Elle décrit les disques virtuels disponibles à l’intérieur du domU. Créer un disque virtuel vivant dans un fichier est le plus simple :
```
vif = ['file:/var/xen/images/test.img,0x01,w']
```
  Pour l’installation du domU (avec le noyau d’installation), il ne faut pas non plus oublier de configurer le disque virtuel correspondant au CD-ROM contenant les sets d’installation NetBSD (les gros fichiers .tgz contenant l’userland précompilé) :
```
vif = ['file:/var/xen/images/test.img,0x01,w',
       'file:/var/xen/images/install.iso,0x02,r']
```
  L’ISO se télécharge simplement sur un miroir NetBSD, dans le dossier iso/ (séparé des autres dossiers de fichiers d’installation).
  Ces disques apparaîtront dans le domU NetBSD sous la forme de périphériques xbd (le premier étant xbd0, le second xbd1, etc.). D’autres systèmes interprètent cela différemment.^ε
  ε : Sous Linux, le second paramètre de la description du disque virtuel spécifie le périphérique à créer dans le domU.
  Le seul point délicat sur lequel je suis tombé est que pour utiliser un fichier en guise de disque virtuel (file:), il faut absolument que ce fichier ne soit pas creux (sparse), sans quoi vnd(4), le périphérique virtuel permettant de monter un fichier comme un disque, est incapable de fonctionner correctement.
  En pratique, cela signifie utiliser dd count=N plutôt que dd seek=N pour créer le fichier.
3. Enfin, la configuration du réseau mérite un point à elle toute seule. Le principe est que Xen expose deux interfaces réseau (type Ethernet) connectées : une du côté domU (qui s’appelle xennet sous NetBSD) et une du côté dom0 (xvif sous NetBSD).
  Ce qui est fait de ces interfaces est laissé libre à l’administrateur, et est typiquement contrôlé par des scripts. Il y a deux scripts fournis avec le paquetage, vif-bridge et vif-ip, permettant respectivement d’obtenir un pont (bridge(4)) ou une simple IP statique privée associée au domU.^ζ
  Pour ma part, j’ai choisi la seconde solution, car elle me convient mieux. Je n’ai pas besoin d’accéder à Internet depuis mon domU, et si cela devait se présenter, je pense que j’essaierai de mettre en place de la redirection, et du NAT. Pour utiliser par défaut vif-ip, il suffit de modifier le fichier de configuration de xend (/usr/pkg/etc/xen/xend-config.sxp, syntaxe s-exp, d’où le nom) :
```
(vif-script vif-ip)
```
  Avec une telle configuration, la ligne de configuration du vif ressemble à :
```
vif = ['ip=192.168.127.2 netmask 255.255.255.0']
```
  La valeur du sous-paramètre ip est simplement passée à ifconfig(8) pour configurer l’interface xvif (côté dom0). Le script ajoute automatiquement le sous-réseau mentionné (ici 192.168.127/24) dans la table de routage afin de diriger le trafic en direction de celui-ci à travers la bonne interface xvif. Cela signifie, en bref, qu’il suffit de donner une adresse IP appartenant au même sous-réseau à l’interface xennet, du côté du domU, et tout marche comme si les deux domaines étaient sur un même réseau !
  ζ : Le script proposé dans le howto NetBSD/xen est périmé. Celui fourni avec le paquetage semble très bien marcher.
Une fois le fichier de configuration écrit, il suffit de faire appel à xm create, et tak.
L’installation se passe comme une installation classique, par CD-ROM (à part que le périphérique CD est ici xbd1). Une fois terminée, il suffit de changer de noyau (dans le fichier de configuration du domU), et hop ! Une fois les briques de base en place, on peut passer à l’installation des paquetages que l’on veut.
Pour ça, j’ai utilisé la solution cheap : un chroot(8) dans le vnd(4), en réutilisant les paquetages précompilés par pkgsrc pour ma NetBSD principale (avec un petit mount_union(8)).
```
# vnconfig vnd0 /var/xen/images/test.img
# mount /dev/vnd0a /mnt/
# mkdir /mnt/usr/pkgsrc/
# mount -t union -o -b /usr/pkgsrc/ /mnt/usr/pkgsrc/
# chroot /mnt/ /bin/sh
# export PKG_PATH=/usr/pkgsrc/packages/All/
# pkg_add ...
```
Et voilà ! Un joli environnement de test. :)

Impressions

Avec tout ça, j’ai un truc qui tourne. Je peux même tout simplement copier le disque en l’état, pour produire des environnements de test en masse.

Ceci dit, même si je considère Xen comme une technologie « cool », tout n’est pas rose. Au-delà des défauts que possède la version dom0 de NetBSD (principalement l’absence de SMP), j’ai eu du mal à trouver de la doc pertinente, et c’est un gros problème pour l’adoption de Xen par un public moins gurutique, à mon avis.

Cela mis à part, comme dit plus haut, je trouve, à titre personnel, que Xen avec NetBSD, c’est plutôt facile à mettre en place une fois que l’on a compris le truc ; et même si la doc comporte quelques erreurs, à l’heure actuelle, cela donne une bonne base sur laquelle partir.

Je ne sais pas ce qu’il en est des distributions Linux. J’entends souvent les gens opposer KVM à Xen. Je ne connais pas KVM donc je ne saurais pas trop dire ce qu’il en est. Mais du coup, il semblerait que l’adoption de Xen dans le monde Linux soit moindre… dommage ? Je ne saurais pas dire.

L'Ensimag pour les véritables

2009-08-14T15:03:13+02:00

Pas plus tard qu’hier, quelqu’un m’a posé la question : mais quel est donc le programme de l’Ensimag, côté info, en première année ? C’est vrai qu’à lire les sources officielles vagues et pompeuses (dont je ne donnerai pas l’URL tellement elle est imbittable ; par contre vous pouvez aller jeter un œil à la page d'EnsiZéro concernant le programme, qui n’est ma foi pas mal faite), on n’a guère idée de ce qui nous attend, et je me rappelle m’être demandé également, avant d’intégrer. Du coup, entre un récap xmltools et un futur article-touchette signé bluestorm, j’ai décidé de mettre à jour ma catégorie Ensimag — en sommeil depuis plus d’un mois — avec un article de choc : l’Ensimag pour les véritables.

Imaginez : vous allez entrer à l’Ensimag, et vous êtes un véritable — bon, disons un apprenti-véritable, ou même juste un troll puant, en fait, mais disons que vous avez une idée de ce que peut être l’informatique ou la programmation, ptet pas la bonne idée, mais une idée. Il y a certainement des choses que vous aimeriez savoir, pour mieux vous préparer (psychologiquement) à ce qui vous guette. Vous n’avez besoin de savoir que ce qui compte, ouais, stuff that matters (parce que vous êtes in, parlez le franglais, et lisez /.), des choses comme le nom du système d’hérétiques que l’on vous forcera à utiliser, ou du langage de pouilleux que l’on vous imposera sans merci et qui sans nul doute fera ressentir à votre esprit d’athlète toute la désespératitude de devoir s’exprimer dans ce corps infirme (mais qu’il saura, je suis sûr, évacuer, selon le cas, dans l’alcool, la drogue, la déprim ou l’aigrissement).

Tout d’abord, rassurez-vous, on ne vous enseignera probablement rien qui pourrait venir profondément bouleverser votre conception de la vie et de l’univers. Il faudra cependant accepter que tout le monde ne partage pas (ou plutôt que pas grand monde ne partage) votre spécialité, vos intérêts ou vos convictions, non seulement parmi vos Petits Camarades mais également vos profs, ces gentilles dames et ces gentils messieurs qui auront à leur charge de vous apprendre de gentilles choses.

Une fois ceci bien digéré, la vérité est… que vous allez faire de l’Ada sur des thin clients relié à un serveur Linux (Red Hat) quasiment toute l’année, avec trois semaines de C pour clore la danse en guise de projet de fin. Entre temps, vous vous serez arraché les cheveux sur Scilab (c’est statistique), aurez découvert (ou redécouvert) le VHDL (si vous choisissez Archi2 au second semestre), vaguement touché de l’ASM x86 (Logiciel de base), et aperçu de loin du Prolog (si vous prenez Logique au second semestre).

Vous n’aurez ni programmation objet (mais pas de réjouissances hâtives, on en mange en 2A), ni programmation fonctionnelle (bouh). On vous épargnera même tout le B^Hplaisir de faire de la modélisation avec UML, Merise et leurs amis.

Le reste des matières est constitué de maths, de culture générale informatique (dans le genre de « comment se servir d’un shell » ou « SSH et ses copains crypto-gentils »), et de sciences sociales et humaines (et malgré le nom, ce n’est pas incompatible avec la nolife-attitude).

Voilà donc un tour d’horizon de ce qui sommeille de ce côté-ci de la planète Ensimag ; au-delà, il vous faudra trouver d’autres sources que mon humble blog.

Le Wifi du CROUS : guide de survie

2009-07-14T13:15:05+02:00

Arrivé sur Grenoble, j’étais tout content de découvrir que le CROUS m’offrait gratuitement l’accès à Internet par le biais de Renater et d’installations Wifi. J’ai vite déchanté en voyant la qualité de la connexion. Autant le débit est tout à fait acceptable pour une connexion partagée (il va de soi qu’en téléchargement montant vous n’avez rien ou presque, ceci dit), autant la stabilité de la connexion laisse tout à fait à désirer.

Ce petit guide sans prétention vous fait part de mon expérience avec ce réseau capricieux ainsi que mes petites astuces sur comment y survivre malgré tout.

Cet article ne s’adresse évidemment pas aux gens qui utilisent Windows, n’ayant pas Windows moi-même, sur mon portable, je ne saurais les conseiller.

Avant d’entrer dans le vif du sujet

Je tiens à préciser que ceci n’est pas un guide de configuration (mais plutôt de dépannage), parce que j’estime qu’il y en a déjà suffisamment sur la Toile, mais surtout parce que j’ai la flemme !

Afin de vous donner quelques pistes de recherche, toutefois, voici les programmes dont vous aurez besoin pour faire tourner la machine. Mieux vaut les avoir préparés avant d’atterrir sur le campus !

Un noyau qui supporte votre carte Wifi, c’est bête mais…
wpa_supplicant, pour établir la connexion avec les points d’accès du CROUS. En vérité, celle-ci s’opère sans authentification (déléguée au VPN), mais wpa_supplicant, malgré son nom, gère également les réseaux en WEP, ou sans sécurité aucune. Entre autres, il permet de gérer plusieurs réseaux alternatifs, ce qui permet de faire cohabiter votre réseau à la maison familiale, pour quand vous rentrez chez vous, avec celui de votre école (p.ex. l’Ensimag a son propre réseau), et celui du CROUS, par exemple.
Vous pourriez être tenté d’utiliser quelque chose comme NetworkManager. Si tel est le cas, sachez que ce guide ne vous sera pas d’une grande utilité, car ce logiciel a tendance à masquer toutes les manipulations que je présente ici, et je ne saurais dire si les commandes que je donne auront les effets escomptés en présence de NetworkManager.
dhclient (ou un autre client DHCP), sans quoi vous aurez une connexion sans avoir d’IP…
vpnc, le client libre compatible avec les réseaux VPN de Cisco. Le client officiel, sous licence propriétaire, est à la fois instable et indisponible sous BSD.
OpenSSH, si vous souhaitez utiliser des tunnels (et si vous avez un serveur pour les héberger, celui de votre école peut faire l’affaire). Si votre utilisation d’Internet ne se limite pas au Web, vous en aurez sans doute besoin.

Le VPN (Very Private Network)

Il y a beaucoup de gens qui appréhendent l’usage de cette chose qu’est le VPN, alors qu’en vérité, les problèmes commencent après. L’usage du VPN est simple, il suffit de suivre les divers guides (disponibles pour Linux et Unix !) mis à votre disposition, ou de demander à quelqu’un du service informatique de votre école. Ou encore, plus simplement, il vous suffit d’installer vpnc (p.ex. via le gestionnaire de paquets de votre distribution Linux), et de récupérer les paramètres du réseau VPN, voire un fichier de configuration déjà fait (ne pas oublier de le convertir, s’il est au format Cisco VPN, avec pcf2vpnc).

La seule chose à laquelle il faut faire attention est, si vous utilisez un noyau compilé par vos soin : il faut activer le support du tunnel générique (TUN/TAP).

Limitations explicites du réseau

Officiellement, vous êtes encouragé à vous limiter à des activités purement scolaires au sein du réseau ; certains manuels sont plus indulgents et parlent de trafic personnel raisonnable. Il va de soi que je ne vous conseille pas de faire de gros téléchargements depuis le réseau du campus ; ce serait une perte de temps pour vous et un dérangement pour les autres.

Cependant, la tentative de contrôle imposée par l’administration du réseau, consistant à bloquer certains ports en sortie, peut être très gênante pour un nombre de choses utiles, notamment vous connecter en SSH à votre serveur à votre domicile familial, par exemple pour faire une sauvegarde de vos données importantes (on n’est jamais trop prudent). Le FTP ne marche d’ailleurs pas mieux.

13 juin 2009. Depuis quelques jours, j’ai remarqué que le port CVS est ouvert en sortie ; il est donc possible, par exemple, de mettre à jour son arbre de ports ou sa dernière version d’Emacs… Cela paraît d’autant plus aberrant que le port FTP est demeuré fermé.

Sessions et tunnels SSH

Si votre école vous offre un environnement moins restrictif (et c’est mon cas, avec l’Ensimag),^α vous pouvez vous connecter en SSH là-bas pour ensuite faire vos petites manipulations. Ou vous pouvez créer un tunnel SSH. Si vous ne connaissez pas, il s’agit de l’option -L de la ligne de commande ou LocalForward du fichier de configuration.

Par exemple :

$ ssh -L 2806:chez.moi:22 telesun

α : 20 février 2010. Depuis fin janvier, l’Ensimag filtre également agressivement sur les ports en sortie. Entre autre, on ne peut plus utiliser ni FTP, ni CVS, ce qui s’avère très gênant pour la mise à jour de ma NetBSD… m’enfin, on se débrouille toujours.

`sshd` sur un autre port

Si vous avez un peu de contrôle sur votre réseau à votre domicile et que le port 80 n’est utilisé par rien d’autre, simplement faire écouter sshd sur celui-ci marche bien et le réseau du campus ne bronche pas quand vous parlez SSH sur le canal normalement réservé au HTTP.

Vous pouvez également utiliser le port 443, celui d’HTTPS, qui est également ouvert, sur le réseau du campus, si cela vous convient mieux. C’est ce que je fais.

Améliorations : clés SSH et `ssh-agent`

Honnêtement, si vous prévoyez d’utiliser massivement SSH, pour rediriger votre trafic sur une machine qui vous permet d’accéder à des services indirectement, je vous conseille vivement de vous créer une paire de clés publique/privée et un compte dédié sur votre serveur, acceptant ces clés, dénué de tout droit et servant uniquement à la mise en place du tunnel.

Une alternative, si l’idée d’un tel compte vous semble inacceptable, est d’utiliser ssh-agent, pour n’avoir à taper votre passphrase qu’une seule fois.

Vous pouvez même pousser le vice plus loin en ajoutant le module d’authentification PAM pam_ssh à la configuration de votre gestionnaire de connexion (si bien sûr il utilise PAM). Il s’agit d’inclure une ligne de ce genre au début du fichier du service PAM concerné :

auth	sufficient	pam_ssh.so	no_warn try_first_pass

pam_ssh vous permet de taper votre passphrase en guise de mot de passe de connexion et se charge de lancer ssh-agent pour vous. Que demander de plus ?

Problèmes avec le Wifi

Des problèmes avec le Wifi, j’en ai rencontré un certain nombre : les deux plus agaçants étant, en grand numéro 1, les fréquentes déconnexions, suivi, de très loin par le débit qui décroît parfois assez violemment.

Régulièrement, le VPN ou le Wifi, ou les deux, va périr. Pour diagnostiquer la panne, plusieurs méthodes. Aucune n’est 100% fiable, mais elles donnent toutes des informations utiles, selon le cas.

Le premier réflexe est de regarder la liste des processus. Si certains manquent, vous savez d’où vient le problème…
Un autre moyen de dépister le problème (dans le cas du Wifi, ça ne marche évidemment pas pour le VPN), et qui est peut-être meilleur (entendez par là qu’il s’agit peut-être du problème le plus courant), est d’utiliser wpa_cli status. Regardez par exemple la ligne wpa_state.
Si cela ne résout pas le problème, la netstat -r peut vous aider à y voir plus clair : ils permettent d’identifier les chemins (littéralement « itinéraires », routes en anglais) empruntés par les paquets du réseau.
En temps normal, vous devriez voir une interface tun (le tunnel VPN) et une interface correspondant à votre carte Wifi (p.ex. wlan sous Linux, ou wpi pour ma carte Intel sous NetBSD).
En cas de problème, certains chemins au réseau peuvent disparaître. Si l’interface tun n’est plus présente, c’est vpnc qui est mort. Si c’est l’interface de votre carte Wifi, c’est le Wifi qui est en cause.
Un autre problème assez courant est que certains chemins demeurent alors même que la connexion est morte ou a changé. Les symptômes sont typiquement : vous êtes connecté et wpa_cli status vous retourne des informations crédibles mais vous ne pouvez accéder à aucun autre hôte du réseau, même pas votre passerelle ou vos serveurs DNS. Dans ce cas, il faut supprimer les chemins erronés avec route del (Linux) ou route delete (NetBSD) (généralement la passerelle par défaut, default, suffit) et rétablir la connexion.
Enfin, un simple ping sur TCP (ICMP est bloqué, vous pouvez utiliser par exemple echoping) peut également vous être utile pour apprécier l’état général de la connexion.

Solutions

Si c’est vpnc, il suffit de le relancer, en revanche, si c’est le Wifi (et il m’a fallu pas mal de temps pour m’en rendre compte), c’est probablement que vous avez été déconnecté et qu’en même temps, votre liste de points d’accès s’est vidée ! La solution ? Rescanner la liste des points d’accès, avec par exemple :

# wpa_cli scan

Quelques fois, wpa_cli status vous indiquera un état valide (ASSOCIATED) mais vous n’aurez aucune IP attribuée : relancer le client DHCP peut être nécessaire. La plupart du temps, il s’agit de dhclient, mais selon le système, cette démarche peut être couplée avec le redémarrage du service réseau tout entier : par exemple, /etc/init.d/net.wlan0 restart sous Gentoo mais simplement /etc/rc.d/dhclient restart sous NetBSD.

Quant au problème de débit misérable, si iwconfig (sous Linux) ou autre wlanctl (sous NetBSD) vous indique un [Bit] rate minable, vous pouvez sans doute y remédier avec un wpa_client reassociate.

Automatiser le processus

Toute cette surveillance est fastidieuse et l’on est vite tenté de vouloir l’automatiser. Cela peut se faire par exemple avec un script tournant en fond qui échantillonne périodiquement l’état de la connexion et tente de remédier aux problèmes.

Ce n’est pas une tâche aisée, cependant, car le diagnostic peut être délicat. Un petit script peut toutefois du moins vous épargner de retaper les trois ou quatre commandes servant à relancer l’ensemble des services nécessaires.

Je vous mets à disposition mes deux petits scripts pour NetBSD, qui sont très loin d’être parfaits (je me retrouve de temps en temps à devoir faire sudo do_wifi all à la main), mais qui peuvent servir de point de départ ou de source d’inspiration pour élaborer les vôtres. :)

do_wifi: Le script principal.
do_sshtunnel: Trois lignes de shell qui démarrent mon tunnel SSH.

Fin

Bah voilà, c’est fini et c’est la vie, mais avec ça et un peu de documentation, vous devriez avoir une connexion Internet correcte sur le campus, si ce n’était pas déjà fait, mais cette fois, aux frais du CROUS.

Ensimag, histoires d'intégration : la plaquette alpha

2009-06-27T22:47:03+02:00

Bon, c’est l’été, les oraux (des concours d’entrée aux Grandes Écoles, bien sûr), et bientôt la préparation à l’intégration de l’année prochaine, pour ceux qui intégreront. Les plaquettes des diverses écoles se font concurrence pour impressionner les candidats, dissiper tous les mythes, mettre en avant tous les atouts. Celle de l'Ensimag (remarquez au passage l’URL à rallonge horrible, typique de tous les services Internet qui dépendent de Grenoble INP) ne fait pas exception.

Dans la lignée de mes billets passe-temps sans grande utilité, je vous présente donc une petite critique (gentille) de la plaquette alpha (basée sur la version en ligne) ! Commençons…

Graphiquement, la qualité du PDF est sincèrement à vomir ; les bitmaps passent très mal et ne sont visiblement même pas à la résolution par défaut du document. D’un autre côté, la police d’écriture n’est pas désagréable, et la typographie pas trop mal respectée… seulement, soit il y a eu un problème technique, soit les relecteurs étaient aveugles, soit les rédacteurs n’apprécient pas correctement le rôle du point d’interrogation dans l’univers typographique français. On appréciera que cette année l’orthographe et la grammaire aient fait partie du package alpha.

Quant au texte, soyons honnêtes, c’est banal ; on saura donner un bon point à la (petite) recherche d’originalité avec l’aspect faux journal relativement réussi. Gros point faible toutefois : il y a clairement trop de paragraphes qui se suivent avec une mise en page monotone et linéaire, sacrifiant (à mon avis) trop la structure et la clarté au profit de l’effet de style journal. Passée la dixième page, j’ai dû faire une pause.

Sur le fond, rien de nouveau sous le soleil. Ce qui est dit est sans doute vrai pour certains, de là à dire pour une majorité, je n’en sais trop rien. Je tiens à préciser que les commentaires tentant de briser le mythe de l’ensimagien geek sont totalement fondés. Des étudiants avec une certaine expérience (n’osons pas parler ici d’intérêt) de l’informatique pratique, il n’y en a pas beaucoup à la rentrée… et guère plus un an après. Au premier jour, celui qui a utilisé un unixoïde ne serait-ce qu’une seule fois dans sa vie est probablement dans la moitié haute, sur l’échelle de l’expérience. (Pas de souci pour les autres, cependant, il y a le stage Unix et plein d’occasions de s’accoutumer.)

On remarquera, avec une certaine déception sans doute pour certains, la présence féminine modérée au niveau des photos, qui offre l’impression d’une école à dominante masculine, ce qui est la stricte vérité. On peut constater que sur la trentaine de photos montrant des élèves de l’école, au moins cinq comportent des filles de manière visible, soit un rapport d’1/6, ce qui n’est pas très éloigné des 14% ou 15% d’effectif féminin recensé à l’école. Même la vignette intitulée de manière évocatrice « Des filles » est agréablement sobre et apparaît comme un simple fragment de vie, avec son charme naturel, distrait… si toutefois on arrive à passer outre le conformisme latent qui prend la forme d’un orange omniprésent (qui était, n’en doutons pas, au moment de la photo, de circonstance) sur lequel un peu de noir est plus que le bienvenu…

En conclusion, quoi que l’on en dise, les prétendants à l’Ensimag ne passeront probablement pas des heures (sans doute même pas une seule) à contempler cette plaquette, encore moins à la disséquer, et elle me semble ainsi, cette année, et malgré quelques détails reprochables, mieux remplir son rôle que sa grande sœur, que j’avais eu entre les mains avant mon arrivée.