devloop :: blog

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

... si vous vous intéressez à la sécurité informatique et tout ce qui transite autour.

Général
SecuriTeam blogs
ARBOR SERT (beaucoup de bonnes surprises )
Security Samizdat (un tas de liens vers des trucs sympa... par contre fait ramer Opera )
Websense Security Labs Blog
Didier Stevens
Uwe Hermann | A slightly paranoid Debian developer (traite aussi de l'informatique en général)

Computer forensics
Windows Incident Response
Blog de Lexfo (principalement inforensique mais d'autres sujets sont aussi traités)
Le live forensique est un sport de combat comme un autre

Kernel, exploitation, programmation et ASM
SF-Freedom : Exploitation Technique and Information Security
Blog d'Ivanlef0u (pour les fanatiques de Windows)
gnurbs : In the name of zero (si tu aimes le langage assembleur tape dans tes mains)

Vulnérabilités web
ha.ckers : le blog de Rsnake

Malwares
F-Secure Weblog : News from the Lab
McAfee Avert Labs Blog
Symantec Security Response Weblog

Cyber : vie privée, surveillance, DRMs etc
Freedom to Tinker
Schneier on Security
La Sécurisphère

et puis bien sûr devloop :: blog

Une semaine (ou presque) sans billets (oups) même si certains sujets ont été assez actifs au niveau des commentaires.
J'ai pas mal taffé ce mois çi (malheureusement rien à voir avec l'informatique) et j'étais bien trop crevé pour faire quoi que ce soit, en plus j'étais pas dans ma blog mood, pas aware quoi

Comme d'habitude j'ai testé tout un tas de logiciels, pas mal de softs de stéganographie, des bons, des moins bons, des facilement compilables, d'autres impossibles à compiler (en fait pour ceux là les tests s'arrêtent avant d'avoir pû essayer le soft), open-source, closed-source, actifs, abandonnés, erreurs 404, host unreachable etc (oui j'ai fouillé).
Dans l'ensemble je cherchais un logiciel de stegano permettant de dissimuler quelques méga-octets dans un fichier et qui soit open-source et fonctionnant sous Linux (encore mieux s'il fonctionne aussi sous Windows). Mais peu de surprises : la quasi-totalité ne permettent de cacher au maximum que quelques kilo-octets.

J'ai donc décidé de voir plus gros au niveau du format conteneur. J'ai découvert isosteg qui comme son nom l'indique permet de cacher des données dans une image ISO.
L'exemple donné sur le site d'isosteg semblait prometteur : pouvoir dissimuler 3Mo dans une image iso de 674Mo, super !
Seulement cet exemple est bien optimiste par rapport aux tests que j'ai effectué :

ubuntu-6.06-desktop-i386.iso (Ubuntu Live CD) 698Mo -> 292Ko
grml_0.8.iso (le dernier GRML) 697Mo -> 40Ko
trustix-2.2-200608031721.i586.iso (Trustix Sunchild) 444Mo -> 117Ko
MomongaLinux3-i686-dvd.iso (Momonga Linux... que je compte tester un jour) 3.6Go -> 127Ko

Visiblement il faut de sacrées chances pour tomber sur le bon ISO

J'ai essayé le système d'exploitation Syllable (par VMWare) sur lequel je n'ai rien à redire : tout semble fonctionner, ensuite c'est les goûts et les couleurs

Je viens tout juste d'essayer SIM-IM (SIM Instant Messenger), un logiciel de messagerie instantané multi-protocole qui n'a pas grand chose à envier à Gaim. Ajouté à ça un module permet d'encrypter au vol les conversations avec GPG

Il existe une version open-source de ce que fait spammimic, développé par un membre de CyberArmy et téléchargeable ici. Il s'agit d'un CGI en perl. Pour des raisons qui m'échappent encore je n'ai pas réussi à le faire fonctionner sous Apache.

J'ai de la nouvelle lecture. il me faudra beaucoup de temps avant que j'arrive à lire les (presque) 1000 pages du livre, déjà que je n'ai toujours pas fini le livre de Bruce. Je suis seulement au tout début de ce livre sur Linux mais il semble très bien écrit et assez accessible (nécessite tout de même d'être un utilisateur de Linux et d'avoir des bonnes connaissances en C)

Google a soufflé ses 8 bougies il y a quelques jours. Les projets de la société laissent parfois songeur, la vie privée des internautes est de plus en plus couverte par ce géant de l'Internet. Ce n'est pas une mauvaise chose de bloquer les cookies venant des moteurs de recherche.

L'affaire AOL est un bon exemple des dérives provoquées par la surveillance continue des Internautes. Le site Futura-Sciences a écrit un très bon article sur cette histoire.


Je farfouillais dans les bacs à disques et j'ai eu l'immense plaisir de découvrir un nouvel album des Stranglers, que je croyais disparu depuis belle lurette (en fait ils ont sorti un album en 2004 après 6 ans d'absence).
Les Stranglers ont marqué à tout jamais l'histoire du Punk. Les gens connaissent généralement peu ce style musical qui offre en réalité une palette assez large, réduisant le punk au hardcore, au punk rock. La confusion a été totale à une époque où les mauvaises langues disaient que le punk était mort. En fait il a simplement explosé en autant de dérivés que la Oï, le punk-hardcore, la new wave, le grunge et que sais-je encore
Les Stranglers ne font pas du punk harcore, ils ont un côté pop bien à eu qui leur a permis de toucher un public bien plus large et de faire quelques tubes (vous avez sans doute déjà entendu Always The Sun). Contrairement aux Rezillos, leur côté pop est loin d'être festif. Il y a dans leur musique quelque chose de dérangeant (et dérangé), une touche vraiment artistique, ce même art que l'on retrouve dans des galeries, en face de tableaux étranges qui provoquent des émotions sans que l'on sache pourquoi.
Leur chansons prennent parfois une tournure psychédélique, utilisant des sonorités étranges, la musique des Stranglers atteint directement le cerveau. En fait il n'y a pas grand chose de plus fort qu'une envie de Stranglers

Suite XVI, leur nouvel album, s'inscrit complétement dans la continuité. Les membres du groupe ont changé entre temps, le chanteur n'est plus le même pourtant... tout est là ! Et pire encore, tout est toujours aussi bon
Quand j'ai voulu écouter Suite XVI, j'ai eu peur que le CD soit protégé par un quelconque procédé anti-copie, rendant la lecture difficile sur certains lecteurs. En réalité il n'en est rien. Mon lecteur CD a simplement rendu l'âme à la seule lecture des premières mesures de l'album. La dose était trop forte semble-t-il

Je vous recommande vivement cet album, ou alors Peaches - The Very Best Of si vous désirez dévouvrir les anciennes chansons du groupe.
Un extrait du nouvel album est un écoute sur cette page

Retour à l'informatique... J'ai remarqué par son site que rgod utilise Wapiti pour trouver des vulnérabilités dans les logiciels qu'il audite. Ca fait plaisir
Je compte toujours continuer le développement de Wapiti, j'attends juste d'avoir un peu de temps et l'impulsion nécessaire. J'ai aussi travaillé sur un projet de forum en PHP il y a quelques temps (j'ai fait les 90% du travail en un temps record) et je n'ai pas repris depuis pour les mêmes raisons. Mais j'y pense.

La nouvelle vient de tomber : l'un des serveurs principaux de Debian a été compromis.
Baptisé gluck, ce serveur est utilisé par les développeurs Debian et propose différents services comme "cvs", "ports" et "releases"... Dès la détection de la compromission, le serveur a été mis hors ligne afin d'effectuer une analyse forensics.

L'apparition récente d'une faille dans le kernel 2.6 permettant de passer root semblait le scénario le plus probable pour ce piratage.

Cette hypothèse s'est avérée vraie après l'analyse de gluck, comme l'explique Debian dans un communiqué.

De toute évidence les pirates devaient posséder un accès à la machine depuis quelques temps et attendaient seulement la première vulnérabilité importante leur permettant de prendre contrôle du système.
Heureusement l'intrusion a été très vite détectée et les pirates n'ont pas eu le temps de causer trop de dégâts... seule une version backdoorée de la commande ping a été trouvée.

Pour info, une intrusion similaire avait eu lieu en novembre 2003. A l'époque les pirates avaient modifié les sources du kernel pour y ajouter une backdoor mais grâce aux yeux attentifs de Linus Torvalds, on avait pû éviter le pire

Source : Zone-H.org

Je viens de faire avec succès mon upgrade de kernel de la version 2.4.29 à la version 2.4.31 sous Slackware.
Pour mettre votre kernel à jour vous devez récupérer plusieurs paquets sur le ftp officiel ou un miroir officiel comme celui-ci :
http://distro.ibiblio.org/pub/linux/distributions/slackware/slackware-current/slackware/

Vous devez télécharger :
- le nouveau kernel : kernel-ide-2.4.31-i486-1.tgz
- les modules pour ce kernel : kernel-modules-2.4.31-i486-1.tgz
- la dernière version de mkinitrd : mkinitrd-1.0.1-i486-3.tgz
- les sources du kernel : kernel-source-2.4.31-noarch-1.tgz
- les headers du kernel : kernel-headers-2.4.31-i386-1.tgz
- les drivers ALSA : alsa-driver-1.0.9b_2.4.31-i486-1.tgz

Normalement seuls les trois premiers paquets sont nécessaires et devraient suffire pour un système de base (une machine en mode console par exemple). Les paquets restant vous serviront à installer les drivers pour votre carte graphique et avoir le son (et oui Alsa ce n'est pas seulement pour faire des gateaux )

Les instructions à suivre se trouvent globalement dans le fichier "/boot/README.initrd" de votre Slackware.
Une fois les paquets téléchargés, installez-les avec installpkg. Si vous jetez un coup d'oeil au répertoire /boot vous vous appercevrez que l'installation du nouveau noyau a modifié quelques liens symboliques... Par exemple le fichier vmlinuz qui pointait vers vmlinuz-ide-2.4.29 pointe maintenant vers vmlinuz-ide-2.4.31. Bref l'installation a fait de votre nouveau noyau le noyau par défaut...
Mais attention !! On n'a pas encore fini ! On doit créer le fichier initrd.gz qui se chargera du chargement de ce nouveau noyau.
Placez vous dans /boot...
Si comme moi vous avez opté pour un système de fichier reiserfs, tappez :

mkinitrd -c -k 2.4.31  -m reiserfs

pour un système ext3 ce sera plutôt :

mkinitrd -c -k 2.4.31 -m jbd:ext3 -f ext3 -r /dev/hdXY

(remplacez "/dev/hdXY" par votre partition racine)

Dernière étape : modifier le fichier de configuration de LILO pour avoir le choix entre les deux kernels au démarrage (très pratique si on a fait une erreur d'installation).
Placez-vous à la fin de votre fichier /etc/lilo.conf avec votre éditeur de texte préféré (il faut juste qu'il enregistre en texte pûr).
Vous devriez voir quelque chose comme ça :

image = /boot/vmlinuz
  root = /dev/hda1
  label = Linux
  read-only

Nous allons ajouter le nouveau kernel et changer la location (la ligne "image") de l'ancien kernel... puis tant qu'à faire modifier aussi le texte qui désignera le kernel (la ligne "label")

image = [B]/boot/vmlinuz-ide-2.4.29[/B]
  root = /dev/hda1
  label = [B]Slackware-2.4.29[/B]
  read-only
[B]image = /boot/vmlinuz-ide-2.4.31
  initrd = /boot/initrd.gz
  root = /dev/hda1
  label = Slackware-2.4.31
  read-only[/B]

On enregistre et on fait un "lilo -v" qui nous informe que les labels utilisés sont trop long
On modifie simplement en :

image = /boot/vmlinuz-ide-2.4.29
  root = /dev/hda1
  label = Slack-2.4.29
  read-only
image = /boot/vmlinuz-ide-2.4.31
  initrd = /boot/initrd.gz
  root = /dev/hda1
  label = Slack-2.4.31
  read-only

On relance... et l'affaire est dans le sac

Attention à chaque fois vous devez penser à modifier "/dev/hda1" par votre partition racine... sans cela l'ordinateur ne parviendra pas à charger le noyau
Dernière étape : rebooter en espérant que vous n'ayez pas fait d'erreur... Si c'est le cas vous avez toujours l'ancien noyau pour résoudre le problème
Vous aurez probablement à réinstaller les drivers de votre carte graphique pour ce nouveau kernel.