Ferdirand's Log

Sunrise bloquent-ils le SSH en sortie ?

2012-01-19T01:24:00.001+01:00

***UPDATE***: Le filtrage semble avoir disparu. La panne coïncidait avec une mise en maintenance de leur site web, y'avait-il un rapport ? Quoi qu'il en soit, merci Sunrise :)

Ceci est un appel à témoins pour les clients Sunrise possédant des smartphones.

Depuis hier, mon téléphone est mystérieusement incapable de se connecter en SSH à mes serveurs habituels via la connexion mobile 3G:

- Si je déplace le serveur SSH sur un port alternatif, ça marche

- Si le téléphone est en wifi, ça marche

- Le problème affecte 3 machines différentes, sur des réseaux complètement différents

- Le problème n'apparait sur aucun de mes autres équipements clients

Je crois qu'on peut conclure que le problème vient de leur réseau, délibéré ou pas.

Si j'observe les tentatives de connexion avec tcpdump, je recois le premier syn, en revanche le synack en retour semble ne jamais atteindre mon téléphone. J'observe 3-4 tentatives de connexion, après quoi le client ssh sur le téléphone abandonne.

Quelqu'un a-il observé un comportement similaire ? Je contacterai leur service technique demain pour savoir si c'est délibéré.

Vote électronique: Critique, Réponses, Coïncidences

2011-11-17T15:30:00.002+01:00

La Critique

Le jeudi 20 octobre 2011, le journal 24 heures publiait en courrier des lecteurs (page 26) une lettre signée de "P. Santschi, ancien député au grand conseil et ancien directeur du centre de calcul de l'EPFL". M. Santschi y évoque un système de vote électronique développé au sein du canton de Genève, et mentionne l'absence de garantie cryptographique du secret de vote. Il fait également référence a l'affaire des chevaux de troie utilisés sans cadre légal précis par la police pour traquer la criminalité en ligne. Il évoque, mais sans les préciser, les dangers posés par la combinaison de ces deux technologies.

Ces dangers méritent un éclaircissement. L'opposition à l'utilisation des chevaux de troie ne se justifie pas, comme certains voudraient le faire croire, par un désir de préserver la vie privée. Elle provient d'une part de l'absence d'un cadre légal clair qui devrait être de mise, comme il en est pour les autres prérogatives des services de police; et d'autre de considérations purement techniques liés a la qualité douteuse des logiciels utilisés.

Il a en effet été révélé que le cheval de troie utilisé par la police allemande, insuffisamment sécurisé, laissait les ordinateurs ouverts a l'abus de tous. Imaginez qu'un enquêteur de police, plutôt que de procéder a la fouille du domicile d'un suspect, fracture systématiquement toutes les serrures et les laisse en l'état, pour faciliter les fouilles ultérieures. Imaginez qu'un cambrioleur en profite pour entrer dans ce domicile, y voler tous les objets de valeur, et y cacher son stock de drogue. Y voyez-vous un problème ?

L'observation de M. Santschi soulève donc un problème intéressant et souligne l'importance de la création de bases légales claires, et d'une assurance sur la qualité des outils utilisés par les enquêteurs.

La remarque concernant le non respect du secret de vote est un problème à part, et qui mériterait un article en lui-même.

Les Réponse

Suite à cette lettre, le 24 heures publie, le 31 octobre 2011, toujours dans son courrier des lecteurs (page 27) trois réponses à la lettre de M. Santschi.

Le site de 24 heures ne répond pas, mais les réponses sont encore dans le cache de google:

http://webcache.googleusercontent.com/search?q=cache:KoOBKA6nVsoJ:archives.24heures.ch/VQ/LAUSANNE/-/article-2011-10-3706/a-propos-de-la-lettre-de-lecteur-de-m+claude+bonard+ours+vaudois&hl=fr&client=firefox-a&gl=ch&strip=1

La première, signée Sonia Lardi, de Genthod, titrée "Difficile de le prendre au sérieux", rejette la critique de M. Santschi sur l'absence de secret de vote. A juste titre, Mme Lardi rappelle que les méthodes de vote papier dépendent aussi de la confiance envers l'administration, et qu'il n'y a pas lieu de critiquer un vote électronique qui offre une sécurité aussi bonne que le vote traditionnel.

Cet argument est incomplet, car il ne prend en considération que le risque d'une action malveillante de la part d'un agent de l'administration, sans considérer la portée de ce risque. Or en gestion du risque, il est nécessaire de quantifier ces deux aspects. La portée d'une action malveillante est beaucoup plus grande avec le vote électronique: si des scrutateurs entrent en collusion pendant le dépouillement pour modifier le compte des bulletins, ils pourront au pire falsifier les résultats d'une circonscription, sans compter le risque d'une recompte. Un informaticien malveillant ayant le contrôle total du système pourra, lui, aisément altérer le vote entier. Il est donc faux de comparer ainsi la sécurité du vote électronique et du vote traditionnel: il est normal d'exiger d'un vote électronique, dont les conséquences sont beaucoup plus graves en cas de faille, une réduction du risque d'attaque, tout comme on doit soumettre (en théorie) les centrales nucléaires à des controles techniques plus stricts que ceux d'une chaudière individuelle.

Si Mme Lardi se fourvoie dans son raisonnement, elle a au moins le mérite d'apporter un argument concret a l'encontre de la lettre de M. Santschi. Ce n'est pas le cas des deux suivants.

La deuxième lettre est signée Claude Bonard, de Vernier. Celle-ci met les griefs de M. Santschi envers le système de vote genevois sur le compte d'une rivalité entre cantons, sans plus argumenter.

La troisième, signée Michel Chevallier, de Mies, intitulé "Quelle bêtise !", reproche à M. Santschi de décrédibiliser l'EPFL et le Conseil National en signant de ces titres ce que M. Chevallier considère comme, je cite, "une ânerie pareille", là encore sans argumenter,.

Les Coïncidences

Cette troisième lettre m'a interpellé parce que le nom de son auteur ne m'est pas inconnu. En effet, l'article du Flash Informatique de Juin 2011 (http://flashinformatique.epfl.ch/spip.php?article2314) qui décrit l'architecture du système de vote genevois, est signé du même nom. Coïncidence ?

(Au passage, mon avis personnel, en tant qu'ingénieur diplômé EPF et candidat doctoral en cryptographie, est que ce design présente plusieurs erreurs grossières: transmission de la partie privée d'une clef asymétrique sur le réseau, création d'une table pour inverser un hash, utilisation redondante de chiffrement, et mixage inopérant) Espérons que les schémas présentés soient faux et ne soient pas le reflet du fonctionnement actuel du système.)

Une recherche sur internet nous apprend qu'une Mme Sonia Lardi a travaillé auprès de la Chancellerie d'Etat. On apprend également qu'un Claude Bonard aurait occupé le poste de secrétaire général de la Chancellerie d'Etat de 2000 à 2010.

Coïncidences ?

Failover IP sur une VM en proxy-arp

2011-10-27T13:38:00.000+02:00

Le proxy-arp est une technique intéressante qui permet de se passer d'un bridge lorsqu'on héberge des machines virtuelles. Elle empêche également l'admin de la VM de voler des addresses dans le subnet local comme c'est le cas avec un bridge. Cepandant, attention à cette intéraction néfaste avec le failover IP...

Avec une VM bridgée classique, l'hôte établit un pont entre l'interface réseau physique et les interfaces réseau virtuelles. Les requêtes ARP sur le subnet local sont transmises à toutes les VM, et chaque VM décide ou non d'y répondre, sans contrôle de l'hôte (bien sur on peut utiliser ebtables pour filtrer)

Au lieu d'utiliser des interfaces virtuelles de type ethernet, on peut également utiliser des liens point-à-point virtuels. Côté VM, l'interface a donc une addresse unique /32, et une addresse p2p fixe (typiquement 10.64.64.64) qui sert de passerelle par défaut. Côté hôte, pas de problème pour avoir une addresse unique sur plusieurs interfaces, parce que les interfaces sont point-à-point, il n'y a donc pas d'ambiguité sur la source. Mais dans cette configuration, comment le routeur du subnet local sait-il qu'il doit addresser les paquets a destination des VM sur l'addresse de l'hôte ?

En activant le proxy-arp sur l'interface physique de l'hôte, l'hôte répondra en arp pour toutes les addresses qu'il est capable de router. Il suffit donc d'ajouter une route statique vers le bon tunnel point-a-point pour chaque VM. C'est ce que fait, d'ailleurs, le script fourni avec openvz pour la gestion des addresses des VMs.

Mais que se passe-il si, par mégarde, une VM vient a déconfigurer une addresse qui lui a été allouée, sans en avertir l'hôte ?

La route statique étant en place, l'hôte va continuer a router les paquets à destination de cette addresse vers le tunnel. Et si le guest a le forwarding activé, il va joyeusement transmettre les même paquets à sa passerelle par défaut, dans le même tunnel, dans l'autre sens.

Chez moi, ça se traduit par un load average de 12, ksoftirqd qui prend 60% du cpu, et 5 secondes de latence entre chaque caractère tapé en ssh.

En bridge, ça marche mieux...

Tutorial: un VPN ipv6 pour la maison, sous Gentoo

2011-10-08T19:56:00.002+02:00

Voici comment se fournir un bloc IPv6 statique a domicile, a partir d'un serveur ayant une addresse v4 stable, avec 6to4 et OpenVPN.

Mes machines, toutes deux sous Gentoo:
* Xolus: serveur housé avec une IP statique sur eth0
* Glokrik: serveur de la maison, IP NAT sur eth0

6to4

La configuration de 6to4 est facile avec Gentoo. J'ajoute dans /etc/conf.d/net sur xolus:


link_6to4="eth0"
config_6to4="ip6to4"
depend_6to4() { need net.eth0 }

Et je crée le service correspondant:


ln -s net.lo /etc/init.d/net.6to4
rc-update add net.6to4 default
rc

Et on teste:


ping6 www.kame.net

OpenVPN

On emerge openvpn sur les deux machines, et on commence par créer les clefs cryptographiques nécessaires. Pour deux machines les clefs statiques sont plus simples, mais dans l'hypothèse d'un ajout ultérieur de machines je vais utiliser une PKI. Il y a des scripts d'aide dans /usr/share/openssl/easy-rsa/. On copie ce répertoire vers un rep de travail.

On y édite le fichier vars et on ajuste les champs des dernières lignes. Puis on source ce fichier et on génère la CA et les clefs des serveurs:


. ./vars
./clean-all
./build-ca
./build-key-server xolus
./build-key glokrik
./build-dh

On viole techniquement un principe des PKI en générant les clefs client sur le serveur, mais bon ;)

Sur xolus, je copie ca.crt, dh1024.pem, xolus.crt et xolus.key dans /etc/openvpn/. Je transfère ensuite ca.crt, glokrik.key et glokrik.pem au meme endroit sur la machine glokrik.

Sur xolus, je crée la définition suivante dans /etc/openvpn/openvpn.conf:


port 1194
proto udp
dev openvpn
dev-type tun
tun-ipv6
tls-server
ca ca.crt
cert xolus.crt
key xolus.key
dh dh1024.pem

Sur glokrik, dans /etc/openvpn/xolus.conf:


port 1194
proto udp
remote 213.162.22.228
dev xolus
dev-type tun
tun-ipv6
tls-client
ca ca.crt
cert glokrik.crt
key glokrik.key

On ajoute les services openvpn au démarrage. Les machines disposent maintenant chacune d'une interface réseau tunnel supplémentaire, qu'il faut maintenant configurer

On vérifie sur les deux machines, avec ip link show, que les deux interfaces sont actives (flag LOWER_UP).

Tunnel IPv6

On commence par calculer le bloc 6to4 à disposition. L'IP fixe de ma machine est 213.162.22.228, mon bloc 6to4 est donc 2002:d5a2:16e4::/48. (Prefixe 2002, suivi de l'addresse v4 convertie en hexadécimal). Il y a ensuite 16 bits disponibles pour le subnet, je vais utiliser 00ff pour le VPN, et 0001 pour le subnet de ma maison. Dans le subnet vpn, l'addresse ::ff sera attribuée au serveur, et l'addresse ::xxxx au client responsable du subnet xxxx.

Sur xolus, dans /etc/conf.d/net:


config_openvpn=( "2002:d5a2:16e4:ff::ff/64" )
routes_openvpn=( "2002:d5a2:16e4:1::/64 via 2002:d5a2:16e4:ff::1" )
depend_openvpn() {
need openvpn
}

Sur glokrik:


config_xolus=( "2002:d5a2:16e4:ff::1/64" )
routes_xolus=( "2000::/3 via 2002:d5a2:16e4:ff::ff" )
depend_xolus() {
need openvpn.xolus
}

On ajoute ces deux services au démarrage, on les lance, et on teste le fonctionnement du tunnel:


glokrik # ping6 2002:d5a2:16e4:ff::ff
PING gw.vpn.xolus.net(2002:d5a2:16e4:ff::ff) 56 data bytes
64 bytes from 2002:d5a2:16e4:ff::ff: icmpseq=1 ttl=64 time=8.54 ms
64 bytes from 2002:d5a2:16e4:ff::ff: icmpseq=2 ttl=64 time=8.11 ms

On active ensuite le forwarding sur la passerelle:


echo "net.ipv6.conf.all.forwarding = 1" >>/etc/sysctl.conf
sysctl -p

Glokrik peut maintenant pinguer des sites ipv6 publics:


glokrik # ping6 www.kame.net
PING www.kame.net(2001:200:dff:fff1:216:3eff:feb1:44d7) 56 data bytes
64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=1 ttl=58 time=340 ms

RADVD

Il faut maintenant fournir la connectivité ipv6 aux hôtes de la maison. Pour celà il suffit d'installer radvd sur glokrik, et d'y ajouter la conf qui va bien dans /etc/radvd.conf_


interface eth0 {
AdvSendAdvert on;
prefix 2002:d5a2:16e4:1::1/64 {
AdvOnLink on;
AdvAutonomous on;
};
};

On édite ensuite le script de démarrage /etc/init.d/radvd pour changer la dépendance:


depend() {
need net.xolus
}

Ce qui empêche radvd de démarrer tant que le lien vpn n'est pas up.

Notez qu'il n'y a pas besoin d'activer le forwarding ipv6 sur glokrik, le script de démarrage de radvd s'en charge.

radvd démarré, ma machine de bureau reçoit presque immédiatement une addrese v6, et je peux pinguer des sites publics.

6to4reverse

Une fois la connexion 6to4 active, il suffit d'aller sur https://6to4.nro.net et d'enregistrer ses serveurs de noms pour disposer du reverse.

Une conférence avec Michel Riguidel

2011-10-05T20:39:00.003+02:00

J'ai eu le plaisir, cet après-midi, d'assister à une conférence ayant pour thème les dangers et futurs enjeux de la guerre électronique. Parmi les invités, un certain Michel Riguidel, dont le nom m'est alors inconnu, cité comme "conseiller pour le gouvernement français" en matière de cybersécurité, et auteur de plusieurs brevets liés a la sécurité.

Dès la première slide, bien remplie de texte, on comprend que la présentation sera technique et concrète, loin des généralités banales du conférencier précédent. Je m'en réjouis.

Pas pour longtemps, hélas.

Je vais immédiatement mentionner le SEUL point de son discours avec lequel je me trouve en accord: les géants comme Facebook présentent un danger significatif pour la vie privée (pour M. Riguidel, un tel pouvoir est une prérogative d'état.)

M. Rigidel accumule dans son discours tellement de "WTF"s et d'apparentes inepties que je n'ai la présence d'esprit de tous les noter. Ce dont je me rappelle, en vrac:

- TCP/IP est complètement obsolète (je suis d'accord pour TCP, mais avec LTE et les futurs réseaux téléphoniques tout IP, on peut se poser la question)
- la liberté sur Internet conduira au nivellement par le bas de la culture (LOL)
- PGP est une catastrope politique (LOL)
- Le chiffrement ne sert qu'aux entreprises désirant narguer le gouvernement en l'empêchant de surveiller ses flux (parce que le gouvernement est incapable d'obtenir une clef de chiffrement par des moyens non-techniques, le citoyen doit renoncer au chiffrement même si cela l'expose aux abus de son ISP ou d'un fournisseur de cloud)
- Cloud et P2P sont des technologies opposées, et populairs par effet de mode mais de nature éphémère.
- L'anonymat sur internet est une catastrophe, des personnalités (dont lui-même) se font diffamer sans aucun contrôle (Effet Streisand, il ne connaît pas ?)
- Les "hippies" soutenant le libre sont une minorité de hackers marginaux dont le travail n'est bénéfique que très occasionnellement (il ne doit pas être au courant de la représentation de Linux dans le top500, tiens).
- Internet est tellement centralisé qu'il se résume aujourd'hui a 300 serveurs
- Puisque la loi de Moore s'est arrêtée en 2008, et comme il est impossible de scaler un système a plus de 4 processeurs, l'arrêt brutal de la performance amènera un "crépuscule numérique". (Larrabee ça n'existe pas)
- L'informatique sera obsolète en 2100 et remplacée par la nanotechnologie.
- Le progrès cryptographique en occident est arrêté depuis 10 ans et les chinois sont largement en avance sur l'europe ou les états-unis.

Ces positions déraisonnables relèvent au mieux de l'incompétence, au pire d'une totale malhonnêteté intellectuelle. Je me demande si M. Riguidel croit vraiment à ce qu'il raconte, ou s'il déforme volontairement la réalité pour pousser un agenda politique.

Pour le dernier point de la liste, je me suis fendu d'une question simple: pourquoi, si la chine est tellement en avance en matière de crypto, les universités chinoises représentent moins de 20% des publications soumises à Asiacrypt 2011 ? réponse de M. Riguidel: "ah mais dans ces conférences le jury est pipé de toute façon." Ben voyons. Et d'étayer son raisonnement par le fait que Xiaoyun Wang, d'origine chinoise, est l'auteure de plusieurs papiers sur des collisions de hachage. Je n'ai pas eu le coeur de lui rappeler qui est a l'origine des collisions sur certificats x509, ou de la factorisation de RSA-768, ou des milliers d'autres problèmes actuels en crypto. Mais bon.

J'ai pu ainsi me faire, par moi-même, une opinion assez claire du personnage. Mais je suis quand meme allé voir sur google, histoire de voir de quelle "diffamation" il parlait. Je constate que S. Bortzmeyer, personnage avec qui j'ai eu le plaisir de discuter occasionnellement sur IRC, et dont je respecte hautement les compétences techniques, le qualifie ni plus ni moins de "Bogdanoff du net". Même son de cloche auprès de mes autres connaissances au sein du FrNOG.

Je suis ébahi que l'UNIL offre une telle tribune à ce personnage, qui se permet de prendre position avec une arrogance incroyable sur des sujets sur lesquels le consensus est quasi universel au sein de la communauté scientifique, et sans offrir aucune démonstration ou justification à ses propos. Ebahi et un peu dégoûté.

Dieu merci, les intervenants qui lui ont succédé ont fait preuve de raison et de pragmatisme, sans quoi je serais certainement parti avant la fin.

Tuning NFS pour démarrer un cluster

2011-10-04T22:10:00.000+02:00

Le cluster AMD64 du LACAL comporte 90 noeuds, pour l'instant tous servis depuis un frontend unique qui héberge leurs racines NFS. En cas de coupure, si tous les noeuds redémarrent en même temps, le serveur NFS se retrouve légèrement surchargé, et plusieurs noeuds se retrouvent dans un état bloqué (kernel panic).

Une partie des noeuds ne dispose ni de contrôleur IPMI ni de watchdog, ce qui rend les redémarrages un peu chaotiques. Mais la situation peut être grandement améliorée par trois règlages:

1) Augmenter le nombre de processus pour le démon nfsd. Avec Gentoo ceci se règle par la variable OPTS_RPC_NFSD dans /etc/conf.d/nfsd

2) Utiliser le port 627 pour le démon mountd (même fichier, variable OPTS_RPC_MOUNTD). C'est le port spécifié n dur dans le noyau au cas ou le portmapper serait trop lent a répondre.

3) Augmenter la tolérance du client nfs, en passant l'option adéquate au noyau. Ici, dans la config pxelinux de chaque machine:

append root=/dev/nfs nfsroot=10.1.0.2:/var/nfs/nodexx,retrans=10,timeo=30

Software CPU Upgrade

2011-09-26T17:05:00.000+02:00

Q: What to do when an annoying customer insists that he wants a CPU from a different brand on his Linux dedicated server ?
A: This: http://bitbucket.org/maugier/cpufake

Dégoûter les démarcheurs téléphoniques avec Asterisk

2011-09-26T17:00:00.000+02:00

Les démarcheurs téléphoniques, c'est chiant. Débarassons-nous en avec Aterisk. Au menu: un menu vocal horripilant, et un raccrochage dans la face au bout de quelques minutes.

D'abord, le matériel: un petit serveur de récup', déja allumé en permanence pour les diverses tâches de la maison. J'y ajoute une interface téléphonique analogique, une A400P de chez OpenVox, avec un module FXO (pour y brancher la ligne téléphonique) et un module FXS (pour y brancher mon ancien téléphone). J'intercale donc mon PBX entre mon téléphone et ma ligne.

Le serveur est sous Gentoo, j'y installe Asterisk 1.8 ainsi que le driver DAHDI. J'ajoute le module wctdm dans /etc/modules.autoload.d/kernel-2.6.

Il faut ensuite générer la config du driver avec dahdi_genconf, vérifier que les modules FXO et FXS sont bien détectés. Voici le contenu auto-généré de /etc/asterisk/dahdi.channels.conf:

;;; line="1 WCTDM/4/0 FXSKS"
signalling=fxs_ks
callerid=asreceived
context=sunrise
channel => 1

;;; line="2 WCTDM/4/1 FXOKS"
signalling=fxo_ks
callerid="Maison" <1>
context=maison
channel => 2

Notez que la terminologie est inversée pour le signaling: le module FXO, qui se comporte comme un téléphone, utilise le signaling FXS (car il cause avec la ligne FXS de mon fournisseur) alors que le module FXS, qui cause à mon téléphone, utilise le signaling FXO pour parler a mon téléphone FXO)

A ce stade on peut lancer Asterisk avec le script système, et attacher la console avec

glokrik # asterisk -r

...

=========================================================================
Connected to Asterisk 1.8.5.0 currently running on glokrik (pid = 31554)
glokrik*CLI>

On teste en passant un appel bidon, d'abord vers le téléphone (la ligne 2)

glokrik*CLI> originate DAHDI/2 application sayphonetic ABCDEF

Le téléphone sonne, parle quand on décroche, puis raccroche, youpie.

On teste un appel sur la ligne sortante:

glokrik*CLI> originate DAHDI/1/076xxxxxxx application sayphonetic ABCDEF

Cette fois-ci j'ai un petit bug, Asterisk ne détecte pas correctement le décrochage de la ligne et envoie le message immédiatement. A investiguer, mais sans conséquence pour ce que nous voulons faire.

Premièrement, rendons le PBX transparent en lui permettant de passer des appels entrants et sortants vers et depuis le combiné de la ligne 2. J'ajoute dans /etc/asterisk/extensions.conf

[maison]

exten => _X.,1,Dial(DAHDI/1/${EXTEN})

exten => _X.,2,Hangup()

[sunrise]

exten => s,1,Dial(DAHDI/2&SIP/monpc)

exten => s,2,Hangup()

Au passage, je fais un tour dans sip.conf et y ajoute un compte pour mon PC, que je nomme monpc, dans le contexte maison; mon PC peut maintenant passer des appels sortants. Notez la définition dans le contexte sunrise qui fait également sonner mon pc quand un appel entrant arrive (le premier qui décroche prend l'appel.)

Maintenant, la partie rigolote: enregistrons un menu vocal idiot. J'utilise Asterisk pour me lancer des appels sur le pc et m'enregistrer:

glokrik*CLI> originate SIP/monpc application record torture-main.gsm

Je décroche, et récite trèèèèès lentement, en me pincant le nez, et de manière générale avec une voix stupide: "Bonjour, vous êtes bien chez XXXXXX, meeeerci de choisir une des options suivantes: si vous appelez dans le contexte de blablabla, appuuuuuyez sur 1,..."

Asterisk enregistre ceci dans le fichier torture-main.gsm. Je procède de la même manière pour enregistrer chaque message, avec torture-submenu1.gsm, torture-submenu2.gsm, ..

J'ajoute maintenant dans extensions.conf le contexte [torture] dans lequel je perds les indésirables:

[torture]

exten => s,1,Background(torture-main)

exten => s,2,Goto(torture,s,1) 

exten => 1,1,Goto(torture-submenu1)

exten => 2,1,Goto(torture-submenu2)

[torture-submenu1]

exten => s,1,Background(torture-submenu1)

exten => s,2,Goto(torture,s,1)

exten => 1,1,Goto(torture-sub-sub1)

exten => 2,1,Goto(torture-sub-sub2)

etc etc...

Note le Goto(torture,s,1) à la fin de chaque s de chaque contexte; si l'utilisateur attend la fin du message, il retourne a la racine du menu. Oui, il faut être rapide !

A la fin de la farce, en divers endroits, un Hangup() se débarasse purement et simplement de l'individu.

Notre contexte torture défini, reste à y envoyer les télémarketeurs. Commençons par une blacklist statique. On modifie le contexte de la ligne entrante:

[sunrise]

exten => s/_00494542801.,1,Goto(torture,s,1) 

exten => s,1,Dial(DAHDI/2&SIP/monpc)

exten => s,2,Hangup()

Ce qui a pour effet d'envoyer tous les numéros commençant par le préfixe mentionné (qui appartient, je crois, à un institut de sondage) vers le menu insupportable.

Ajoutons maintenant une redirection dynamique, pour ceci je vais utiliser une featuremap.
Je modifie encore le contexte entrant:

[sunrise]

exten => s,1,Set(DYNAMIC_FEATURES=torture)

exten => s/_00494542801.,2,Goto(torture,s,1)

exten => s,2,Dial(DAHDI/2&SIP/monpc)

exten => s,3,Hangup()

Et j'ajoute dans /etc/asterisk/features.conf, dans la section [applicationmap], la ligne suivante:

torture => *,self/callee,ChannelRedirect(DAHDI/1-1,torture,s,1)

Qui a pour effet de rediriger l'appel de la ligne extérieure, la ligne 1, vers le contexte cible. "callee" indique que seul le destinataire (donc mon téléphone local) peut utiliser la fonction.

Et voila, il me suffit donc d'appuyer sur * pendant un appel, pour me débarasser du télémarketeur intempestif.

Things learned while writing an erlang driver

2010-11-15T14:00:00.004+01:00

I've spent a couple of days writing an erlang binding for zfec. The binding takes the form of a driver, that is, a shared library written in C that communicates with erlang according to the defined interface.

The reference doc was ambiguous for some points, which gets summarized here:

Q: How is the Command parameter of open_port() passed to the ErlDriverEntry .start callback ?
A: The Command is a string, and the first word (whitespace-separated) must be the name of the driver. The whole string, including the driver name, is passed to the callback.

Q: If I send a list of binaries to the port, can I expect to get every one of them separately with the outputv callback ? How does the SysIOVec struct work ?
A: NO. Small binaries, and presumably sub binaries spliced from a common one, may get merged in the resulting ErlIOVec. I've written this to iterate over an ErlIOVec. The doc defines:

typedef struct {
  int vsize;
  int size;
  SysIOVec* iov;
  ErlDrvBinary** binv;

and does not define (because it is platform-dependant, but in this case we want Unix):

typedef struct {
    char *iov_base;
    size_t iov_len;
}

size is the total byte size of the whole ErlIOVec. vsize is the number of chunks (which may not match the number of binaries in the original iolist). iov and binv both are arrays of size vsize.

binv references the parent refc binaries (so the same binary can appear twice, and you may not be interested in all its data). Use this to manipulate the refcounter of the binary if you need to keep the data around.

iov is the chunks of data you are actually interested in. The two fields should be self-explanatory :)

Q: Is it OK to define the outputv callback and not output one ?
A: yes, you will receive an IOVec with a single chunk

Q: Why does open_port seemingly randomly fail with "bad argument" ?
A: It will if you try to open a driver that is not loaded. Now, erl_ddll is smart and remembers who loaded which driver, and will unload a driver when it is not needed anymore. If you are testing from the shell, getting an uncaught exception will terminate the shell process and start a new one, which may cause your driver to get unloaded.

Q: Why is erl_ddll:load/2 asking for a path ? What is a reasonable value to provide ?
A: According to the OTP doc, the standard way is to use code:priv_dir(app_name)

Changement a chaud de la configuration d'ejabberd

2010-11-04T13:51:00.000+01:00

Depuis le 1er novembre, mon serveur jabber (qui dessert aussi swisslinux.org) dispose du client web Jappix, qui nécessite un point de service BOSH. BOSH est supporté nativement par ejabberd, mais il n'était pas activé dans la configuration .

J'aurais pu redémarrer ejabberd, mais cela aurait provoqué quelques désagréments: déconnexion temporaire de tous les membres utilisant une addresse @swisslinux.org, et déconnexion de la chat-room officielle. Heureusement, il existe un moyen très simple d'ajouter le service à chaud.

Dans la configuration de ejabberd, il existe un tuple appelé "listen", qui liste un certain nombre de "listeners". Chaque listener est responsable d'un port tcp. Par exemple, par défaut, on trouve le listener suivant:

  {5222, ejabberd_c2s, [{access, c2s}, {shaper, cs2_shaper}, starttls, {certfile, "/etc/ssl/jabber.pem"}]}

Cela signifie qu'une instance du module ejabberd_c2s (le listener pour les connexions client) écoute sur le port 5222, avec une liste particulière d'options.

Le listener requis pour BOSH, que j'avais désactivé parce que je n'utilise pas l'interface d'administration web, est le suivant:

  {5280, ejabberd_http, [http_bind]}

Le listener web est un peu particulier, puisqu'il peut écouter sur un seul port et y fournir plusieurs services sur des chemins différents. L'option http_bind active le service BOSH sur l'addresse /http-bind.

Pour ajouter ce listener à chaud, il suffit de se connecter au noeud erlang; sur ma distribution favorite, il suffit d'un simple

hostname # ejabberdctl debug

Qui nous donne un prompt erlang:

  (ejabberd@hostname)1>

On démarre le listener supplémentaire:

(ejabberd@hostname)1> ejabberd_listener:start_listener(5280, ejabberd_http, [http_bind]).

Et hop, ça fonctionne... plus qu'a quitter le shell erlang avec un double Ctrl-C !

shatag: un détecteur de doublons

2010-08-25T23:45:00.000+02:00

Si vous êtes comme moi, il vous arrive fréquemment de déplacer à la main des fichiers volumineux d'un serveur à un autre. Vous n'utilisez pas encore partout un fs distribué, parce que la bande passante disponible ne le permet pas; vous avez des vieilles copies qui trainent dans les coins, et vous ne savez jamais quoi effacer lorsque vous faites le ménage, incapables de vous rappeler si vous avez déja téléchargé le fichier x ou y sur le serveur domestique.

Voici shatag, un petit script python pour inventorier des fichiers efficacement, et détecter les doublons ou la présence de fichiers identiques sur un stockage distant:

http://bitbucket.org/maugier/shatag/

Le programme calcule une somme de contrôle SHA-256 pour chaque fichier, et la met en cache dans un attribut étendu POSIX. La somme reste ainsi en cache même si le fichier est déplacé ou renommé. Une modification du fichier invalide la somme, qui peut être recalculée de manière transparente.

Un autre script permet ensuite de collecter ces sommes via ssh, et de les accumuler dans une base sqlite. Cette base peut ensuite être utilisée pour examiner le fs local, signaler les fichiers qui existent sur un serveur distant, a double ou pas !

Monoïdes, Flèches, et Pliables: un cas particulier

2010-06-10T18:37:00.000+02:00

Voici un joli exemple de la puissance du polymorphisme en Haskell. Le contexte est similaire au problème dit de "stream fusion": il s'agit d'effectuer en une seule passe plusieurs calculs qui demandent d'itérer sur une structure de données. L'exemple classique consiste à calculer la moyenne d'une liste:

average xs = sum xs / length xs

Cette expression est inefficace, parce que le programme va traverser la liste deux fois: une fois pour calculer le sum, une fois pour le length. Bien sur, on peut éviter le double passage en implémentant la récursion à la main:

average = uncurry (/) . foldAverage (0,0) where
    foldAverage (sum,length) [] = (sum,length)
    foldAverage (sum,length) (x:xs) = foldAverage (sum+x,length+1) xs

Ce qui a le désavantage d'être plutôt moche; exprimons le plutôt avec un fold:

average = uncurry (/) . foldl' (\(s,l) x -> (s+x,l+1)) (0,0)

Mieux, sans être extraordinaire. Observons qu'encore une fois, les deux opérations qui nous intéressent (la longeur et la somme) son associatives et admettent un neutre: nous sommes donc en présence d'un Monoid.

Coup de chance, ces deux notions qui nous intéressent sont déja dans la lib standard sous la forme du wrapper Sum, qui transfome n'importe quel Num en Monoid sous l'addition. Mieux: il existe une instance

(Monoid a, Monoid b) => Monoid (a,b)

Qui fait ce que vous pensez: appliquer deux mappend ou mconcat en parallèle.

Pour calculer notre moyenne, commençons par mapper chaque élément de la liste vers une paire de Monoids additifs, effectuons le concat, et il restera la division finale:

average = (\(s,l) -> getSum s / getSum l) . mconcat . map (\x -> (Sum x, Sum 1))

Encore un peu trop verbeux à mon goût: les lambdas peuvent être éliminés grâce aux combinateurs de flèches:

import Control.Arrow
average = uncurry (/) . (getSum *** getSum) 
        . mconcat . map (Sum &&& (Sum.const 1))

Cette fois-ci, nous sommes PointFree, un progrès apréciable. Mais nous pouvons encore améliorer les choses. Par exemple, et si nous généralisions la fonction à d'autres types de données (arbres, arrays, ...)

Nous avons utilisé mconcat, qui n'est autre qu'un fold de mappend. Si nous disposons d'un fold générique pour une structure de données, nous pouvons généraliser. Il existe une classe à ce dessein, la classe Foldable. La définition minimale d'un type Foldable consiste en une seule fonction:

instance Foldable t where
foldMap :: (Monoid m) => (a -> m) -> t a -> m

Qui applique une fonction (a->m) au contenu de la structure pour obtenir un Monoid, sur lequel on appelle mappend. Passer par un Monoid garantit que l'opération est associative, ce qui permet dans certains cas d'explorer la structure très efficacement (sujet d'un prochain article).

Evidemment, par défaut les Lists sont Foldable, et nous pouvons donc réécrire average en utilisant Foldable:

average = uncurry (/) . (getSum *** getSum) . foldMap (Sum &&& (Sum.const 1)

Pour la petite histoire: Il existe deux wrappers Bool, les Monoids And et Or, qui utilisent respectivement (&&) et (||) comme opération. Ceci permet d'écrire très simplement une fonction pour controler en une passe si un ensemble de Booléens ne contient que des True, que des False, ou un mix des deux:

alltruefalse = (getAny *** getAll) . foldMap (Any &&& All)

Cette expression est équivalente à (or &&& and), avec l'avantage de calculer les deux folds en une seule passe....

... ou pas. Cette fonction est en réalité complètement stupide pour deux raisons:

La définition du Monoid sur les tuples est trop stricte, et force l'itération de la liste jusqu'a la fin, même en présence de deux folds paresseux et court-circuités. Ce qui nous amène au point suivant,
or et and sont court-circuités par défaut, et au moins un de ces deux terminera son évaluation immédiatement après le 1er élément (Si le premier élément est True, or retourne True, sinon and retourne False). La fusion des folds n'a donc aucun intérêt dans ce cas particulier !

Haskell, c'est concis !

2010-06-10T17:51:00.000+02:00

Considérez le problème de la rotation d'une liste: On dispose d'une liste xs de longueur inconnue, on souhaite effectuer une rotation de n positions (déplacer n éléments du début à la fin.) Faisons une tentative d'implémentation en Haskell, tout a fait normale, en utilisant la récursion sur n:

rotate 0 xs = xs  

rotate n (x:xs) = rotate (n-1) (xs ++ [x])

C'est bien connu, le ++[x] est très loin d'être efficace (Les listes sont simplement chainées, et immutables, ce qui implique une réallocation complète de l'argument à gauche, donc ici O(l*n) allocations).

Sacrifions un peu de généralité pour une meilleure implémentation (mais qui n'accepte pas de n supérieur à la taille de la liste):

rotate n xs = (drop n xs) ++ (take n xs)

take est une fonction de la librairie standard qui retourne les n premiers éléments d'une liste, tandis que drop retire ces mêmes n premiers éléments.

Concis ? pas encore assez. Intéressons-nous à une classe souvent sous-estimée, le Monoid, dont voici la définition:

class Monoid m where

    mzero :: m

    mappend :: m -> m -> m

    mconcat :: [m] -> m

    mconcat = foldr mappend mzero 

Rien d'extraordinaire ici, la classe Monoid regroupe les types pour lesquels il existe une opération naturelle associative, mappend, et un élément neutre des deux côtés, mzero. Quant à mconcat, c'est une fonction de convenance dont la définition par défaut est donnée.

Il existe beaucoup d'exemples de Monoids; on peut citer les nombres entiers dans deux contextes différents (addition et multiplication), le type Ordering (pour décrire un ordre hiérarchique), mais plus simplement: les listes !

Dans le cas des listes, on à simplement

instance Monoid [a] where

    mzero = []

    mappend = (++)

    mconcat = concat

Comme les Monoids sont fort utiles, on peut généraliser le sens de (++) et de concat à tous les Monoids (c'est d'ailleurs le cas en Caleskell):

import Prelude hiding ((++), concat)

import Data.Monoid

(++) = mappend

concat = mconcat

Ceci nous permet donc d'utiliser (++) sur n'importe quel Monoid, et pas seulement sur les listes.

Voyez-vous ou tout ceci nous mène ? Probablement pas encore, sauf si vous
connaissez l'existence de l'instance suivante (dans la librairie standard):

instance Monoid a => Monoid (t -> a)

dont l'implémentation est laissée comme un exercice au lecteur ;)

Traduction: si les listes [a] forment un Monoid, les fonctions (t -> [a]) en forment également un ! ce qui me permet par exemple de remplacer la définition

f x = g x ++ h x

par une plus concise:

f = g ++ h

A condition que x soit d'un type appartenant à la classe Monoid.

Encore plus fort, notre instance est récursive ! en effet, on à

instance Monoid b => Monoid (t' -> b) 

(on a juste renommé les variables de type).

Posons b = (t -> a), on a alors Monoid a => Monoid b, qui se dérive en

instance Monoid a => Monoid (t' -> (t -> a))

C'est exact, le truc fonctionne également sur les fonctions à plus d'un argument ! Ce qui nous permet de simplifier immédiatement

rotate n xs = (drop n xs) ++ (take n xs)

rotate = drop ++ take

Si ça c'est pas de la concision...

Lîlarfikod, "Patternglazed"

2010-01-25T21:09:00.000+01:00

Journal d'Ushat Olonkulal, Maire de Lîlarfikod - le 12e Hématite 214.

Une dizaine d'années se sont écoulées depuis le premier coup de pioche, porté dans le flanc de la montagne par l'un des septs vaillants nains fondateurs. Jadis hameau perdu au milieu des montagnes, Lîlarfikod est aujourd'hui une métropole florissante. le Duc Kandzudmeng en a fait sa capitale régionale, et une rumeur voudrait que la Reine Inod elle-même y considère l'installation de son palais d'hiver.

La situation extérieure est au beau fixe; le commerce avec les humains est plus lucratif que jamais, et les kobolds se terrent dans les montagnes après le massacre de leurs troupes pendant le dernier siège. Même ces pleurnichards d'elfes nous sont reconnaissants d'avoir limité l'abattage des arbres. Bah. Comme si le bois présentait un quelconque intérêt face a la pierre. Mais je m'égare.

Non, décidément, c'est la forteresse elle-même qui nous cause le plus d'inquiétude. Il y a six mois, l'équipe de minage sud-est, creusant à la poursuite d'une veine d'argent natif, détectait un secteur de roche anormalement humide. Quelques mètres de plus, et les vaillants mineurs exposaient une immense rivière souterraine, à la présence jusque la totalement insoupçonnée. Voici donc l'origine des rumeurs de monstres aquatiques hantant les sous-sols de cette région !

Suivant l'ouverture du tunnel, nous essuyâmes une attaque d'hommes-lézards armés jusqu'au dents. L'attaque couta la vie à deux de nos meilleurs soldats, noyés d'épuisement après avoir combattu a mains nues et étranglé une dizaine d'assaillants. Un brave maçon, au péril de sa vie, parvint à murer le dangereux orifice, scellant le péril hors du périmètre du fort.

Nos ingénieurs ayant estimé le tracé de la rivière, je démarrai immédiatement la construction de fortifications en différents points stratégique autour du cours d'eau, et y installai une troupe de nos meilleurs
arbalétriers. La rivière rougit bientôt du sang de nos ennemis tombés !

L'humidité de la rivière souterraine fertilise nos tunnels, et mes nains me signalent que des champignons Chapeaux-de-Tours poussent un peu partout. Ces champignons, en vieillissant, acquièrent la dureté et la texture du bois. Nous allons creuser une immense ferme souterraine et les y cultiver; voila qui dispensera nos bûcherons de s'exposer au soleil, et devrait par la même calmer les humeurs des bouffeurs de baies des bois.

Cette rivière nous apporte un deuxième avantage, celui de nous débarasser bien plus facilement de nos ordures. J'ai fait creuser une cheminée d'accès, descendant des niveaux principaux jusqu'au gouffre souterrain dans lequel se jette la rivière. Nos concitoyens peuvent maintenant évacuer leurs déchets sans s'aventurer dans les dangereux territoires extérieurs !

En revanche, toujours rien d'intéressant du côté de l'équipe de minage ouest, chargée d'explorer les veines d'obsidienne à la recherche de magma. En dix ans, nous n'avons pas trouvé une seule veine de houille dans la région, et notre industrie métallurgique dépend entièrement du charbon de bois, ce qui n'est pas pour plaire aux clowns aux oreilles pointues.

Les lubies du Duc nous causent également des ennuis. Ce fils de yack des montagnes a ordonné que la ville développe une industrie du verre, pour lui fournir de la vaisselle de luxe. Nous n'avons pas les ressources nécessaire pour en produire, et le temps que le message parviennent à nos voisins marchands, qui sait si le vieux fou n'aura pas perdu patience. La dernière fois que nous avons raté un délai (une commande fantaisiste de 12 armoires en electrum), il a condamné a mort l'artisan fautif, notre meilleur forgeron.

Notre meilleure chance reste de convaincre la Reine de venir s'installer dans notre forteresse, et prions qu'elle puisse modérer les excès d'autorité du Duc. Nous allons donc nous atteler à une tâche titanesque: percer la montagne de part en part, pour permettre aux caravanes de traverser en toute sécurité en évitant le dangereux col, propice aux embuscades gobelines. L'entrée du tunnel est terminée, mais nous devons terminer les fortifications intérieures avant de creuser le tunnel principal; sans quoi nos ennemis auront une voie royale pour contourner toutes nos défenses et nous envahir de l'intérieur.

Mais voila que la délégation diplomatique Elfe frappe à nos portes, et je me dois d'aller les acueillir. Encore une dure journée dans la vie d'un vieux bureaucrate nain...

Cluster Tricks: cycle reboot

2009-10-26T16:18:00.000+01:00

Au LACAL, nous avons récemment reçu notre nouveau cluster équipé d'Infiniband, qu'il a fallu mettre en place. Pour des raisons de convenance, rien n'est installé sur les disques des noeuds (qui servent uniquement au swap et au stockage temporaire), et le boot se fait via le réseau.

Problème 1: le BIOS est idiot - si le netboot échoue, la séquence de boot continue, puis s'arrête. Autrement dit, si un noeud tente de booter alors que le serveur est indisponible, il ne réessaie pas, il s'arrête. Ce qui serait absolument sans conséquence, s'il n'y avait le:

Problème 2: suite a un glitch administratif, nos noeuds ne sont pas équipés d'IPMI. Impossible donc de les redémarrer à distance.

Solution sympathique: puisque le disque local n'est pas utilisé pour booter, installons-y un système qui va redémarrer la machine. Il ne reste alors plus qu'a ajouter le disque à la fin de la séquence de boot, et le redémarrage sera automatique. Mais comment ?

Pour une opération aussi simple qu'un reboot, inutile de charger un système complet. On sait que, pour booter sur un disque, le BIOS vérifie d'abord la validité de la table de partitions, puis charge et exécute le code situé dans le MBR, soit le premier secteur du disque. Le code est exécuté en mode réel.

Jetons un coup d'oeil rapide dans la documentation de Linux. Elle nous apprend l'existence d'une technique primitive de redémarrage, utilisée en dernier ressort: le Triple-Fault.

Wikipedia contient une page à ce propos, et mentionne son utilisation par Linux. La technique consiste en "installer une table de vecteurs d'interruption vide, puis déclencher une interruption". Quelques recherches sur google indiquent que ceci se fait via l'instruction x86 LIDT. L'argument contient a la fois un pointeur vers la base de la table, et sa longeur; une valeur constante de 0 fonctionne pour créer une table vide.

Je crée donc un fichier reboot.asm:

lidt [0]
int 3

Que j'assemble simplement avec nasm:

max@node ~$ nasm reboot.asm
max@node ~$ hexdump reboot
0000000 010f 001e cd00 0003
0000007

Merveilleux. reste à écrire ce fragment dans le MBR de mon disque:

max@node ~ $ sudo dd if=reboot count=1 conv=notrunc of=/dev/sda

Presto !

Cluster Tricks: copie en masse

2009-10-01T17:27:00.005+02:00

Dans un cluster, la vitesse des disques ou du réseau peut être un facteur limitant critique pour la performance. Considérons le scénario suivant, qui a été rencontré en pratique au Lacal:

Une première phase de calcul est lancée sur chaque noeud, et produit plusieurs GB de données par noeud (stockées dans l'espace de travail sur le disque local)
Une deuxième phase de calcul est lancée, et elle a besoin de toutes les données précalculées sur tous les autres noeuds.

Les disques sont assez gros pour acueillir chacun une copie du dataset intermédiaire complet (quelques centaines de GB). Mais comment les distribuer efficacement ?

Evidemment, un bête SCP ferait l'affaire, mais il serait impensable de le lancer a la main entre les différentes machines suivant un ordonnancement précis (ou alors, trop emmerdant, et pas assez réutilisable).

Un bête scp de toutes les machines vers un noeud "principal", puis de ce noeud vers les autres, ferait aussi l'affaire. Mais terriblement lent.

Au moment ou je suis intervenu sur le problème, la copie sur un noeud maître avait déja été faite, mais le scp séquenciel était hors de question (trop lent).

Une première solution intéressante s'est révélée en Bittorrent. Les outils pour cela sont disponible dans portage (nous avons utilisé BitTornado, qui est un peu plus pratique que le client original "mainline" tout en étant très similaire d'utilisation). Une fois le hash initial accompli sur le noeud maitre (ce qui prend toutefois beaucoup de temps), la copie s'est faite relativement efficacement.

Mais on est encore très en dessous du maximum théorique, ce qui m'a amené a découvrir la solution idéale pour le job: uftp (http://www.tcnj.edu/~bush/uftp.html), un système ftp-like over udp, supportant le multicast.

Avec le multicast, chaque noeud peut envoyer un seul paquet de données au switch, le paquet sera répété sur toutes les interfaces (ou seulement sur les interfaces utiles si le switch gère le Multicast Snooping, ce qui n'était pas notre cas), et chaque machine pourra réceptionner le paquet simultanément, ce qui génère un gain très appréciable de vitesse (dans notre cas, vitesse de copie globale d'environ 400MB/s, au lieu des 6MB/s offerts par scp, et des 150MB/s offerts par bittorrent.)

L'utilisation est très simple, même si manquant un peu de flexibilité. Le recepteur est un daemon tournant sur chaque machine, qui stockera tous les fichiers reçus dans un répertoire public sur le disque local. L'émetteur est un client lancé par un utilisateur, qui prendra simplement un nom de fichier en argument.

Evidemment, ce système est totalement abusable et n'intègre absolument aucune sécurité. et ne doit être employé qu'a l'intérieur d'un réseau de confiance. L'ebuild est disponible ici (https://xolus.net/~max/uftp-ebuild.tar.gz) en attendant qu'elle fasse son chemin dans Sunrise.

Contrôler le crédit sur une carte SIM avec Nagios

2009-06-09T16:46:00.010+02:00

Il est inutile de présenter Nagios, un système de monitoring très populaire et flexible.

J'ai la chance d'avoir a disposition, depuis mon serveur Nagios, un modem GSM très pratique pour envoyer des SMS d'alerte en cas de problème sur un service quelconque. Pour l'envoi de SMS, j'utilise SMSTools, qui s'installe sous la forme d'un daemon prenant le contrôle
du modem, et d'un répertoire de spooling (/var/spool/sms) dans lequel on dépose les messages sortants, au format adéquat.

Pour rendre la chose plus facile, il existe également un script d'envoi simple (sendsms) qui a l'avantage d'éviter les problèmes classiques aux répertoires de spool (conditions de course, etc..). Nagios se configure très simplement pour envoyer des notifications:

define command{
command_name notify-host-sms
command_line /usr/local/sbin/sendsms $CONTACTPAGER$ "'Host $HOSTNAME$ is $HOSTSTATE$'"
}

define command{
command_name notify-service-sms
command_line /usr/local/sbin/sendsms $CONTACTPAGER$ "'Service $SERVICEDESC$ @ $HOSTALIAS$ is $SERVICESTATE$'"
}

C'est parfait, tout va bien. Mais la carte SIM installée dans le modem est une carte prépayée. Comment faire si le crédit sur cette carte s'épuise ? nous allons justement utiliser Nagios pour surveiller le crédit sur la carte, et émettre un avertissement s'il tombe trop bas.

Avec mon opérateur téléphonique, on peut contrôler son crédit restant depuis le téléphone, en entrant une commande de service au clavier: *130#. Le téléphone répond avec un message indiquant le crédit restant.

Quelques recherches sur google indiquent que ce type de commandes s'envoie au modem au moyen de la commande AT CUSD. On teste immédiatement avec minicom:

AT+CUSD=1,*130#,15
OK

+CUSD: 2,"Credit actuel: CHF -0,44; 25 SMS gratuits jusqu'au 01.10.2009",15

Reste a interagir correctement avec le modem, ce qui n'est pas totalement trivial a cause de quelques détails pratiques. J'utilise pour piloter le terminal un obscur outil appelé comgt, un équivalent de "chat" (le système de script utilisé par ppp) mais en plus flexible. Voila le script (a mettre dans /etc/comgt/credit):

set com 115200n81
set senddelay 0.05
send "AT+CUSD=1,*130#,15^m"
waitfor 60 "+CUSD:"
get 10 "^m" $s
print "Reply: ",$s,"\n"

On teste avec comgt:

gate # comgt -d /dev/ttyS0 credit
SIM ready
Waiting for Registration..(120 sec max)
Registered on Home network: "Swisscom"
Signal Quality: 21,99
Got: " 2,"Crdit actuel: CHF -0,44; Xtra-liberty: 25 SMS gratuits jusqu'au 01.11.2009.",15

Reste à traiter la sortie pour l'envoyer vers nagios (exercice pour le lecteur parce que je suis paresseux).

Gare au Hadophishing !

2009-05-25T10:45:00.002+02:00

J'ai discuté récemment avec un internaute français, téléchargeur occasionnel, qui était persuadé d'avoir reçu un mail d'avertissement Hadopi.

Le mail en question est arrivé sur la mailbox de son ISP, "contre-signé par la gendarmerie", et incluait des prétendues preuves sous la forme d'une liste de téléchargements avec dates et heures.

J'ai hésité un instant. Pour autant que je sache, l'infrastructure Hadopi est loin d'être opérationnelle, cet e-mail était donc selon toute vraisemblance une tentative de phishing.

Comment la liste de téléchargements a-elle été produite ? Etait-ce simplement une liste aléatoire de titres populaires ? Comment un phisher pourrait-il relier une liste de téléchargements à une mailbox d'ISP ? Il est sûrement assez facile de moissonner des adresses IP sur un réseau P2P public, mais le lien avec les mailboxes correspondantes ne devrait être connu de personne hormis l'ISP.

Faut-il donc voir une brèche de sécurité chez son ISP ? un employé mécontent aurait-il pu revendre ces informations à un phisher ? ou pire, l'attaque pourrait-elle directement émaner d'un insider ?

Tout ceci fait réfléchir aux implications du processus prévu par la loi Hadopi. Les mails de phishing de ce genre sont une deuxième attaque évidente contre ce processus (la première est l'envoi de plaintes arbitraires et invérifiables a l'encontre d'inconnus)

Threads perl avec Gentoo - Beware !

2008-04-10T23:18:00.003+02:00

Je viens de perdre deux bonnes heures avec un problème bien tordu.

A PolyLAN X, il semblerait que la cause du gros foirage de l'authentification soit dû non pas au dimensionnement du nombre de transactions autorisé, comme je l'ai d'abord pensé, mais au fait que l'interpréteur Perl n'était pas threadé, et que par conséquent un seul login simultané pouvait avoir lieu pour le serveur radius.

Après un "echo dev-lang/perl ithreads >>/etc/portage/package.use ; emerge perl", radiusd s'est retrouvé incapable de démarrer, se plaignant d'un symbole manquant dans le module rlm_perl.

Ré-emerger freeradius n'a bien entendu rien donné.

Le problème était qu'a la compilation, freeradius à utilisé les headers de perl pour compiler son module, mais au lancement, il se liait dynamiquement à la libperl. Sous Gentoo, l'interpréteur perl et la libperl sont deux packages séparés, et je n'avais pas réinstallé la libperl.

De manière générale, plein de problèmes de linking sont apparus. Ces problèmes auraient du être résolus par perl-cleaner; malheureusement, si perl threadé et non threadé sont considérées comme des versions différentes, avec des répertoires séparés pour les libs, perl-cleaner les considère comme une seule et même version, et ne déclenche pas la reconstruction par défaut. Il fallait donc utiliser "perl-cleaner allmodules" plutot que "perl-cleaner modules".

PolyLAN XI, Topologie Réseau

2008-03-30T21:35:00.003+02:00

Voici le plan pour la topologie du réseau PolyLAN XI (en admettant que nous recevions bien le 6248 à temps)

Places: 216

Couche Physique :

Au centre, le 6242 en haut du rack. Fifi, Riri, Loulou sur ports 1,2,3.
ports 27-48 trunkés par paires, donc 11 trunks (9 zones joueurs, 2 zones admin)
ports 4-26 pour serveurs de jeu.

Couche Ethernet :

Vlan 1: réseau de production. Vlan par défaut, untagged partout sauf ports 2 et 3
Vlan 10: réseau administratif. Tagged sur tous les trunks et sur port 1 (fifi)
Vlan 20: réseau passerelle vers internet. Untagged sur ports 2 et 3.

Couche IP:

Réseau administratif: 10.0.4.0/24 sur Vlan 10.
Fifi: 10.0.4.10

Réseau passerelle: 10.0.8.0/24 sur Vlan 20.
Core: 10.0.8.1
Adresse de routage flottante: 10.0.8.2
Loulou (primaire): 10.0.8.3
Riri (secours): 10.0.8.2

Réseau production: 10.0.0.0/22 sur Vlan 1
10.0.0.0/24 : Services réseau
10.0.0.1: Core
10.0.0.2: Fifi
10.0.1.0/24 : Serveurs & Admins
10.0.2.0/23 : Joueurs

Pfew.... un vrai jeu d'enfant, comparé à PolyLAN X :D

C'est pas demain que j'aurai ma license...

2008-03-30T13:51:00.001+02:00

... Vu que la personne qui s'occupe de ça a l'OFCOM a pris des vacances. Du coup, va falloir attendre encore un peu... frustration frustration

Diplôme, HAM-Radio, LACAL, Polylan

2008-03-11T21:34:00.006+01:00

Ca y est, je suis "Officiellement autorisé à porté le titre d'ingénieur en systèmes de communication", avec le petit papier qui va bien. Je ne suis donc plus un bon a rien d'étudiant, yesss !

Petite geulante contre l'administration de l'EPFL: c'est bien d'avoir une gestion automatique des droits, avec un bel annuaire LDAP et tout. Mais quand le lendemain de la réception de la jolie enveloppe, on se retrouve avec tous les accès physiques et une bonne partie des accès éléctroniques coupés, ça fait un peu l'effet d'un bon coup de pied au cul... et c'est pas franchement pratique pour finaliser les projets encore en cours.

Mercredi, j'ai passé l'examen de radio-amateur CEPT. J'attends de recevoir la concession. En attendant, j'ai fait l'acquisition d'un IC-271E en excellent état pour le 145MHz, et une antenne GP qui va avec. J'ai posé l'antenne sur le balcon du toit d'INJ en attendant de pouvoir faire mon premier QSO légal. J'ai aussi une superbe antenne magnétique pour la HF, qui venait avec un tuner automatique et SWR-mètre intégré. Malheureusement je n'ai pas (encore) de transceiver HF.

Je suis sur le point d'être engagé par le LACAL avec pour mission officielle de mettre en place le cluster de playstations. Nous avons gardé le front-end que j'avais configuré il y a trois mois, mis au point un schéma d'allocation d'adresses et de noms. Dans un premier temps, il n'y aura pas de scheduler, les noeuds seront directement accessibles en SSH depuis le front-end. Nous allons probablement acheter une meilleure machine pour le front-end, et reconvertir l'ancien en station de gestion réseau. Aujourd'hui, Dag Arne a enfin obtenu les droits administratifs de resp. technique du labo, ce qui nous à permis d'obtenir une adresse fixe pour ce foutu front-end. L'objectif est de pouvoir lancer les premiers calculs à la fin de la semaine prochaine.

PolyLAN XI aura lieu le w-end du 12-13 Avril, au hall du SG à l'EPFL. Ceci risque d'être ma dernière ou avant-dernière édition :( Grâce au soutien technique de Dell, nous allons pouvoir acquérir à prix préférentiel un superbe PC6248 tout neuf, ce qui couvrira nos besoins pour cette édition en terme d'interconnexions Gigabit. La performance niveau ARP devrait rester bonne puisque nous gardons un routeur matériel, et il n'y aura plus de trunk limitant au milieu qui coupe la salle en deux.

Yatta !

2008-02-01T13:41:00.000+01:00

Ca y est, j'ai rendu mon mémoire de master !

La défense aura lieu le 18 février. D'ici la, un peu de temps pour me reposer !

Accessoirement, comme une bonne nouvelle ne vient jamais seule: le papier dont je suis co-auteur (Parity-regular Steinhaus graphs) a été accepté par l'AMS et sera publié dans leur prochaine édition ! (détails ici)

EPFL::Restaurant

2008-01-16T23:48:00.000+01:00

Voici mon dernier gadget Perl, le module EPFL::Restaurant. Il permet d'accéder directement aux menus hebdomadaires sur http://restauration.epfl.ch. La doc POD explique sommairement son utilisation.

Dépendances: LWP, HTML::TableExtract

Sus aux "programmeurs d'entreprise" !

2008-01-11T11:04:00.000+01:00

Suivant une discussion plus ou moins aléatoire sur #scala/Freenode, j'ai suivi par hasard ce rant, qui m'a conduit à cet autre rant, sans compter celui-là. Amusant, suivant de près ce dernier lancé il y a peu de temps sur Slashdot.

Je n'ai absolument aucune compétence en Scala, n'ayant jamais rien programmé d'utile avec. Je n'en ai pas encore eu l'opportunité. Je n'ai donc pas d'intérêts particuliers à défendre Scala.

En revanche, je trouve absolument effarant et dramatique l'avis de ces prétendus programmeurs
, et reste béat devant l'absurdité et l'incohérence de leur discours. Par ou commencer ?

Le plus incroyable reste certainement celui qui prétend que les évolutions sophistiquées du langage Java le condamnent, que les génériques étaient une erreur monumentale, les casts étant un mécanisme bien plus naturel, et qu'il est hors de question d'y ajouter des fermetures, encore moins des horreurs fonctionnelles; que ces solutions sont bonnes uniquement pour des chercheurs isolés dans leur tour d'ivoire, mais que les "vrais programmeurs" qui travaillent sur des applications "business" n'en ont pas besoin.

Mais quelle sorte de programmeur prendrait donc une telle position ?? Ces gens seraient nés quelques dizaines d'années plus tôt, ils auraient été du lot qui défendait fermement le COBOL contre tous ces langages modernes bizarres et sans intérêts comme le C ou le Pascal... la récursion ? la programmation structurée ? baaah, ca sert a rien, c'est inutile, et le Lisp on en parle même pas..

Mon premier langage de programmation fut le Basic. Avec mes premiers pas d'autodidacte, j'ai produit quantité de code bancal et inélégant. Et au fur et a mesure que ce code expérimental boiteux s'accumulait, je commençais à identifier des problèmes récurrents.

J'ai découvert le Pascal, et la programmation structurée. Me suis-je dit "beeeeh, c'est compliqué, les gosub ca suffit, et la récursion ca s'émule avec des boucles quoi qu'on dise" ? certes non! Enfin, l'assurance d'un scope restreint, la fin de l'erreur de typo a la ligne 1642 qui plante le programme à la ligne 492...

J'ai découvert les pointeurs en C. Me suis-je dit: "beeeeh, c'est compliqué, c'est dur a comprendre, de toutes façons je peux tout faire avec des tableaux et des indices" ? certes non! enfin des noms cohérents pour des alternatives hétérogènes !

J'ai découvert Perl, premier contact avec les fermetures. Je ne savais même pas ce qu'était une fermeture. Pourtant, c'est grâce aux fermetures qu'une bonne partie du code perl faisant appel à des subs anonymes fonctionne correctement après un premier jet...

J'ai découvert Java. Après avoir travaillé sur plusieurs programmes relativement sophistiqués, j'ai mordu la poussière sur des erreurs de typage dynamique, je haïssais le système de types de Java et en particulier la technique hideuse du cast systèmatique pour utiliser une collection. Avec Java 5, j'ai découvert les génériques. Me suis-je dit: "beeeeh, les casts sont bien plus faciles, de toutes facons ces types sont juste un encombrement inutile ?" certes non ! les génériques me donnaient la garantie de l'absence d'erreurs de type dans mon programme, au prix de quelques modifications très intuitives.

J'ai découvert Haskell, le premier langage fonctionnel que j'ai utilisé sérieusement. Me suis-je dit: "baaah, les fonctions d'ordre supérieur, c'est inutile, c'est un passe-temps d'académique inutile dans la vraie vie ?" certes non ! j'abusais déja des map, grep et sort en Perl, et quel plaisir de pouvoir utiliser des callbacks sans définir une centaine de classes internes de 3 lignes, comme il est nécessaire de faire en java !

Que dire maintenant, des deux dirigeants d'AdaCore, qui se plaignent que l'enseignement de Java comme langage primaire dans les universités a été une terrible décision. Java "encouragerait les programmeurs a chercher des solutions toutes faites dans des librairies pré-existantes, plutôt que de développer ses propres routines plus performantes."

HELLOOO ? il me semble que l'immense majorité de la communauté s'accorde à dire que la performance était le problème de la dernière décennie; la loi de Moore n'a de loin pas l'air de s'essoufler, et les évolutions récentes des langages de programmation se font toutes dans la même direction: améliorer la ré-usabilité du code. Quel idiot choisirait de pénaliser un programmeur qui préfère chercher une solution standard, éprouvée, répandue, et optimisée par sélection naturelle, plutôt que de réinventer une roue octogonale chaque fois que l'occasion le permet ?

Ces gens m'énervent. ça m'énerve. Rhaaaah

Softs ham-radio

2007-12-10T22:12:00.000+01:00

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.

Bouton power sur un PowerMac G4 sous Gentoo

2007-11-19T16:12:00.000+01:00

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:

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).
Dumpkeys indique que la touche est reconnue comme touche de clavier "Do":

dumpkeys |grep 116
keycode 116 = Do

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

loadkeys - <<< 'keycode 116 = KeyboardSignal'

Configurons init pour intercepter ce KeyboardSignal et éteindre la machine, en ajoutant cette ligne dans /etc/inittab:

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

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

Screenshot PLT 0xA

2007-11-08T09:37:00.001+01:00

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

En direct du local PolyLAN...

2007-11-08T04:28:00.000+01:00

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)

OIDs de versions sur Dell PowerConnect

2007-11-05T21:24:00.000+01:00

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.

CaveShooter 0.3

2007-11-02T12:42:00.000+01:00

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 !

2007-11-02T01:43:00.000+01:00

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)

Du bon usage de /finally/

2007-11-01T09:48:00.000+01:00

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
}


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é.

Tests de VCS distribués

2007-10-29T22:37:00.000+01:00

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.

CaveShooter 0.2

2007-10-26T03:00:00.000+02:00

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

Configuration de l'équipement réseau

2007-10-24T17:34:00.000+02:00

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.

La structure réseau se met en place

2007-10-23T23:37:00.000+02:00

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.

SpaceShooter devient CaveShooter

2007-10-19T18:55:00.000+02:00

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.

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

2007-10-17T16:53:00.000+02:00

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.

Ouf

2007-10-16T11:12:00.000+02:00

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

2007-10-16T09:57:00.000+02:00

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.

Nouvelles de PolyLAN 0xA

2007-10-15T15:47:00.000+02:00

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

2007-10-15T15:05:00.000+02:00

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).