On se tutoie ?

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

mardi, mai 26 2009

Utiliser plusieurs claviers avec des mapping différents sous X.org

Les deux techniques présentées sont différentes selon la version de X.org utilisée.
Les versions de X.org >= 1.5 supportent l'hotplugging, en passant par HAL ; les versions précédentes non.

Pour connaître sa version de X:

X -version

Avec HAL

Pour lister les périphériques détectés par HAL:

lshal

Copie le fichier /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi dans /etc/hal/fdi/policy/.

Voici mon fichier une fois modifié:

<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.keymap">
      <append key="info.callouts.add" type="strlist">hal-setup-keymap</append>
    </match>
 
    <match key="info.capabilities" contains="input.keys">
      <merge key="input.xkb.rules" type="string">base</merge>
 
      <merge key="input.xkb.model" type="string">keyboard</merge>
      <match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"
             string="Linux">
        <merge key="input.xkb.model" type="string">evdev</merge>
      </match>
 
      <match key="info.product" string="TypeMatrix.com USB Keyboard">
              <merge key="input.xkb.variant" type="string">bepo</merge>
      </match>
      <match key="info.product" string="USB Multimedia Keyboard">
              <merge key="input.xkb.variant" type="string">latin9</merge>
      </match>
 
      <merge key="input.xkb.layout" type="string">fr</merge>
    </match>
  </device>
</deviceinfo>

La partie:

<match key="info.product" string="TypeMatrix.com USB Keyboard">
    <merge key="input.xkb.variant" type="string">bepo</merge>
</match>

spécifie que pour mon clavier TypeMatrix je souhaite une variante bépo.
Pour l'autre j'utilise du latin9.

Pour configurer ton fichier il faut reprendre les informations issues de lshal.
Les claviers sont repérables par leur info.capabilities qui contiennent 'input.keyboard'.

Une fois repérés il reste à récupérer la chaîne info.product (TypeMatrix.com USB Keyboard et USB Multimedia Keyboard dans mon cas) et configurer le fichier /etc/hal/fdi/policy/10-keymap.fdi avec.

Sans HAL:

Pour lister uniquement les périphériques d'entrée (souris, clavier, joystick...):

xinput list --short

On récupère l'identifiant du device qui nous intéresse et, par exemple:

setxkbmap -device 0 fr bepo
setxkbmap -device 1 fr latin9

L'inconvénient c'est que le changement n'est pas persistant lors de chaque redémarrage.

jeudi, juin 12 2008

Accéder à du contenu authentifié ... en 2 lignes de shell

Le souci : récupèrer du contenu protégé par un couple login / pass classique

Décidément les outils GNU n'ont pas fini de me surprendre.
Le dernier en date c'est wget.
Quand on voit la taille du man on se dit tout de suite qu'on peut faire un paquet de choses avec cet outil.

L'usage le plus courant de wget est le téléchargement de fichier sur la toile, que ceux ci soit stocké en http, ftp ...
Récemment je cherchais à récupérer la liste des flux que je consulte dans google reader.
Sous Reader l'export se fait au format standard OPML.

Bien sûr pour accéder à l'export il faut s'authentifier.
J'ai d'abord pensé faire un petit script ruby mais dans ce cas présent il y a mieux.
Si si !

S'authentifier avec sauvegarde des cookies

L'idée est de procéder en deux étapes :

  1. Se connecter en soumettant login / pass et récupérer le cookie pour le stocker dans le fichier de notre choix.
  2. Ré-utiliser ce cookie pour accéder au fichier qui nous intéresse [1].

Chaque étape se fait en une ligne de commande :

 
wget "https://www.google.com/accounts/ServiceLoginAuth?service=reader" --post-data="PersistentCookie=1&Email=email&Passwd=pass" --no-check-certificate --save-cookies="/tmp/gcookie" --output-document=/tmp/null 
wget "http://www.google.com/reader/subscriptions/export" --no-check-certificate --load-cookies="/tmp/gcookie" --output-document="~/opml"

J'ai volontairement utilisées les options longues qui sont réellement explicites.

Dans la première étape on accède à l'url d'authentification et on soumet le formulaire en POST [2] en lui passant les différentes valeurs (notre email, notre mot de passe, et l'option pour rester connecté à base de cookie).
La valeur 1 est la valeur de la checkbox cochée.

Le --no-check-certificate nous permet de passer la validation du certificat https comme c'est souvent le cas, notamment pour les certificats auto-signés.
Le --save-cookies nous permet de spécifier le path ou sera stocké le cookie. Si l'authentification échoue le fichier sera quand même créé mais uniquement avec les headers de wget.
Enfin la page récupérée ici (page qui nous indique le succès ou non de notre connexion) ne nous intéresse pas, elle est donc copié dans le trou noir qu'est /dev/null.

La deuxième étape reprend les mêmes options que la première mise à part le --load-cookies qui nous permet d'accèder à une page en se basant sur notre fichier de cookies précédemment créé.
C'est tout, ton fichier de souscriptions est désormais dans ton $HOME.

Difficile de faire plus rapide même si le script est minimaliste et ne vérifie pas si l'authentification s'est bien passée etc ...

Notes

[1] Et ne pas oublier de l'effacer une fois le fichier récupéré.

[2] D'ailleurs ça marche aussi en passant les paramètres et leurs valeurs respectives en GET.

vendredi, mai 23 2008

Garder son serveur GNU / Linux à l'heure atomique

Rester dans les temps

C'est une bonne idée de conserver son serveur à l'heure, surtout quand celui ci doit communiquer avec le reste du monde.

Sous GNU / Linux il existe ntpdate qui permet de réajuster l'heure à un moment donné en se basant sur des serveurs de temps.
Ce paquet est pratique pour une utilisation ponctuelle et réfléchie.

Toutefois c'est une mauvaise idée d'utiliser ntpdate dans un cron pour conserver sa machine à l'heure.
En effet les décalages de temps, même minces, risque d'entraîner des perturbations (parfois invisible) au niveau des processus en cours.

Nombreux sont les programmes qui utilisent des timestamp ou se base sur l'horloge système pour planifier d'autres tâches.
Si un programme planifie une tache à n+1 et qu'à la prochaine mise à jour de temps ton serveur passe à n+2, certaines tâches ne seront pas éxécutées.

Le programme dovecot par exemple, s'arrête complètement à chaque mise à jour de temps avec ntpdate.

Utiliser un démon pour garder l'heure à jour

Pour garder sa machine à l'heure il existe un programme qui tourne en tache de fond : ntpd (paquet ntp).
Ntp ne se contente pas de réajuster l'heure avec les risques que cela comprend.
Lorsque le serveur est en retard il accélère l'horloge système afin de rattraper son retard.
Le temps va donc passer plus vite mais sans perte.
À l'inverse il va décélérer l'horloge si la machine est en avance.

Pour l'installer il te suffit d'utiliser ton gestionnaire de paquet favoris, par exemple :

aptitude install ntp

ou d'utiliser le paquet qui va bien sur le site officiel.

Une fois installé le serveur se lance en démon.
J'ai juste changé les serveurs du /etc/ntp.conf de n.debian.pool.ntp.org vers n.fr.pool.ntp.org pour avoir les serveurs de temps les plus proches.

mercredi, juin 20 2007

Installer plusieurs distributions linux

Depuis que j'ai vu passer l'annonce de la disponibilité d'ubuntustudio, j'avais envie de tester cette distribution, pour me remettre un peu à la MAO.

Toutefois je ne savais pas comment m'y prendre pour la faire cohabiter avec ma distribution arch. En fait c'est relativement simple.
Si comme moi tu utilises GRUB (je ne donnerai pas la procédure pour LILO) il faut l'installer dans le MBR du disque de démarrage si ce n'est pas déjà le cas :

grub-install /dev/hda

Normalement à l'installation de la distribution c'est le choix par défaut mais il est possible de l'installer sur une partition.

Maintenant tu peux installer la seconde distribution, et c'est là qu'il faut faire attention. Lorsque viendra le choix de l'installation de GRUB, il faut choisir la partition de destination.
Dans mon cas je l'ai installée sur /dev/hda2, je choisis donc /dev/hda2 (ou hd0,1 ; c'est pareil) pour installer GRUB.

A la fin de l'installation, au prochain redémarrage tu n'as pas encore accès à la seconde distribution. Pour cela il faut chainloader le second chargeur de boot à partir du premier.
En dépit du terme barbare c'est très simple. Une fois booté sur la la distro principale tu vas éditer le fichier /boot/menu/grub.lst et ajouter ceci (en adaptant suivant la partition d'installation) :

title  Ma distribution
root   (hd0,1)
chainloader +1

Voilà c'est terminé. Au prochain reboot, lorsque tu choisiras 'Ma distribution' le GRUB de la seconde distribution sera amorcé et tu pourras alors choisir celle-ci.

vendredi, mars 16 2007

Votez !

Non ceci n'est pas un appel aux urnes, en l'occurence il s'agit plutôt d'un vote virtuel mais tout aussi utile. Poursuivant son idée de fournir des machines avec Linux pré-installé, Dell te demande maintenant de lui dire ce que tu vas en faire de ton manchot.

Il s'agit donc d'un petit formulaire à remplir indiquant quelle genre de machine faisant tourner Linux t'intéresse le plus (laptop, PC fixe ...) et l'utilisation que tu comptes en faire (Internet, photo, video, jeux ...).

Enfin, l'un des points importants concerne le choix de la distribution, Dell propose 2 distributions commerciales & 3 distributions communautaires :

  1. Novell / SuSE Linux Desktop (Commerciale)
  2. Red Hat Enterprise Desktop (Commerciale)
  3. Fedora (Communautaire)
  4. OpenSUSE (Communautaire)
  5. Ubuntu (Communautaire)

Utilisant debian sur l'ensemble de mes machines et Kubuntu sur mon poste desktop, je commence à être bien rodé aux distributions de type debian-like, j'ai donc voté en conséquence.

D'ailleurs l'idée d'acheter du matériel livré avec la prochaine feisty (dont la sortie est prévue pour le 19 avril) me plaît assez !

On peut bien entendu imaginer tous les impacts positifs de ce choix. Le plus important à mes yeux étant que les constructeurs se sortent enfin un peu les doigts du <censuré>***</censuré> pour fournir des pilotes linux valables pour leur matériel. Une fois cette démarche entammée on se prend à rêver d'avoir des jeux récents compatibles sous linux, de façon native.

Bref, fonces voter j'ai comme l'impression qu'il s'agit d'une opportunité à ne pas laisser passer.

Via prendreuncafe