lundi 10 décembre 2007

Softs ham-radio

J'ai écrit quelques ebuilds pour des logiciels de radio-amateurisme qui ne sont pas dans portage:

https://xolus.net/~max/hamradio-ebuilds-pack.tar.gz

Contenu:
  • xastir-1.9.2 - X Amateur Station Tracking and Information Reporting
  • fldigi-2.05 - Digital Modem
  • xlog-1.6 - QSO Logger
Xastir permet de recevoir les données APRS (Automatic Position Reporting System), soit directement via un périphérique AX.25, soit via internet, a travers l'un des nombreux ponts publics (swiss.aprs2.net par exemple). Le traffic APRS non filtré représente un volume important. Spécifier un filtre (j'utilise a/53/-4/34/12, pour avoir uniquement la Suisse, la France, une bonne partie de l'Espagne, de l'Allemagne, et l'Italie du nord) permet de restreindre le traffic a un volume acceptable. Les données reçues incluent la position GPS des différentes stations (y compris voitures et autres stations portables), des relevés pour les stations météorologiques. Tout ça gratuitement... fun !


Fldigi est un modem software qui fonctionne avec une carte son ALSA ou OSS. Il permet de faire de l'analyse de fréquences, et module/démodule le morse, différents modes MFSK, BPSK et QPSK, RTTY, Olivia et Throb, entre autres. Pour le morse, j'arrive tout a fait a m'en servir en tenant ma radio devant le micro de mon portable.

Xlog est un logiciel pour tenir un journal de contacts radio. Je ne m'en suis pas encore servi pour l'instant.

lundi 19 novembre 2007

Bouton power sur un PowerMac G4 sous Gentoo

J'ai hérité d'un sympathique petit PowerMac G4, que j'utilise à la maison comme serveur de stockage. Il tourne sous Gentoo Linux PPC.

Dans la configuration par défaut, il y a un petit détail ennuyeux: le bouton Power ne fait rien par défaut. Utilisant mon serveur sans écran ni clavier, je devais me connecter avec SSH depuis mon portable pour l'éteindre, ce qui est peu pratique. Le petit truc suivant m'a permis de configurer le bouton Power pour éteindre la machine proprement:

  1. Un coup de showkeys en root via ssh, et appuyer sur le bouton. Chez moi, showkeys indique que le bouton est reconnu comme touche de clavier standard (keycode 116).
  2. Dumpkeys indique que la touche est reconnue comme touche de clavier "Do":

  3. dumpkeys |grep 116
    keycode 116 = Do

  4. Ajoutons au script de boot (pour gentoo, /etc/conf.d/local.start fait l'affaire) un mapping qui associe le symbole KeyboardSignal à cette touche:

  5. loadkeys - <<< 'keycode 116 = KeyboardSignal'
  6. Configurons init pour intercepter ce KeyboardSignal et éteindre la machine, en ajoutant cette ligne dans /etc/inittab:

  7. ha:12345:kbrequest:/sbin/shutdown -h now

Voila :) Si j'ai le temps, je ferai une version sûre contre les extinctions accidentelles.

jeudi 8 novembre 2007

Screenshot PLT 0xA

Un petit screenshot du nouveau plan de réseau pour PolyLAN 0xA

En direct du local PolyLAN...

La configuration progresse à petits pas... Comme toujours, je perds mon temps en gadgets inutiles (ou pas). Dans la liste des fonctionnalités manquant à PLT, on peut maintenant barrer:
  • Des quittances pour les alertes sur l'état des trunks. Une touche dans le trunk monitor permet d'arrêter le clignotement, l'alarme est supprimée jusqu'a ce que le trunk récupère un état normal.
  • Un script wiring-map.pl permet d'obtenir une vue graphique de la configuration d'un switch donné dans la DB. Le script affiche la disposition des différents trunks et leurs destinations supposées, et les ports utilisateur déclarés.
  • Le code de gestion des traps SNMP a été largement réécrit pour être polymorphique, il est maintenant possible de traiter les traps en fonction du modèle de switch qui les envoie; il n'est plus nécessaie de maintenir de multiples entrées dans snmptrapd.conf, une seule entrée par défaut suffit.
Autrement, les backbones sont complètement configurés, et je vais commencer la configuration des 6 derniers switches 3424 (mise a jour firmware + configuration PolyLAN)

lundi 5 novembre 2007

OIDs de versions sur Dell PowerConnect

SNMPv2-SMI::mib-2.47.1.1.1.1.9.67108992
SNMPv2-SMI::mib-2.47.1.1.1.1.10.67108992
SNMPv2-SMI::mib-2.47.1.1.1.1.8.67108992

Ces OIDs permettent de récupérer les versions du bootcode, du firmware et du matériel des switches Dell PowerConnect. Confirmé sur 3424 et sur 5324.

PLT inclut maintenant un script ./check-versions.pl qui affiche les versions des firmwares des équipements connectés.

vendredi 2 novembre 2007

CaveShooter 0.3

Ca-y-est, CaveShooter a atteint une version utilisable ! on peut se tirer dessus tout en discutant. Après quelques ajustements au gameplay, c'est devenu carrément amusant.

Reste a y intégrer quelques cheat codes... je verrai ça quand j'ai le temps :)

cudoku 0.2 !

Voila une nouvelle version de CuDoKu, mon solveur de sudoku en curses !

  • Il est maintenant possible d'importer et de sauvegarder les grilles
  • Pour les cas ou l'algorithme d'induction-déduction ne suffit pas, le solveur effectue une descente récursive
Pour rappel, cudoku est écrit en Perl pur, et utilise une interface Curses (nécessite le module Curses de perl).

Vous pouvez obtenir la dernière version via mon serveur Mercurial tout neuf:
hg clone https://xolus.net/hg/cudoku


Ou simplement le tarball:
https://xolus.net/~max/cudoku-0.2.tar.gz

lancez simplement avec ./cudoku . La grille démarre vide si le fichier n'existe pas.

Une grille enregistrée est composée de neuf lignes de neuf caractères, pouvant être les chiffres de 1 à 9 pour les valeurs connues, ou 0 si la case est inconnue. Le programme est souple et acceptera des caractères arbitraires entre les chiffres.

N'hésitez pas à y apporter des améliorations et à me soumettre par mail des patches Mercurial:

(hack hack hack...)
hg commit -m 'uber-cool changes'
hg bundle mes-ameliorations.hg https://xolus.net/hg/cudoku
(envoyer mes-ameliorations.hg par mail)

jeudi 1 novembre 2007

Du bon usage de /finally/

Dans le cadre du cours de réseaux informatiques, nous constatons malheureusement quelques légères difficultés avec de la matière de première année... un point particulièrement problématique est celui du traitement des exceptions en Java.

En particulier, la formation en première année (selon mes souvenirs) ne se concentre que sur l'aspect interception des exceptions, comme une nuisance mineure mais inévitable; la création d'exceptions propres au programme, et le report du traitement des erreurs, sont malheureusement mis de coté. Je ne crois pas avoir jamais fait d'exercice consistant a remonter une exception dans un cas concret.

L'intérêt des exceptions est évidemment de pouvoir déférer le traitement d'erreurs a une couche plus élevée du code, la ou il est possible de prendre une décision pertinente quant au traitement de l'erreur, et ce sans saturer l'interface de la méthode.

Exemple: voici une fonction sensée construire un objet 'blob' à partir d'un fichier:


Blob lire(String fichier) {
Blob b = ...
FileInputStream f = ...
...
f.close();
return b;
}

Mais si le fichier ne peut être lu ? d'ailleurs, le code précédent ne compile même pas; il y a plein d'exceptions IOException non récupérées. Que faire ? j'ai vu beaucoup de gens tomber dans le travers suivant:


Blob lire(String fichier) {
try {
Blob b = ...
...
return b;
} catch (Exception e) {
return null;
}
}


FAUX !!!
Non seulement le code appelant risque de se manger une NullPointerException à tout moment, mais en plus on perd complètement la traçe de l'erreur initiale. Et en plus, si un problème survient pendant la lecture (formatage, etc...) le fichier ne sera jamais fermé !

On réessaie:


Blob lire(String fichier) {
try {
FileInputStream f = ...
//fichier bien ouvert, il faut le fermer
Blob b;
try {
...
} catch (IOException e) {} //Erreur pendant lecture
f.close();
return b;
} catch (Exception e) {
return null;
}
}

ARCHI-FAUX !!!

La encore, on retourne un b qui risque d'être incorrect si le parsing n'a pas marché. Sans compter la laideur... notez qu'on ne peut retourner le b avant le f.close(), puisque le return termine la fonction, forcément...

On nous a enseigné que la syntaxe appropriée est:

try { ... } { { catch(Type e) { ... } } } finally { ... }

en première année, on se contente de dire que "le contenu du bloc finally est toujours exécuté après le contenu du bloc try, même si celui-ci a levé une exception.

Naif étudiant en première que j'étais, je me suis posé la question: Mais quelle est donc la différence entre:


try {
... //throws MyException
} catch (MyException e) {
...
} finally {
... // blah blah
}


et


try {
... //throws MyException
} catch (MyException e) {
...
}
// blah blah


? Dans les deux cas, si le contenu du bloc try lève une exception MyException, celle-ci est attrapée, et le code "blah blah" est exécuté. Alors pourquoi cette clause finally ?

Ce qui n'a pas assez été répété, c'est que le code dans le "try" peut très bien lever une autreexception que celle de la clause catch (qui est d'ailleurs facultative). D'une part, le code peut lever une exception de type RuntimeException (dont l'interception n'est pas obligatoire, car de telles exceptions sont considérées imprévisibles), d'autre part, la méthode contenant le bloc try/finally peut très bien déclarer elle-même lever des exceptions. Enfin, sachez également qu'il est possible de faire un "return" a l'intérieur d'un bloc try/finally, et que la clause finally sera exécutée tout de même !

Ce qui nous amène naturellement a la version légèrement plus correcte de l'exemple précédent:


Blob lire(String fichier) throws IOException {
FileInputStream f = ...
//fichier ouvert
try {
Blob b = ...
...
return b;
} finally {
f.close();
}
}


Notez que nous n'avons utilisé qu'un seul try/catch, que nous n'avons pas besoin de prédéclarer b dans un autre bloc (ce qui est laid), que f.close() sera toujours appelé si le fichier a été correctement ouvert, que le b retourné sera toujours correct, que le programme appelant aura a sa disposition toute l'information nécessaire pour réagir correctement à l'erreur, et que le compilateur informera le programmeur si le code de traitement d'erreur est oublié.

lundi 29 octobre 2007

Tests de VCS distribués

Je suis depuis quelques temps à la recherche d'un nouveau VCS (Version Control System). J'utilise habituellement Subversion, qui a l'avantage d'être répandu. Mais le versionage centralisé commence à montrer ses limites. La goutte d'eau qui a fait déborder le vase a été le serveur SVN du LCA auquel je n'ai pu accéder a cause d'un glitch administratif, et qui nous a poussé à héberger l'arbre de CaveShooter sur un serveur à part, et la perte de temps qui s'en est suivie.

Quatre VCS distribués ont retenu mon attention pour l'instant: Bazaar, Darcs, Mercurial et Monotone.

J'ai eu tenté de migrer vers Arch (l'ancêtre de Bazaar) il y a quelque temps, mais j'ai trouvé l'interface rébarbative. Il semblerait que Bazaar aie porté le focus sur la facilité d'utilisation; c'est probablement une bonne chose.

Darcs prétend fournir des merges plus puissants, étant basé sur la "théorie des patches". L'interface est en revanche assez différente des VCS que je connais pour être déstabilisant.

Mercurial est très façile a prendre en main pour un utilisateur habitué à Subversion, la migration étant quasiment transparente.

vendredi 26 octobre 2007

CaveShooter 0.2

La programmation de CaveShooter avance gentiment:
  • La machine d'états TCP inclut maintenant le système de discussion et les join/part des divers participants.
  • Côté UDP, un nouveau trick de multithreading permet d'avoir des ticks un peu plus réguliers.
  • Les Magic Numbers manquants ont été corrigés
  • La logique de jeu a évolué, les objets sont maintenant capables de se déplacer, le tir devrait suivre sous peu.
  • La structure dans caveshooter.protocol.* a été revue et concerne maintenant la sérialisation/désérialisation des messages udp uniquement, le reste étant géré par les clients et serveurs respectifs

mercredi 24 octobre 2007

Configuration de l'équipement réseau

J'ai commencé à reconfigurer les équipements en accord avec le nouveau schéma d'allocation choisi.

Il semblerait que le protocole de trunking utilisé par le Dell 6224 soit incompatible avec les autres équipements Dell que nous avons (5224 et 3424); sur les switches que nous avions, le vlan 1 est considéré comme le vlan par défaut, et ses paquets ne sont jamais taggés, mais toujours envoyés tels quels sans étiquette de vlan. C'est une mesure de compatibilité; un client qui ne comprend pas les vlans 802.1q et se retrouve accidentellement connecté à un port trunk sera vu comme appartenant au vlan 1.

Sur le 6224, les paquets appartenant au vlan 1 sont taggés quand ils sortent par un port trunk. C'est probablement une mesure de sécurité, soit pour empêcher un client hostile du vlan 1 d'injecter des paquets a destination d'autres vlans à travers un port trunk.

La différence entre ces deux modes de gestion empêche les paquets du vlan 1 de traverser les port trunk entre le 6224 et les autres modèles. Il faudrait passer les trunks entre les backbones en mode générique, pour forcer les paquets du vlan 1 à sortir en mode non-taggé, ou ne plus utiliser le vlan 1 du tout. Pour l'instant, je retiens la 2e solution, qui est plus simple à configurer, mais empêche un client mal configuré de fonctionner sur un port trunk (ce peut être un mal ou un bien, en fonction de la situation)

Je pense également placer Loulou dans un micro-subnet à part, de manière a faire tout transiter par le 6224. Ca permettra à tous les autres équipements du réseau de n'avoir a configurer qu'une entrée de routage par défaut.

Le système de génération des configurations a été mis a jour pour inclure le nouveau schéma de vlans, et mettre les ports utilisateurs dans le vlan 2 par défaut.

mardi 23 octobre 2007

La structure réseau se met en place

On commence gentiment à planifier la topologie du réseau pour PolyLAN X.

Comme nous ne sommes pas certains de la performance qu'apportera la segmentation du réseau, nous allons prévoir quatre subnets pouvant accomoder ~ 500 machines chacun. Au début de la LAN, tous les participants seront dans un subnet unique, et nous couperons le réseau en 2 segments de 200, ou 4 segments de 100, si nécessaire.

La classe d'allocation 10.0.4.0/24 sera gardée pour le vlan administratif de l'équipement réseau. Nous utiliserons 10.1.0.0/16 à 10.4.0.0/16 comme subnets opérationnels. Dans ces subnets, 10.x.0.0/24 sera réservé pour les serveurs multihomed, tandis que 10.x.2.0/23 sera une classe libre à allouer aux joueurs.

Pour ce faire, nous abandonnons l'utilisation du proxy-arp. Premièrement, cette technique n'apporte qu'un faible avantage par rapport à des subnets distincts. Avec des subnets distincts, déplacer une machine de segment requiert de la déconnecter pour lui réallouer une adresse différente, tandis qu'avec le proxy-arp, même si l'adresse peut rester la même, il est quand même nécessaire de purger la table arp pour que le réseau fonctionne correctement, mais également de purger les entrées relatives a ce client sur toutes les autres machines. En pratique, on devra donc se baser sur le timeout arp pour faire expirer ces entrées, ce qui est peu pratique et exclut l'utilisation d'un timeout large. Or, nous comptons sur l'utilisation d'un timeout large pour réduire le traffic ARP.

Deuxièmement, l'architecture en subnets permet aux applications de savoir qu'elles ne communiquent pas avec des machines locales. Le proxy-arp peut en théorie rendre impossible le fonctionnement de certaines applications, et nous manquons de temps pour tester.

Pour permettre a tous les joueurs de voir tous les serveurs, les serveurs découvrables par broadcast (CS, BF ?) seront tous multi-homed; chaque serveur disposera d'une adresse dédiée pour chaque subnet différent.

Pour réduire encore plus le traffic de broadcast, nous installerons un serveur WINS, et demanderons si nécessaire a nos joueurs de configurer leur machine en p-mode (pas de broadcasts netbios). J'essaierai de bricoler qqch pour envoyer des messages popups aux machines fonctionnant en b-mode.

vendredi 19 octobre 2007

SpaceShooter devient CaveShooter

Le projet du cours sc250 pour l'année 2007 s'appelle désormais CaveShooter. Plus question de vaisseaux spatiaux, mais des hommes des cavernes opérant des catapultes pour lancer des rochers.

Côté implémentation, Aris a terminé les classes du modèle, et a attaqué la vue graphique; j'ai implémenté le serveur TCP, la machine d'états pour le prologue TCP, et le receveur UDP.

Le code est versioné avec SVN sur Xolus, mais je me demande sérieusement si je ne vais pas migrer vers Bazaar.

mercredi 17 octobre 2007

Résolu les crashs sur Fifi, structure réseau finalisée

Le plantage systématique de Firefox sur Fifi a été résolu. Apparemment, il s'agit d'un bug dans le driver ATI de X.org, propre à un modèle de carte particulier (ATI Rage IIC). L'accélération 2D hardware a été désactivée (option NoAccel de X.org), le système ne plante plus.

L'organisation réseau a été finalisée pour PolyLAN X. Nous aurons 3 subnets dans des VLANs séparés, respectivement 10.0.[1,2,3].*, pour les joueurs. 10.0.x.1 sera reservé pour le routeur Dell. 10.0.x.2 sera réservé également pour Fifi, qui aura besoin d'un accès a tous les domaines de broadcast pour le monitoring DHCP notamment.

Chaque joueur se trouvera dans un VLAN correspondant initalement au tournoi correspondant (CSS, RTS, et Autres). Il sera possible de changer dynamiquement de VLAN via une interface web, mais chaque VLAN sera limité à 200 personnes.

mardi 16 octobre 2007

Ouf

Ma demande de déplacement pour mon service militaire a été acceptée. Je vais pouvoir finir mon PDM tranquille, j'aurai tout le temps nécessaire pour m'occuper du milliard de choses que j'ai a faire. Champagne !

SpaceShooter v2.0

Aujourd'hui, j'ai commencé a travailler sur SpaceShooter "v2.0", le projet qui sera proposé en cours de réseaux pour les 2e SSC/3e informatique. Je ne peux pas en dire beaucoup pour l'instant, mais tout est dans le nom... le jeu ressemblera à celui que nous avons utilisé en 2004, mais avec de nombreuses améliorations, et un protocole réseau largement différent.

Comme de juste, Aris s'occupera du client et moi du serveur. C'est toujours amusant de revenir sur du vieux code qu'on a écrit...

A la fin du projet, je pense qu'on pourra publier ici le petit jeu, histoire de s'amuser un peu.

lundi 15 octobre 2007

Nouvelles de PolyLAN 0xA

PolyLAN X (0xA pour les intimes) approche à grand pas (10-11 novembre, pour les pas encore inscrits). Je travaille toujours sur PLT; cette version-ci va voir venir de nombreux changements clef.

- LLDP est maintenant activé sur les ports tronc du réseau. Un module est en cours de développement, qui permettra de récupérer la topologie en live sur le réseau de production (fini les incohérences avec l'affichage des liens). Auparavant, le système pouvait seulement vérifier la cohérence a l'aide des tables de forwarding.
- Beaucoup de paramètres codés en dur sont maintenant configurables depuis un endroit central (PolyLAN/Config.pm), ce qui facilitera l'installation du software sur un autre système.
- Le système de quarantaine a été remis a niveau (il était abandonné depuis l'introduction de l'authentification par 802.1x), les vlans sont maintenant configurables depuis une position centrale; le mécanisme de configuration des switches y a été adapté
- Les switches sont maintenant reconfigurables automatiquement également par tftp et plus seulement via le port série (si la configuration actuelle du switch le permet)

Nous avons également reçu un routeur Dell 6224 qui sera le nouveau coeur de notre réseau. Nos 400 joueurs seront divisés en 3 vlans (correspondant par defaut au jeu qu'ils ont choisi). Chaque vlan sera un subnet séparé, pour réduire le traffic de broadcast. Il sera possible de changer en cours de LAN, nous n'avons pas encore décidé comment. (manuellement, interface web, semi-automatique ?)

Il sera maintenant possible pour un joueur d'obtenir plusieurs adresses IP sans déclencher une alarme. Il n'y aura plus d'alarme lorsque un joueur change de carte réseau par exemple. En revanche, chaque adresse MAC se verra associer durablement une adresse unique, et le système gardera trace du propriétaire de chaque machine.

Encore une migration

Voila, j'ai encore une fois migré de plateforme pour raconter ma vie. Ce blog fait suite à la défunte installation DotClear que je n'avais plus le courage de maintenir. Je vous encourage à mettre a jour vos bookmarks vers cette nouvelle addresse (http://blafh.blogspot.com).