Geek, alcool et rock'n'roll

Il y a des problèmes avec la compilation de certains modules spécifiques à VMware. On obtient une erreur du type :

/tmp/vmware-root/modules/vmnet-only/vnetUserListener.c: In function ‘VNetUserListenerEventHandler’:
/tmp/vmware-root/modules/vmnet-only/vnetUserListener.c:240: error: ‘TASK_INTERRUPTIBLE’ undeclared (first use in this function)
/tmp/vmware-root/modules/vmnet-only/vnetUserListener.c:240: error: (Each undeclared identifier is reported only once
/tmp/vmware-root/modules/vmnet-only/vnetUserListener.c:240: error: for each function it appears in.)
/tmp/vmware-root/modules/vmnet-only/vnetUserListener.c: In function ‘VNetUserListenerRead’:
/tmp/vmware-root/modules/vmnet-only/vnetUserListener.c:282: error: ‘TASK_INTERRUPTIBLE’ undeclared (first use in this function)
/tmp/vmware-root/modules/vmnet-only/vnetUserListener.c:282: error: implicit declaration of function ‘signal_pending’
/tmp/vmware-root/modules/vmnet-only/vnetUserListener.c:282: error: implicit declaration of function ‘schedule’
make[4]: *** [/tmp/vmware-root/modules/vmnet-only/vnetUserListener.o] Erreur 1
make[3]: *** [_module_/tmp/vmware-root/modules/vmnet-only] Erreur 2

La méthode la plus simple pour le faire fonctionner, je l'ai trouvée sur un blog de geek. Je la recopie ici afin d'apporter un peu de pérennité, on sait jamais. Les deux dernières commandes sont à exécuter avec les droits root :

cd /tmp
tar xf /usr/lib/vmware/modules/source/vmnet.tar
tar xf /usr/lib/vmware/modules/source/vmci.tar

cd vmnet-only
sed -i "/vnetInt.h/ a\#include \"compat_sched.h\"" vnetUserListener.c

cd ../vmci-only/include
sed -i "/compat_page.h/ a\#include \"compat_sched.h\"" pgtbl.h

cd /tmp
tar cf /usr/lib/vmware/modules/source/vmnet.tar vmnet-only
tar cf /usr/lib/vmware/modules/source/vmci.tar vmci-only

Il suffit ensuite de redémarrer vmplayer (ou vmware si c'est Workstation) et leur appli se charge de recompiler les modules si elle ne les trouve pas.

(Yes, I know that's GNU/Linux, but my title was already too long :-) ) Translation of my last post in english. Hope it will be readable :-)

Dell publishes all BIOS firmwares as a Windows .EXE. When we try naively to execute it using Wine, Wine stops because the exe tries to flash the firmware using direct access to the hardware... which doesn't work with Wine.

The solution is to use dellBiosUpdate, which ships with the Debian package libsmbios-bin:

aptitude install libsmbios-bin

This tool needs 2 things : the bios firmware in HDR format, and the kernel module dell_rbu to do the update. For this last part, it's easy on a normal Debian (read: with a Debian kernel):

modprobe dell_rbu

For the HDR file, I tried during 2 hours... and indeed it was very easy (please replace the filename by the actual filename):

wine E6400A19.EXE -writehdrfile

Yes, Dell's .EXE knows how to write the HDR file !

Now, you can execute dellBiosUpdate :

dellBiosUpdate -f ./E6400A19.hdr -u

And reboot !

Please note that if you don't use Debian, Dell has some easy setup to update the BIOS firmware under Linux. It seems to work on RPM distributions, and also in Ubuntu. I tried to make it work with Debian, I think I successed but the repository seems to contain rather old firmwares. Maybe I'll try to help them make it work with Debian :-)

J'ai décidé hier de mettre à jour la Debian de mon PC du boulot.

Globalement, ça s'est bien passé. Il y a eu cependant deux problèmes majeurs : VMWare ne se lance plus, et j'en parlerai dans un autre billet si j'arrive à résoudre le problème, et Eclipse me retournait un joli "network unreachable" dès que j'essayais d'accéder au gestionnaire des plug-ins.

J'ai d'abord réalisé un petit programme Java, pour vérifier que c'était bien tout Java qui était concerné :

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLConnection;

public class TestReseau {
	public static void main(String[] args) throws MalformedURLException,
			IOException {
		URLConnection connection = new URL("http://www.google.fr")
				.openConnection();
		BufferedReader reader = new BufferedReader(new InputStreamReader(
				connection.getInputStream()));

		StringBuilder sb = new StringBuilder();
		String line;

		while ((line = reader.readLine()) != null) {
			sb.append(line + '\n');
		}

		System.out.println(sb.toString());
	}
}

Et, oui, que ce soit avec Java 5, Java 6, ou OpenJDK, le même problème apparaissait.

Une recherche rapide m'a amené sur le bug tracker Debian, avec la solution :

• modifier /etc/sysctl.d/bindv6only.conf, nouveau fichier amené par la version 4.38 de netbase,
• changer la valeur de net.ipv6.bindv6only vers 0,
• et recharger procps par /etc/init.d/procps restart.

C'est très pénible de perdre une heure sur des changements silencieux comme ça, mais au moins, j'ai trouvé la solution... pas comme avec VMWare.

Mise à jour : il y a eu aussi un ptit bug avec Eclipse avec un GTK récent. Rapidement résolu en utilisant la variable d'environnement préconisée : GDK_NATIVE_WINDOWS=1. Le problème était que les contrôles ne répondaient pas toujours correctement (genre les boutons-poussoirs restaient appuyés quand on cliquait dessus, sans produire d'effet).

Oui, c'est un peu ce qui est arrivé sur nos machines du boulot.

On a du vieux Redhat Enterprise Linux 4, qui vient avec un vieux noyau 2.6.9 patché jusqu'au cou^[1].

Et voilà, ce bon vieux noyau contenait un mécanisme appelé l'OOM killer. Ce mécanisme permet, lorsqu'il n'y a plus de mémoire vive disponible, de tuer le "meilleur" processus afin de récupérer de la mémoire vive.

En soi, c'est plutôt louable. Mais voilà, vous vous en doutez, c'est bien la définition de "meilleur" qui pêche ! En l'occurence, c'étaient les processus serveurs. Gênant.

C'est tout simple :

echo “- - -” > /sys/class/scsi_host/hostH/scan

Il faut évidemment remplacer H par un numéro, généralement 0 lorsqu'on n'a qu'un bus SCSI.

Avec cette commande, on détecte donc les devices SCSI qui ont été ajoutés depuis le dernier scan du bus... utile lorsqu'on ajoute un disque dynamiquement dans une VM gérée par VMWare (ou autres (?)).

On peut vérifier la détection avec la commande dmesg :

SCSI device sdb: 20971520 512-byte hdwr sectors (10737 MB)
sdb: cache data unavailable
sdb: assuming drive cache: write through
 sdb: unknown partition table
Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0

(oui, c'est un aide-mémoire... mais qui sait, ça peut servir à d'autres ?)

Trouvé sur le site d'IBM, où se trouvent aussi d'autres commandes qui peuvent servir.

Au menu, un petit problème qui m'a embêté aujourd'hui. Ça pourra paraître bateau à pas mal de gens, mais j'ai bien dû chercher une heure avant de trouver la solution par moi-même, car Google ne m'aidait pas trop. J'espère que ça servira donc à quelqu'un.

Le problème

J'avais une vieille installation de OpenLDAP sur une machine, installé et configuré automatiquement par les outils Debian.

Si je ne me trompe pas, ces outils installent une base sécurisée, dans le sens où le mot de passe admin n'est stocké en clair nulle part. Ils le demandent à l'installation (avec le Bind DN associé), l'insèrent dans le référentiel, et configurent le fichier slapd.conf pour autoriser ce Bind DN à écrire partout.

Me voilà bien embêté, 2 ans après, pour accéder à ce Bind DN ! Les mots de passe par défaut habituels y sont tous passés: password, secret, admin... Rien n'y fait.

La manière brute

Le premier essai, naïf, a consisté à accéder au référentiel directement. Un ptit coup de slapcat permet de récupérer l'intégralité du contenu du référentiel. Là, on a, pour notre DN, un champ userPassword, qui ressemble à ça :

userPassword:: e01ENX1BjhU4KiFacVhpaT0oKYDeRTNuQ3p3PT0=

(Note: je l'ai modifié, ce n'est sans doute plus quelque chose qui veut dire quelque chose).

Ce champ est encodé en Base64, pour le décoder j'ai utilisé l'outil base64 de la manière suivante :

echo 'e01ENX1BjhU4KiFacVhpaT0oKYDeRTNuQ3p3PT0=' | base64 -d

Cela a retourné la chaîne {crypt}AT35SkUje86dKL7KE3nCzw== (ou quelque chose approchant, j'avoue que je triche).

Zut, une chaîne hashée... J'aurais dû m'y attendre ! Je me suis donc fait un petit fichier passwd-like contenant une ligne :

admin:AT35SkUje86dKL7KE3nCzw

Et j'ai lancé l'excellent logiciel de crackage de mot de passesécurité john :

john passwd

Après quelques minutes de crackage intensif, john ne m'a rien trouvé. J'avais utilisé un mot de passe à peu près sécurisé. J'ai donc utilisé mon cerveau pour changer directement le mot de passe.

La manière douce

C'est en fait beaucoup plus simple. On peut définir un DN root avec un mot de passe associé dans le fichier de configuration du serveur OpenLDAP. C'est d'ailleurs ce qui est indiqué souvent dans les divers HOWTO.

C'est donc ce que j'ai fait; j'ai ajouté les lignes suivantes à l'endroit opportun de mon fichier /etc/ldap/slapd.conf:

rootdn "cn=root,dc=monbeaudomaine,dc=fr"
rootpw monbeausapin

Puis j'ai redémarré slapd, je me suis connecté sur le référentiel en utilisant ces informations, et j'ai pu changer le mot de passe de mon DN admin précédent. Je me suis ensuite empressé de commenter ces deux lignes puis de redémarrer à nouveau slapd.

Depuis que j'avais mis à jour ma Debian, la souris ne fonctionnait plus correctement dans mon VMWare Windows que j'utilise pour accéder aux applications spécifiques du boulot. En effet, elle n'affectait plus la VM guest, donc je n'arrivais plus à contrôler le système.

J'ai trouvé la solution sur un blog anglophone: il suffit de lancer, à la place de vmplayer :

VMWARE_USE_SHIPPED_GTK=yes vmplayer

et voilà :)

Certains le savent peut-être déjà, mais un gros trou de sécurité affecte Adobe Flash. Sauf cas particulier, il est à peu près sûr que vous ayiez ce logiciel installé (c'est celui qui permet de lire les vidéos sur Youtube et la quasi totalité des des sites de vidéo^[1]). Donc, vous êtes mal, car il n'y a pas encore de correctif sorti par Adobe, prévu pour jeudi et vendredi. Et puis, ah oui, j'oubliais, des exploitations du bug sont déjà en ligne sur Internet. Bref, vous êtes mal.

A partir de là, il y a deux solutions :

• désactiver Flash tant qu'il n'y a pas de correctif de la part d'Adobe. Dans Firefox 3 (ou 3.5), ça se fait dans "Outils/Modules complémentaires", et il faut aller dans l'onglet "Plugins'". Là, on peut désactiver le plug-in Adobe Flash. Par contre, il sera désactivé pour tous les sites, et il faudra le réactiver à nouveau après le correctif d'Adobe.
• installer l'excellente extension Firefox NoScript, installable directement depuis "Outils/Modules complémentaires".

L'extension NoScript désactive tout contenu actif (Javascript, Flash, Silverlight) par défaut, et vous permet de l'activer site par site. Ainsi, aucun risque de se choper du code qui viendrait d'un site non connu.

Il faut savoir en effet que, bien souvent, même les sites corrompus (c'est-à-dire les sites où vous auriez l'habitude d'aller, mais qui se seraient fait pirater pour pouvoir ajouter l'exploitation du bug) font référence au script d'exploitation depuis un serveur distant. En fait, avec NoScript, la seule possibilité de ne pas être protégé est si un site que vous avez autorisé se retrouve complètement piraté. Je ne vais pas vous mentir, ça peut arriver.

Bon, en plus, en définissant précisément les domaines de confiance, cela vous permet de pas donner vos informations à n'importe qui, et de véritablement contrôler ce qui est exécuté chez vous. Et donc, vous seriez aussi un peu mieux protégé contre les problèmes de sécurité à venir.

Bref, NoScript, c'est bon, mangez-en :-)

Puisque le firmware n'est pas téléchargeable sur le site, je ne sais pourquoi, je le propose ici. Je l'ai récupéré via un autre site et je peux assurer qu'il fonctionne...

On sait jamais, ça pourrait être utile :-)

Ça y est, j'ai craqué et j'ai acheté un linker DS. J'ai choisi l'iTouch DS notamment après avoir lu ce forum qui en parle bien et la petite phrase "Vu son prix et ses fonctions il surpasse des linkers plus cher en particulier le cyclo DS Evolution qui est plus cher et n'inclu que le realtime guide en plus."

L'intérêt principal pour moi, c'est de pouvoir mettre des émulateurs :

• Lameboy comme émulateur GameBoy ! À moi l'excellent Zelda Gameboy et le non moins excellent Mario !
• NesDS comme émulateur NES
• J'ai cru voir passer aussi des émulateurs Megadrive, Game gear, Super NES, Master system...
• ScummVM !

Mais je pense continuer à acheter mes jeux DS...

Pour ceux qui seraient intéressés, j'ai acheté le iTouch DS chez Tech Wizad, une boîte anglaise (vu le prix de la livre en ce moment...), et une carte mémoire chez Amazon.

À suivre pour vous raconter comment ça marche :-)