On se tutoie ?

Aller au contenu | Aller au menu | Aller à la recherche

jeudi, septembre 27 2007

Fetcher son gmail

Comme je n'aime ni l'interface web de gmail, ni le fait d'avoir 15 boîtes à fetcher, j'ai décidé de configurer mon gmail dans mon .fetchmailrc. La seule “difficulté” c'est que gmail n'autorise que les connexions SSL.

Plutôt que de paraphraser voilà un lien vers un HOWTO.

jeudi, juin 7 2007

Sésame, réveille toi !

J'ai récemment subi une petite mésaventure. Pourtant tout partait d'une bonne intention. Réactif à la campagne incessante de sauvegarde de la planète je me suis dit :”Shutdown your computer, save the world”, et j'ai donc pris le parti d'éteindre mon PC desktop quand c'était réalisable.

Seulement voilà, une fois parti en week end, il m'a manqué ce document complètement indispensable que j'avais pris beaucoup trop de temps à réaliser.
Bien entendu rsync n'avait pas eu le temps de backuper ce document sur mon serveur avant que j'éteigne mon poste. D'habitude en trois coups de ssh - scp bien placé j'aurai pu le récupèrer facilement, même non archivé.

Alors que faire ? Fallait-il mettre de côté ma récente bonne habitude ? Bien sûr que non.
J'ai donc fini par trouver la solution à mon problème : wakeonlan.

Le Wake-on-LAN est une technologie permettant à un ordinateur d'être démarré à distance par l'envoi d'un "magic-packet" sur la carte réseau supportant le Wake-on-LAN.
Bref avec ça je peux démarrer mon poste, à partir de mon serveur, auquel j'ai accès en ssh.

Comment mettre cela en place ?

Sur la machine à démarrer à distance :

Tout d'abord il faut commencer par récupérer ethtool, disponible aussi bien sous debian que sous arch.

# pacman -S ethtool 
ou
# aptitude install ethtool

Ensuite on va vérifier que notre carte supporte le wake on lan :

# ethtool eth0 | grep Wake
        Supports Wake-on: g
        Wake-on: d

Cela signifie que le WOL est supporté mais pas activé. Si pour vous le support est sur 'd' vous avez sûrement une option à activer dans le bios, sinon votre carte réseau est peut-être simplement trop ancienne. Si la carte le supporte activons le WOL :

# ethtool -s eth0 wol g

Et on vérifie :

# ethtool eth0 | grep Wake
        Supports Wake-on: g
        Wake-on: g

Avant d'éteindre ce poste, repéres son adresse MAC et notes là (ou retiens là de tête voir :-) ):

$ ifconfig | grep HWaddr
eth0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx

Sur la machine qui enverra le paquet magique :

Il faut installer wakeonlan ou etherwake. Le premier permet de redémarrer l'ordinateur en passant par le net contrairement au second.

Sur debian(-like) :

# aptitude install wakeonlan

Sur arch il n'existe de paquet ni pour l'un ni pour l'autre. Dans mon cas l'appelant est sous debian, ce n'est donc pas génant mais si vraiment vous devez faire l'appel depuis arch vous pouvez récupérer les sources ... depuis une debian par exemple :-) :

$ cd /tmp && apt-get source wakeonlan

Vous pouvez ensuite déplacer et utiliser le script (extrait dans /tmp/wakeonlan-0.41/wakeonlan) directement sous arch ou autre, puisqu'il est écrit en perl.

Une fois cela réalisé vous pouvez redémarrer votre client :

$ wakeonlan xx:xx:xx:xx:xx:xx

Si vous n'avez pas essayé de retenir l'adresse de tête (dans ce cas vous redémarrez sûrement à la main :p), votre ordinateur devrez commencer à ronronner !

Attention il reste toutefois une petite manipulation. En effet, une fois booté le Wake-on sera de nouveau désactivé sur eth0.

Certains recommandent d'activer l'option par un script à l'arrêt de l'interface réseau avec tous les soucis que ça comporte :

  • Un halt coupe les connexions violemment sans éxécuter les scripts pre-down
  • Un arrêt encore plus violent en appuyant sur le bouton ne permettra pas de réveiller la machine la prochaine fois

Partant de ce constat je préfère éxécuter la commande au démarrage. J'ai donc mis la commande précédente dans un script (/etc/rc.d/starter) :

#!/bin/sh -e
[ -x $(which ethtool) ] && ethtool -s eth0 wol g

que le lance au démarrage (en modificant le rc.conf) DAEMONS=(.... starter)

Voilà, finis les soucis !

mercredi, juin 6 2007

Il est là, il arrive, je le veux !

Reste deux contraintes de taille : le prix et l'opérateur, toujours pas choisi.

jeudi, mai 10 2007

Remote sous linux : beucoup de lirc et un peu de magie

Tombé du lit vers 4h30 ce matin, je me suis demandé à quoi j'allais bien pouvoir m'attaquer avant de me souvenir qu'il restait une chose que je n'avais pas configuré depuis ma migration de kubuntu vers arch : ma télécommande.

Configuration :

  • Arch Linux 0.8 (Voodoo)
  • Noyau : 2.6.21-ARCH
  • Alsa : version 1.0.14rc2
  • Lirc : 0.8.1-6

La télécommande est, comme toute chose inutile, indispensable.

Côté matériel j'utilise donc la télécommande livrée en standard avec ma carte son Audigy platinum 2 zs pro, qui à l'époque valait son pesant d'or.

Il y a en fait deux sources d'événements différents : le hub qui possède 3 boutons en façades et la télécommande en elle même qui en possède 33.
Le fonctionnement de cette télécommande est 'simple'. Lorque que vous appuyez sur un bouton, un signal est envoyé au hub qui le transfère à la carte son par une interface midi.
Dans un premier temps il faut vérifier la présence de cette interface midi, qui a été créée par alsa si celui ci a été installé.

$ ls -l /dev/snd/ | grep midi

  • crw-rw 1 root audio 116, 8 mai 10 2007 midiC0D0
  • crw-rw 1 root audio 116, 9 mai 10 2007 midiC0D1
  • crw-rw 1 root audio 116, 10 mai 10 2007 midiC0D2
  • crw-rw 1 root audio 116, 11 mai 10 2007 midiC0D3

L'interface midi est donc bien présente. Le C0 désigne la carte son 0 et le port midi qui nous intéresse est le 1. Puisque tout est en ordre, on commence donc par installer lirc qui permet de décoder les signaux infrarouges de la plupart des télécommandes.

Sous arch, lirc se trouve dans le dépôt extra, qu'il faudra donc activer si ce n'est pas encore le cas (dans /etc/pacman.conf). Si vous ne souhaitez pas activer ce dépôt, vous pouvez compiler lirc à la main, ce qui vous permettra entre autres de choisir le driver dont vous avez besoin (livedrive_midi) pendant la phase de configuration, évitant ainsi l'ajout de tous les drivers inutiles.

  1. pacman -S lirc lirc-utils

Une fois lirc installé, nous allons le configurer par le biais du fichier /etc/conf.d/lircd :

LIRC_DEVICE="/dev/snd/midiC0D1"
LIRC_DRIVER="livedrive_midi"
LIRC_EXTRAOPTS=""
LIRC_CONFIGFILE=""

Nous avons donc spécifié le device et le driver à utiliser. Avant de se jeter à l'eau et de lancer lircd pour tester il faut noter que certaines personnes doivent lancer une chaine d'initialisation au périphérique midi afin que celui ci soit opérationnel :

$ echo -e '\360\000\040\041\141\000\000\000\177\000\367' > /dev/snd/midiC0D1

Si vous avez besoin de cette chaine, pensez à automatiser le processus car il faudra l'envoyer à chaque redémarrage. Lancons maintenant lircd :

/etc/rc.d/lircd start

Logiquement lircd se lance mais nous prévient qu'il n'a pas trouvé le fichier de configuration /etc/lircd.conf :

lircd: could not open config file '/etc/lircd.conf' lircd: No such file or directory

Ce fichier comportera le binding des événements correspondant à notre remote. En fait il est tout à fait possible de le générer nous même via irrecord :

$ irrecord -d /dev/snd/midiC0D1 -H livedrive_midi /tmp/binding

Mais nous pouvons nous en passer car un fichier fonctionnel pour cette remote existe déjà, autant donc s'en servir. Copier donc le contenu suivant dans /etc/lircd.conf :

begin remote

   name        rm1500
   flags       SPACE_ENC|CONST_LENGTH
   bits        32
   eps         30
   aeps        100
   header      9000 4500
   one         563  1687
   zero        563  562
   gap         108000
   toggle_bit  0
   repeat      9000 2250
   frequency   38000
   duty_cycle  33
   begin codes
       1       0x83228B74
       2       0x83228F70
       3       0x8322906F
       4       0x83228A75
       5       0x8322847B
       6       0x83227887
       7       0x83228976
       8       0x8322837C
       9       0x83227788
       0       0x8322807F
       stop    0x8322857A
       play    0x83227986
       pause   0x83227986
       slow    0x83227D82
       step    0x83227E81
       prev    0x83227F80
       next    0x83227A85
       mute    0x83226E91
       vol-    0x8322639C
       vol+    0x8322629D
       eax     0x83228C73
       options 0x8322827D
       display 0x83227689
       return  0x83228E71
       start   0x83228877
       close   0x83227C83
       up      0x83227B84
       down    0x83228D72
       left    0x83228778
       right   0x8322758A
       ok      0x8322817E
       power   0x8322619e
       cmss    0x8322718e
       record  0x8322738c
   end codes

end remote begin remote

   name        audigy_io_hub
   flags       SPACE_ENC|CONST_LENGTH
   bits        32
   eps         30
   aeps        100
   header      9000 4500
   one         563  1687
   zero        563  562
   gap         108000
   toggle_bit  0
   repeat      9000 2250
   frequency   38000
   duty_cycle  33
   begin codes
       mute    0x80000040
       vol+    0x80008080
       vol-    0x80008082
       cmss    0x80000080
   end codes

end remote

Vous pouvez constater la présence du hub et de la remote. Une fois le fichier pasté, on relance lircd. Si tout s'est bien passé on lance un irw :

$ irw

En appuyant sur les boutons de la remote ou en triturant les boutons du hub vous devriez voir apparraitres des choses du style :

0000000080008080 00 vol+ audigy_io_hub
0000000080008080 01 vol+ audigy_io_hub
0000000080008082 00 vol- audigy_io_hub
0000000080008082 00 vol- audigy_io_hub
0000000083228b74 00 1 rm1500
0000000083228f70 00 2 rm1500
000000008322906f 00 3 rm1500

Magnifique, tout fonctionne au poil. Que faire maintenant de ces signaux ? Grâce à ce fichier de configuration nous allons pouvoir réaliser des actions correspondantes aux différentes touches. Pour cela on se crée un fichier .lircrc dans son home et on le remplit de la sorte, pour la touche display par exemple :

begin

 prog = irexec 
 button = display
 config = /opt/kde/bin/amarok &

end

On le voit c'est irexec qui fait la correspondance entre lirc et les commandes de lancement, seulement irexec n'est pas encore lancé actuellement, alors n'attendons plus, lançons le en démon :

$ irexec -d

Maintenant l'appui sur la touche display devrait lancer amarok. N'oubliez pas de faire un petit script qui s'éxécutera au démarrage et lancera irexec en tâche de fond. Si vous êtes un peu flemmard pour configurer un à un chacun des boutons dans le fichier .lircrc sachez que irkick peut le faire pour vous. Il s'agit d'un soft kde qui vous permet de configurer vos boutons via une IHM.

La part de magie :

Lorsque j'ai voulu installer et que j'ai effectué les opérations que je viens de décrire cela n'a pas fonctionné. D'ailleurs le voyant rouge du hub ne s'allumait même pas lorsque j'appuyais sur un des boutons de la remote. Pourtant tout semblait bien configuré, mais au lancement d'irw aucun des pottards n'avait le moindre effet. J'ai donc commencé à me poser des questions et à sérieusement me demander si le matériel était toujours opérationnel.

Et puis dans un dernier espoir j'ai voulu tester avec un live cd de kubuntu. J'ai donc booté rapidement, installé lirc, lirc-x et lirc-modules-source et ré-itérer les étapes précédentes et la bingo : le voyant s'est allumé, ça a fonctionné directement. Déjà content que ça marche quelquepart j'ai voulu réessayer sur mon arch et la boum ça a fonctionné aussi, sans rien retoucher.

Note : le seul bouton qui ne fonctionne pas est celui qui permet de régler l'amplification du micro. Vu son intérêt limité je ne me suis pas penché en détail sur le pourquoi du comment.

jeudi, mars 1 2007

Compiler son kernel sous debian

Ce document me sert avant tout de mémo et est amené à évoluer, il existe des dizaines de sites expliquant plus en détails comment compiler son kernel.

L'intérêt de compiler son noyau est de bénéficier des dernières avancées, de drivers plus à jour etc ... De plus sous debian, les derniers kernels en date ne sont pas forcément fournis sous forme de paquets (linux-image). Il faut souvent attendre un peu (même en unstable ou testing). Enfin une compilation personnelle vous permet de choisir et charger uniquement les options dont vous avez besoin (inutile d'avoir les drivers de matériel que vous ne possédez pas), ce qui optimise les performances de manière significative. Rentrons donc dans le vif du sujet.

Mise en garde :

Gardes toujours au moins un noyau sur lequel tu sais que tu pourras booter sans soucis, ce qui t'éviteras quelques nuits blanches en cas de kernel panic.

Pré requis :

  1. Posséder une distribution de type debian, ou debian-like (ubuntu ...)
  2. Avoir les packages suivants installés :
  • fakeroot
  • kernel-package, pour bénéficier de la commande make-kpkg
  • libc-dev (dans mon cas libc6-dev)
  • libncurses-dev (dans mon cas libncurses5-dev)
  • initrd-tools

Installation :

Récupération du noyau à compiler :

$ cd /tmp && wget -c ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.20.1.tar.bz2

Extraction du noyau à compiler :

$ tar jxf linux-2.6.20.1.tar.bz2 && cd linux-2.6.20.1

Une fois que tout est prêt il nous reste à choisir ce que l'on souhaite activer dans notre nouveau noyau. Pour cela on a le choix entre deux solutions :

  • Partir à la découverte des multiples options disponibles dans le noyau
  • Utiliser la configuration de son noyau précédent

Pour rapatrier la configuration du dernier noyau on effectue un :

$ cp /boot/config-2.6.19 .config ( le dossier courant à ce stade devrait être /tmp/linux-2.6.20.1 )

Ici le config-2.6.19 correspond à la configuration de mon noyau précédent, vous devez choisir le votre.

Ensuite on lance le make menuconfig (qui ouvre une interface semi-graphique en ncurses) :

$ make menuconfig

Si tu as copié ton .config les options de ton précédent noyau seront chargés, sinon bonne chance dans les différents menus ; tu pourras choisir d'activer ou désactiver différentes options, voir de les utiliser sous forme de modules.

Choisis ensuite exit et acceptes de sauvegarder ta configuration.

Compiler son noyau

Ton noyau fraîchement configuré, tu vas enfin pouvoir le compiler :

$ make-kpkg - -rootcmd fakeroot - -initrd - -append-to-version=tontexte - -revision=2.6.20.1 kernel-image

Attention il n'y a pas d'espaces entre les tirets, il faut juste que je trouve la syntaxe wiki pour les afficher sinon cela me donne un texte barré sous dotclear.

Le paramètre --rootcmd fakeroot permet d'obtenir les droits root, ce qui est nécessaire pour la création du .deb du noyau.

Note : on aurait aussi pu utiliser --rootcmd sudo

Le paramètre --initrd permet de créer un fichier initrd. Cela est particulièrement utile pour utiliser des modules du noyau dès l'amorçage de l'image de celui-ci.

Le paramètre --append-to-version permet de rajouter un texte personnalisé qui appraitra en bout de chaine, lors du choix du noyau dans grub. Si c'est ta première compilation et que tu te sens un brin mégalo à l'idée d'avoir compilé ton noyau, rien ne t'empêche d'ajouter un texte du style -martin-ce-super-héros.

Toutefois au fil du temps, l'excitation retombant tu te cantonneras certainement à quelquechose de plus sobre comme la date :-)

Une fois la commande lancée et 3-4 cafetières vides plus loin tu devrais te retrouver avec un package de la sorte : kernel-image-2.6.20.1-tontexte.deb

Si la compilation échoue n'essaies surtout pas d'aller plus loin, il se peut que tu ais fais des erreurs de configuration, qu'il te manques des packages parmis ceux évoqués en début de tutoriel ou plein d'autres bonnes raisons. Dans tous les cas une recherche sur ton moteur de recherche préféré devrait vite t'apporter des éléments de réponse.

Une fois le package debian généré, tu prendras soin de faire un clean dans l'arborescence des sources:

$ make-kpkg clean

Dans le cas où tout s'est bien passé tu peux installer le paquet comme un package traditionnel :

# dpkg -i kernel-image-2.6.20.1.tontexte.deb

Note : le # désigne un shell ouvert en root, cela revient à lancer la commande précédée de sudo, un accès root étant généralement déconseillé.

dpkg va donc installer le nouvau noyau en :

  • Installant les modules dans /lib/modules/2.6.20.1-tontexte
  • Créant System.map-2.6.20.1-tontexte, /boot/config-2.6.20.1-tontexte et /boot/vmlinuz-2.6.20.1-tontexte
  • Ajoutant le nouveau noyau dans /boot/grub/menu.lst en première position dans la liste

Une fois que tu as vérifié que tout s'était bien passé, tu peux redémarrer ta machine:

  1. reboot ( ou shutdown -r now mais c'est plus long :-p )

Le boot se fera normalement sur le premier noyau de la liste c'est à dire celui que tu viens d'installer.

Problèmes potentiels au boot :

Table des partitions avancée :

Il peut arriver que le noyau Linux ne reconnaisse pas le disque si la table des partitions avancée est activée dans le fichier .config.

On a alors droit à un kernel panic en règle :

VFS: Cannot open root device "hda1" or unknown block (0,0) Kernel panic - not syncing: VFS Unable to mount root fs on unknow block (0,0)

Dans ce cas, après make menuconfig, édites le fichier .config en changeant:

CONFIG_PARTITION_ADVANCED=y en

  1. CONFIG_PARTITION_ADVANCED

Le # a pour effet de mettre la ligne en commentaire.

Utilisation d'initrd

L'installation du noyau sans créer de fichier d'init peut poser quelques problèmes, aussi n'oublies pas l'option --initrd sur la ligne de commande make-kpkg.

Désinstaller un noyau :

Si ton nouveau noyau fonctionne correctement, ce que tu verras à l'usage, tu pourras supprimer le plus ancien, en veillant à en avoir au moins toujours un autre en plus du courant. Personnellement j'aime bien en avoir toujours 3 dans ma liste donc une fois le nouveau installé et après quelques jours à le tester je supprime le plus ancien avec la commande :

# apt-get remove --purge kernel-image-version-a-supprimer

ou

# dpkg --purge kernel-image-version-a-supprimer

Voilà, c'est fini, ce n'était pas si compliqué !

Liens connexes :

page 2 de 2 -