Sortie de Debian "Lenny" 5.0, Squeeze nouvelle testing

Ce week-end, Lenny a pris la place de Etch [1][2] en temps que Debian stable, et la branche de test de Debian s'appellera désormais Squeeze. Comme je préfère des paquets relativement frais, une petite mise à jour du système s'impose afin de rester dans la branche de test.

Voici mon fichier de configuration des dépôts APT, /etc/apt/sources.list :

deb http://ftp.fr.debian.org/debian/ lenny main non-free contrib
deb-src http://ftp.fr.debian.org/debian/ lenny main non-free contrib

deb http://security.debian.org/ lenny/updates main contrib non-free
deb-src http://security.debian.org/ lenny/updates main contrib non-free

C'est la configuration quasi-standard d'APT suite à l'installation d'une Debian. Bien évidemment, vous êtes un warrior, et vous éditez votre fichier de conf avec un vrai éditeur de texte comme vim. Et comme vous êtes un warrior, vous connaissez les commandes utiles de vim. En l'occurrence, on va lancer une substitution, rien de bien méchant

:%s/lenny/testing/g

Première explication pour les moins warriors d'entre nous, à qui je conseille fortement de s'intéresser à vim. La commande que j'ai lancé se résume en : pour toutes les lignes du fichier, substitue les occurrences de lenny par testing pour chaque occurrence trouvée par ligne.
Deuxième explication, le fichier de configuration des dépôts gère deux notations : la notation basée sur des noms de personnage de Toy Story (Lenny, Squeeze, Sid, ...) et la notation de statut Debian (Stable, Testing, Unstable). Ici j'ai fait le choix de passer d'une à l'autre. La première notation permet de se figer sur une version alors que la deuxième prend en compte le glissement des versions. Lorsque Etch était stable, Lenny était testing. Désormais, Lenny est devenue stable (pour les curieux, Etch devient oldstable) et Squeeze devient testing. Si je laisse Lenny dans mon fichier, je vais passer sur la nouvelle stable, si je mets Squeeze, je resterai sur la testing pendant un peu moins de deux ans jusqu'à ce que Squeeze passe stable. Étant donné que je n'ai aucun intérêt à passer en stable à un quelconque moment, autant pointer sur l'alias testing.
Mon nouveau fichier ressemble donc à ça :

deb http://ftp.fr.debian.org/debian/ testing main non-free contrib
deb-src http://ftp.fr.debian.org/debian/ testing main non-free contrib

deb http://security.debian.org/ testing/updates main contrib non-free
deb-src http://security.debian.org/ testing/updates main contrib non-free

Désormais on peut passer aux choses sérieuses :

$ sudo apt-get update && sudo apt-get upgrade -s

En une ligne, je mets à jour les données sur les paquets, et je simule leur mise à jour. Ça permet de voir ce qu'il y a de nouveau, et si des problèmes s'annoncent. Pour réellement mettre à jour, il suffit d'omettre le -s. Pour finir la mise à jour, il faudra lancer :

$ sudo apt-get dist-upgrade

Cette dernière commande est celle qui permet de vraiment mettre à jour la distribution.
Et voilà ! C'est fini.
Un peu de lecture de qualité au sujet de la sortie de la nouvelle version de Debian [3][4][5].



[1] http://debian.org/
[2] http://debian.org/releases/
[3] http://linux.slashdot.org/article.pl?sid=09/02/14/1952222
[4] http://linuxfr.org/2009/02/15/25028.html
[5] http://www.pcinpact.com/actu/news/49108-debian-lenny-disponibilite-telechargement-nouveautes.htm

Gestion de la fréquence du processeur sous Debian avec cpufreq

Top ! Je suis un objet qui fait vrrrrrrrrrrrrr en dégageant beaucoup de chaleur. Je suis ? Je suis ?

Mon portable est équipé d'un AMD Turion ML-34, processeur ayant tendance à chauffer, et ça s'entend ! À pleine puissance (1,8GHZ), le ventilateur devient vite gênant après quelques minutes d'utilisation. On peut y remédier facilement en installant un daemon réglant dynamiquement la fréquence du processeur. Mon choix s'est porté sur cpufreqd [1], qui utilise le système cpufreq [2] intégré au noyau Linux.
Pour commencer, il suffit de l'installer (ainsi que cpufrequtils [2] qui se révélera utile par la suite) :

$ sudo apt-get install cpufreqd cpufrequtils

Ensuite, il nous faut configurer le lancement du daemon pour qu'il charge le bon module au démarrage. Cela se fait en éditant le fichier /etc/default/cpufreqd. Dans mon cas, il s'agit de :

CPUFREQ_CPU_MODULE="powernow-k8"

Je laisse la deuxième ligne du fichier tranquille, puisqu'elle va charger tous les governors disponibles :

CPUFREQ_GOV_MODULES="auto"

Maintenant, il nous faut configurer les governors dans le fichier /etc/cpufreqd.conf :

[General]
pidfile=/var/run/cpufreqd.pid
poll_interval=2
verbosity=4
enable_remote=1
remote_group=root
[/General]

[acpi]
acpid_socket=/var/run/acpid.socket
[/acpi]

[sensors_plugin]
sensors_conf=/etc/sensors.conf
[/sensors_plugin]

[Profile]
name=ondemand
minfreq=0%
maxfreq=100%
policy=ondemand
[/Profile]

[Profile]
name=performance
minfreq=80%
maxfreq=100%
policy=performance
[/Profile]

[Profile]
name=powersave
minfreq=0%
maxfreq=50%
policy=powersave
[/Profile]

[Profile]
name=conservative
minfreq=0%
maxfreq=80%
policy=conservative
[/Profile]

[Rule]
name=ac
ac=on
profile=ondemand
[/Rule]

[Rule]
name=battery
ac=off
profile=conservative
[/Rule]

[Rule]
name=battery_low
ac=off
battery_interval=0-15
profile=powersave
[/Rule]

Je ne vais pas m'étendre sur le contenu du fichier : il s'agit d'un compromis entre le fichier par défaut, ce que j'ai pu trouver sur le net et l'aide fournie par la manpage du fichier. Je l'ai rempli au moyen des informations obtenues par la commande cpufreq-info :

limitation matérielle : 800 MHz - 1.80 GHz
plage de fréquence : 1.80 GHz, 1.60 GHz, 800 MHz
régulateurs disponibles : ondemand, userspace, powersave, conservative, performance

Concrêtement, le fichier définit 4 profils affectés aux 4 governors respectifs, et 3 règles d'utilisation des profils. Lorsque le portable est branché sur secteur, le profil utilisé est ondemand, utilisant toutes les fréquences du processeur. Lorsqu'il est sur batterie, le daemon passe en conservative, et le processeur n'utilise plus que 90 % de ses capacités, soient les fréquences de 800MHZ (44 %) et 1,6GHZ (88 %).
C'est fini, il ne nous reste plus qu'à redémarrer le daemon pour qu'il prenne en compte sa nouvelle configuration :

$ sudo /etc/init.d/cpufred restart

Pour que tout cela soit user-friendly au possible (le paquet cpufrequtils installé auparavant permet de changer de governor/fréquence depuis la console), on peut installer un applet pour gérer tout ça. En l'occurrence pour Gnome il s'agit du Moniteur de changements de fréquence du processeur que l'on peut ajouter au tableau de bord.
Et voilà ! Désormais je peux changer de profil en un clic de souris, voire passer en profil userspace en sélectionnant directement la fréquence voulue.
Le Turion ne dit plus grand-chose, mes oreilles s'en portent aussi bien !

N.B. : pour toute question, remarque ou correction, utilisez les commentaires. Ça ne m'étonnerait pas que j'aie oublié une étape quelque part ! De plus, les profils conservative et powersave ne marchent pas comme ils devraient... :D



[1] http://www.linux.it/~malattia/wiki/index.php/Cpufreqd
[2] http://www.kernel.org/pub/linux/utils/kernel/cpufreq/cpufreq.html

Installer le plugin Adobe Flash Player 10 pour Iceweasel sur Debian 64bit

Oulah, ça fait un petit moment que je n'ai rien écrit. On va changer ça tout de suite !
Je reprends donc : vous venez d'installer votre Debian GNU/Linux favorite sur votre processeur 64bit préféré, votre navigateur chéri Iceweasel et vous voulez profiter du Flash en ligne. Quoi de plus normal que de vouloir contempler les publicités en Flash comme tout bon Windowsien !
Bien évidemment, si je décide d'installer le plugin Flash, c'est avant pour mater des vidéos sur youtube.com et autres, et pour jouer sur kongregate.com.
Adobe a fait de gros efforts sur la version 10 de son lecteur : une version GNU/Linux est sortie en même temps que les autres. Malheureusement, la version 64bit ne faisait pas partie de cette sortie. À l'heure actuelle, seule une version Alpha (stade très peu avancé du développement) du Flash Player 10 existe pour les OS 64bit basés sur les noyaux Linux et Solaris.
Et bien évidemment, comme on n'a pas peur et qu'on veut voir tout (il existe de bonnes alternatives au lecteur d'Adobe, libres qui plus est, telles que Gnash, très prometteur, mais qui n'est pas encore assez avancé) le Flash du net, on va l'installer.
DIrection Adobe Labs [1], pour télécharger l'archive du plugin. Adobe s'est montré particulièrement radin sur les instructions d'installation, mais ça ne va pas nous arrêter ! Avant cela, il ne faudra pas oublier de supprimer tout autre lecteur installé, comme Gnash [2]. Une fois téléchargé il ne reste plus que 2 petites étapes, désarchiver et mettre le plugin au bon endroit :

$ tar xzf ./libflashplayer-10.0.d20.7.linux-x86_64.so.tar.gz
$ sudo mv ./libflashplayer.so /usr/lib64/iceweasel/plugins/

Ca y est, c'est fini. On peut constater l'utilisation du plugin en tapant about:plugins dans la barre de navigation d'Iceweasel, après l'avoir redémarré.
Maintenant, amusez-vous bien !



[1] http://labs.adobe.com/downloads/flashplayer10.html
[2] http://www.gnu.org/software/gnash/

La prise de vue selon UNIX Garden

Il y a quelques temps, en me baladant sur le site des Éditions Diamond [1] (éditant des magazines réputés tels que MISC et GNU/Linux Magazine France), je suis tombé sur un lien vers Unix Garden [2].
Bien qu'appréciant beaucoup le site et son contenu, je n'avais pas prévu d'en parler, étant donné son caractère technique et spécifique au monde de l'informatique. Mais depuis quelques jours, une nouvelle série d'articles est en cours de diffusion. En fait, le site poste d'anciens articles des magazines de l'éditeur, y compris des articles liés à la photographie et la retouche d'images parus dans des hors-séries.
L'article [3] qui m'a donné envie d'en parler sur le blog traite de la prise de vue, et ça faisait un petit moment que je cherchais un article de qualité à ce sujet, chose que j'ai trouvé aujourd'hui. Je vous en fais donc profiter, et tant que vous y êtes, jetez un œil au reste du site.
Bien évidemment, je ne pourrais que vous conseiller d'acheter les magazines, pour ceux que les sujets traités intéressent.

[1] http://www.ed-diamond.com/
[2] http://www.unixgarden.com/
[3] http://www.unixgarden.com/index.php/graphisme/la-prise-de-vue-letape-incontournable

RSEIUB

Gné !?
6 lettres qui ne veulent pas dire grand chose, mais qui m'ont permis de ne pas tuer un serveur (informatique, pas de restaurant) il y a quelques temps.
Petite mise en situation : peu avant midi, matinée calme, quand soudain on m'annonce qu'un des serveurs préparé par mes soins fait des siennes. Plus précisément, une base Oracle tournant sous Debian GNU/Linux n'accepte plus les connexions... Ah. C'est embêtant en effet. Après vérification du problème et analyse des logs, le problème semblerait venir de l'archiveur d'Oracle qui est complètement con, mais là n'est pas le problème. Je tente de redémarrer quelques services, de redémarrer la base : rien n'y fait, impossible de se connecter.
Mince alors ! N'étant pas du tout expert Oracle, je ne sais pas d'où peut venir le problème et ce qui peut le provoquer. Et je me dis que par contre je suis expert en solution classique telles que le redémarrage. Je m'exécute donc. Lorsque dix minutes ayant passé (ne vous inquiétez pas, je ne suis pas resté dix minutes devant l'écran à attendre, j'ai trouvé autre chose à faire) l'affichage n'avait pas changé et restait figé sur le démarrage du listener Oracle après l'extinction d'une demi-douzaine de services (oulah, j'ai du sérieusement merdé pendant l'installation, moi) alors qu'il aurait logiquement dû s'éteindre, je me suis dit qu'il y avait un problème. Oui, enfin, je m'en étais rendu compte une minute après avoir lancé le redémarrage, mais dix minutes après, j'en étais certain.
Et c'est à ce moment là qu'on hésite très fortement à appuyer sur le gros bouton qu'arbore la machine pour ne pas tout casser (le système de fichier par exemple). C'est aussi à ce moment qu'on essaie de trouver une solution, et rapidement, parce que des gens attendent leur serveur pour bosser.
Et là on se souvient d'un vague truc découvert sur le net, mais qui n'avait servi à rien le jour où on l'avait trouvé : "Raising Skinny Elephants Is Utterly Boring". Oui, c'est un peu débile je l'accorde, mais au moins je l'avais retenu. Après avoir vérifié la syntaxe en faisant une petite recherche, je me lance dans une gymnastique des doigts sur le clavier en réalisant quelques commandes assez acrobatiques. Et après quelques déchirures musculaires, mon serveur redémarre enfin, sans souci et j'ai pu passer mon après-midi à tenter de résoudre le problème lié à Oracle, chose accomplie en début de soirée.

Tout ça pour dire, que les lettres RSEIUB, pour un utilisateur GNU/Linux, peuvent se révéler très utile. Je ne rentrerai pas dans les détails que je ne maîtrise pas, et que d'autres sites exposent mieux que moi, mais pour simplifier, il s'agit de passer des commandes de bas niveau directement au noyau au moyen du clavier lorsque le système ne répond pas : [Alt] + [Syst] + [R], puis [Alt] + [Syst] + [S], ... Chose intéressante, si l'affichage graphique a freezé et empêche l'accès aux consoles, il suffit de taper les commandes à l'aveugle en faisant une pause de quelques secondes entre chaque.
Au final on aura dit à notre noyau de clôturer tout ce qui est en cours, de tuer tout ce qui reste, et enfin de redémarrer. Si vous voulez plus d'infos, je ne peux que vous rediriger vers Wikipédia : http://en.wikipedia.org/wiki/Magic_SysRq_key
Conclusion : même dans les situations les plus désespérées, n'écrasez pas le bouton d'extinction de la machine, et utilisez plutôt cette suite de commandes.