devloop :: blog

Comme je suis de près les différentes build de la version d'Opera 10 à venir, je ne pouvais pas échapper au buzz concernant Opera Unite.

J'ai donc mis en service ma page depuis quelques temps déjà et ait eu l'occasion de tester les différents services proposés en standard.

J'ai d'abord rencontré des problèmes pour que la page soit accessible. Bien que l'utilisation de UPnP soit activée dans Opera et sur le routeur, ce dernier ne semblait pas recevoir la moindre demande de port. J'ai donc du NATer moi même le port 8840 pour recevoir les connexions. Il est possible que cela soit corrigé depuis, je n'ai pas réessayé la configuration depuis la première build.

Le Fridge qui permet de laisser des mémos affichés sous la forme de post-it et le Lounge qui est un salon de discussion très sommaire sont plus des gadgets à mes yeux et je les ais désactivé assez tôt. A noter que pour le Loundge je n'ai pas retrouvé dans les dossiers de cache Opera les conversations ce qui est un bon point question vie privée ("privacy"). Bien sûr les données sont transférées en clair sur le réseau et non protégées par SSl/TLS.

Le système de galerie photo et le service faisant office de serveur web sont plutôt sympathiques et permettent à des personnes souhaitant créer un site Internet de le faire facilement et de disposer d'un nom de domaine pour pas un rond
Evidemment on se limite à des pages statiques, il n'est pas question de faire exécuter du PHP ou CGI.

Pour le peu que j'ai regardé niveau sécurité, je n'ai rien remarqué de mauvais. Les cookies ne sont pas définis sur un sous-domaine global mais bien le domaine exact pour la "domiciliation" de l'utilisateur (home, work etc) et l'administration se fait par le protocole spécial unite:// (donc pas d'attaques du type CSRF)

J'ai eu plus de difficultés à faire fonctionner le Media Player mais le problème venait en fait de FlashBlock pour Opera qui cassait l'affichage des pages
Une fois corrigé, les flux passent bien et on ne sent pas les connexions passer depuis la navigateur (évidemment c'est selon le nombre de personnes connectées).

Quand au système File Sharing, il permet à chacun de mettre très simplement à disposition des fichiers. On regrette bien sûr de ne pas pouvoir spécifier plusieurs dossiers de partage.
Les transferts semblent se faire sans problème. Lors d'un test on a même pû transférer un fichier d'environ 700Mo... en revanche ce transfert utilisait la totalité de la bande passsante en upload Opera semble avoir rectifié le coup avec la dernière build en date.

Pour ce qui est des autorisations d'accès, c'est pour le moins simple : ressources publiques, protégées par un mot de passe ou privées (seul vous y accèder).
Un système permettant d'uploader des fichiers vers son ordinateur pourrait aussi être sympathique (transfert de fichier dans les deux sens)

En revanche le système dans sa totalité n'est par parfait et il arrive que l'on doive relancer Opera pour refaire fonctionner les services qui ne répondent plus.
J'aime vraiment la possibilité que le service offre à chacun (même des "non-initiés") de pouvoir mettre en place et gérer soit même un petit espace sur Internet

J'ai beau aimer Linux et dire régulièrement du mal de Windows (la gestion des fenêtres est tout simplement exaspérante face à un bon KDE), j'admets tout de même volontier que Linux est aussi sujet à des plantages.
MAIS quand ça survient sous Linux, on se dit qu'il y a une bonne raison et que surtout il y a une façon de trouver quelle en est la cause et d'agir pour que ça ne se reproduise plus. C'est tout l'avantage d'un système open-source face à un système propriétaire où l'on peut juste... subir et espérer que les devs découvrent puis décident finalement de corriger le problème

Je ne sais plus exactement depuis combien de temps j'ai ce souci mais ça fait un bail... en fait probablement depuis que j'ai Shirley
Le symptôme est toujours le même : tout d'un coup le disque dur se met à gratter et les commandes ne répondent plus. Seul le curseur de la souris est d'accord pour réagir (par intermittence). Si on est suffisamment rapide (c'est rare), on peut parvenir à fermer les applications et éviter le pire.
Le pire (qui est tout de même loin d'être l'enfer mais très énervant) c'est que le système reste inutilisable et gratte pendant un bon moment. Ca peut durer jusqu'à une demi-heure dans mon cas.
Ce comportement est typique d'un programme quelconque qui explose son utilisation mémoire et, une fois la RAM complètement utilisée, s'attaque à la SWAP (d'où l'utilisation intensive du disque dur)

Si on est patient, tout se termine "bien". Le kernel s'est chargé de tuer toutes applications graphiques, le WM et Xorg inclus (bref la crémerie avec la crémière et ses yaourts) et on est bon pour se relogger.
Quelques minutes plus tôt on s'acharnait à faire des Ctrl+Alt+F1 dans l'espoir de pouvoir régler nous même le problème.

Il est très difficile de déterminer quel programme est à l'origine du plantage... surtout quand on a toujours les même programmes ouverts
Longtemps j'ai soupçonné le "operapluginwrap" qui est le programme qui gère les plugins sous Opera. Son utilisation du CPU grimpe en flèche dès que l'on tombe sur du Flash (d'où l'utilité d'un FlashBlocker pour limiter les dégats).

Au même titre, j'ai soupçonné Vuze (client BitTorrent développé en Java), ce qui m'a poussé à passer à Deluge récemment.
Mais si on suit la logique, le souci pourrait aussi bien être lié à Firefox (souvent ouvert aussi) ou des daemons (mysqld, apache, tor...)

Malgré le passage à Deluge, le souci est réapparu. Je suis donc allé fouiller dans les logs
La dernière fois j'avais vu des appels à un programme nommé "kwin_killer_helper", sorte de soupape de sécurité de KDE qui tente de fermer des programmes quand ça part en sucettes... seulement son action a l'air peut efficace est surtout l'application n'est pas configurable

Cette fois j'ai remarqué des références à "oom-killer". Il agit de la même façon que kwin_killer_helper mais au niveau du noyau.
Le problème c'est qu'il semble reporter seulement le programme qui fait déborder le vase or ce n'est pas forcément celui qui s'est chargé de le remplir à 99%... toutefois en faisant des statistiques, on peut en déduire les programmes qui sont plus gourmants que les autres.

Ainsi un grep sur /var/log/messages me donne 9 "java invoked oom-killer", 1 pour opera, 1 pour policykit-kde et le dernier en date pour klipper
Le bon côté c'est qu'en abandonnant Vuze le problème apparait moins souvent mais il reste toujours présent

Si je regarde dans les logs plus anciens (archivés par logrotate), on retrouve java mais sont aussi mis en cause hald-addon-stor et mysqld

Si on effectue des recherches sur Google, on retrouve tous un tas de programmes variés qui ont "invoqué" oom-killer dont certains sont réputés stables.
Le souci semble donc venir d'ailleurs.

Pour certains, le souci est lié à la taille de la SWAP... il faudrait qu'elle soit au moins de la taille de la RAM. Je ne dirais pas que je n'y crois pas une seconde... mais presque (va pour deux secondes d'incrédulité )
Pour d'autres là (et sans doute plus fiables) et ici, ce serait lié à l'utilisation d'un système 32bits avec une machine 64bits (ce qui est mon cas).
Je vais probablement suivre la seconde possibilité mais je ne compte pas réinstaller mon système pour le moment (j'attends la version 11.2 d'openSUSE)

Pour le moment j'ai vu ici que chaque processus a dans /proc/ des fichiers oom_adj et oom_score dont il serait peut-être bon de connaître l'utilité
Et enfin un comique a enregistré le domaine oomkill.net sur lequel ont peut lire le boût de kernel correspondant à ce tueur de gaspilleurs de mémoire (oom = "Out Of Memory")

Après le cookie dumper, voici le "cache dumper" qui comme son nom l'indique permet d'analyser le cache du navigateur Opera.

Sous Opera, on trouve deux dossiers de cache.
L'un s'appelle "opcache" et sert uniquement aux sites liés à Opera lui-même comme les requêtes à destination du "sitecheck" (système anti-fishing du navigateur), les requêtes vers DragonFly (API pour développeurs web intégré au navigateur) et requêtes vers les autres sous-domaines d'Opera.
Le second dossier est le dossier "cache4" et conserve la grande majorité des fichiers gardés en mémoire par Opera.

Dans les deux cas, les fichiers mis en cache sont renommés sous la forme oprXXXXX (où "XXXXX" est composé de chiffres et lettres majuscules) et un fichier nommé "dcache4.url" présent dans le même dossier est un index qui garde les informations spécifiques à chacun des fichiers.

Il est important de noter que si vous avez coché "Empty on exit" dans les préférences, Opera n'utilisera pas le fichier d'index mais stockera tout de même des fichiers en cache. Les associations entre les fichiers présents dans le cache et les sites Internet correspondants sont alors impossible à déterminer (Opera garde ces associations en mémoire mais ne les écrit pas sur le disque).

Comme pour l'analyse du fichier cookies4.dat la dernière fois, j'ai rencontré certains tags non documentés dans la documentation officielle.
On peut par exemple trouver le tag 0x00 dont la valeur est toujours la même (0x8000000B) et qui ne semble pas avoir de signification
Il y a un tag 0x2e qui représente la langue utilisée pour un fichier de cache donné (par exemple "fr_FR").
Tout aussi énigmatique, le tag 0x3a qui me semble lié à l'entête HTTP "Age" reçu comme réponse des serveurs. Un entête qui m'était inconnu et qui m'a fait penser au ver Conficker qui se base sur un autre entête HTTP pour déterminer la date et l'heure actuelle. Le header "Age" semble renvoyer une valeur numérique dans une intervalle prédéfinie et augmente avec le temps... ça pourrait être pratique comme moyen de trouver un nombre aléatoire

Enfin on trouve des tags qui permettent au navigateur d'intégrer directement des entêtes HTTP et leurs valeurs dans l'index de cache. Le tag racine est le 0x3b, suivi par le 0x3c. Le 0x3d défini le nom de l'entête et le tag 0x3e sa valeur.

Le programme que j'ai fait prend comme argument le chemin vers le fichier dcache4.url ainsi qu'un dossier où sera placé l'analyse du cache. Si ce dernier dossier n'existe pas, il est créé automatiquement.
Pour chaque fichier référencé dans le cache, le programme détermine sa nature à partir de sa valeur "mime" (image/png, text/html, application/x-javascript, etc) et s'il est compressé ("Content-Encoding" défini par le tag 0x20). Si c'est le cas, le fichier est décompressé (si possible car certains fichiers sont compressés en deflate et non par gzip ) avant d'être copiée dans le dossier de destination.
Le programme génère ensuite un fichier HTML qui permet d'afficher facilement l'ensemble des fichiers du cache et leurs métadonnées associées. S'il s'agit d'une image, elle est affichée. Sinon un lien permet d'accèder à la ressource. Les javascripts et codes html ont l'extension txt pour éviter qu'ils soient interprétés.

Comme les descriptions et les images sont chargées dans la même page HTML, ça peut prendre du temps à charger en fonction du cache analysé (il faut mieux un système avec une bonne mémoire )
Le résultat ressemble à ça (extrait) :

Le code est ici : opcadump.py

Le présent blog se veut être une copie de l'original.
Deux raisons m'ont poussé à la création de ce site "miroir" :

• Les problèmes de disponibilité de l'original qui surviennent de temps à autre. Certes à ce que j'ai pû constater, My Opera n'est pas un champion de l'uptime et la plate-forme est régulièrement "en travaux". Mais avec deux emplacements sur le web, ça ne devrait pas poser de problème.
  
• Le nombre important d'images hébergées en externe sur l'original (imageshack, xs.to) qui risque de faire mal si l'un de ces serveurs ferme ses portes. En copiant les articles sur My.Opera, j'en profite pour y placer les images du blog et les serveurs ont au moins une bonne bande passante
  

Je suis loin d'avoir tout recopié (il me reste encore plus de 240 articles ) mais j'ouvre dès à présent ce miroir au public

Ce billet est une actualisation d'un ancien billet (juin 2005 ) qui expliquait brièvement comment profiter des vidéos que l'on peut voir sur le net à l'aide de mozplugger.

Ici on va voir comment installer Gecko Media Player, un plugin basé sur MPlayer et qui fonctionne avec Opera
La procédure concerne une installation sur openSUSE 10.3 mais peut être adaptée (avec plus ou moins de facilité) pour fonctionner avec votre distribution (les plus chanceux seront peut-être les utilisateurs de Fedora pour qui des paquets sont disponibles).

Avant toute chose il vous faut GNOME MPlayer, un frontend (interface graphique) pour MPlayer qui comme son nom l'indique se base sur le bureau GNOME. Le logiciel n'offre pas grandes fonctionnalités comparé à un SMPlayer ou un GMPlayer mais il est développé par le même développeur que le plugin que l'on veut installer et qui y fera appel depuis le navigateur, donc indispensable.

On a la chance d'avoir un paquet pour le player sur le dépôt PackMan. Rajoutez le dépôt par YaST si vous ne l'avez pas déjà chez vous puis installez le logiciel.

Vous aurez ensuite besoin de différents logiciels et leurs fichiers de développement pour la compilation du plugin.
Il vous faudra récupérer mozilla-xulrunner181 et mozilla-xulrunner181-devel correspondant au SDK Mozilla et offrant la commande xpidl appelée lors de la compilation. Ces deux paquets sont sur le dépôt OSS d'openSUSE.

Reste encore les paquets dbus-1-glib, dbus-1-glib-devel, gconf2 et gconf2-devel qui sont tous présents sur le dépôts standard comme les deux précédents.

Vous pouvez maintenant télécharger la dernière version de Gecko Media Player (0.5.4 à l'heure de ces lignes), décompresser l'archive et lancer l'installation avec un classique :

./configure
make
make install

L'installation du plugin s'effectuant par défaut dans un répertoire où Opera ne vient pas fouiller, il faudra ajouter le répertoire "/usr/local/lib/mozilla/plugins" dans votre configuration en suivant Tools > Preferences > Advanced > Content > Plug-in Options > Change Path.
Chez moi ça ressemble à ça :

L'ordre d'appel des plugins peut-être très important si vous utilisez différents plugins qui gérent le même type de données. Personnellement je fait passer Gecko Media Player avant les autres.
Une fois la configuration terminée, fermez le navigateur puis rouvrez-le. Vous pouvez visiter cette page qui permet de tester tous un tas de formats vidéos et audios ou encore aller regarder le trailer d'Iron Man au format QuickTime sur le site d'Apple pour vérifier que ça fonctionne.
La présence du plugin peut être repérée à la barre de lecture grise qui est ajoutée au bas de la vidéo :

Vous aurez peut-être une mauvaise qualité d'image ou de son. Il faut si c'est le cas modifier les sorties utilisées par défaut en lançant "gnome-mplayer" puis refaire des essais

Si vous ne souhaitez utiliser Gecko Media Player que pour certains formats et que vous disposez d'un autre plugin prenant le format en charge, vous pouvez pour chaque type mime définir quel plugin utiliser.
Pour cela, rendez-vous dans l'onglet Avancé comme la dernière fois puis sélectionner la catégorie "Downloads". Sélectionnez le type mime qui vous intéresse, faites "Edit" et prennez le bon plugin dans la liste "Use plug-in".

Morale de l'histoire : Avec un Gecko GNOME dans votre Opera, vous n'avez rien à envier aux pandas rouges