On se tutoie ?

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

lundi, novembre 29 2010

Problème pour cloner un disque avec virtualbox

La bonne façon de cloner un disque avec virtualbox est d'utiliser vboxmanage.

VBoxManage clonehd foo.vdi --existing bar.vdi

Si vous obtenez une erreur du genre:

ERROR: Cannot register the hard disk '/virtual/foo.vdi' with UUID {6dce8ec5-1a90-43ac-ad9b-f03dc2fc822d} because a hard disk '/virtual/foo.vdi' with UUID {6dce8ec5-1a90-43ac-ad9b-f03dc2fc822d} already exists in the media registry…

Il faut juste spéficier les chemins absolus:

VBoxManage clonehd /virtual/foo.vdi --existing /virtual/bar.vdi

mercredi, novembre 3 2010

Quelques commandes pour rebooter sa livebox

Rebooter sa livebox sans passer par l'interface web à disposition c'est simple.

$ telnet 192.168.1.1
login: root
Password: 1234
[root @ home]$ reboot

Du coup si tu as besoin de le faire régulièrement, un petit script ruby qui va bien:

#!/usr/bin/env ruby -w
require "net/telnet"
 
connexion = Net::Telnet.new("Host" => "192.168.1.1")
connexion.login("root", "1234")
connexion.cmd('reboot', { "Timeout" => 180 })

Le timeout n'est utile que si tu souhaites faire des choses après le reboot, c'est le temps d'attente du retour de la commande, qui est forcément assez long dans le cas d'un reboot.

jeudi, janvier 7 2010

Résolution 2010

Passer définitivement de: french_layout.png

à: bepo_layout.png

mardi, février 26 2008

iPhone : attendre, encore et toujours ...

Comme pour tous les nouveaux produits high tech bling bling qui sortent j'essaie d'être un peu raisonnable et de ne pas me jeter dessus dans un excès de geekerie.

Je préfère que ce soit les premiers qui essuient les pots cassés : problèmes software, matériel défectueux (même si ça arrive sur des produits rodés), etc ...

En ce moment j'ai toutes les bonnes raison d'attendre pour l'iPhone :

  • D'une part on évoque de plus en plus un iPhone 2, qui en plus d'intégrer la 3G (et même la 3.5G) se verrait munie d'une caméra embarquée. Il semble de plus en plus probable qu'Apple mette en place une version mobile d'iChat afin de faciliter la visio conférence. Cette fonctionnalité serait disponible sur les iphone et les touch. Il y aussi de fortes chances que l'on voit apparaitre du GPS. Le frein majeur à toutes ces évolutions étant l'autonomie de la batterie, un gros travail devra être fait à ce niveau.
  • Ensuite quelques bruits de couloir évoquent une baisse de celui-ci d'environ 100$. Même si ce n'est pas dans les habitudes d'Apple de casser les prix on est en droit d'y croire puisque que pour un grand nombre, le prix élevé reste le principal obstacle.
  • Je suis curieux de voir un peu le potentiel du SDK afin de pouvoir répondre à la fameuse question : jailbreakera, jailbreakera pas ? Si chaque application doit être validée par Apple afin de pouvoir être installée inutile de dire que ce serait une énorme déception.
  • Me concernant ce qui m'a toujours le plus rebuté c'est ce forfait data anormalement cher, facturé par orange. Ici ce que j'attend avec impatience c'est l'arrivée de free sur le marché de la 3G. Si free parvient à obtenir cette licence il disposera alors d'une force de frappe conséquente dans le domaine de la téléphonie (et autres applications) mobiles puisqu'il détient aussi une licence WiMAX.

Etant donné que Free a souvent mis des grands coups de pied dans la fourmilière on peut rêver de plusieurs choses :

  1. De la téléphonie 100% IP sur son mobile, et donc des coûts largement réduits, voire de l'illimité.
  2. La gratuité des appels depuis sa freebox vers les mobiles (d'ailleurs Alice commence à offrir des heures de communications).
  3. Une seule facture englobant sa box triple and play et son forfait mobile (cependant ne révons pas trop, le forfait ne serait sûrement plus de 29,99€)

Il est amusant de constater que la stratégie de Free est à l'opposé de celle de SFR : se servir de son implantation dans les foyers pour conquérir le marché de la mobilité.
Nul doute que les mois à venir nous réservent encore de belles suprises ...

mercredi, janvier 30 2008

Pas encore bilingue, translate est là pour toi !

Si comme moi tu passes pas mal de temps sur des sites de traduction, ce post est fait pour toi.

En effet 99% des bonnes docs étant écrite dans la langue de Shakespeare il n'est pas toujours évident de tout comprendre sans assistance.
C'est pourquoi je me retrouve assez souvent sur wordreference dans une journée.

Globalement wordreference est un très bon service. Toutefois après avoir cherché un peu je me suis rendu compte qu'il n'offrait pas d'API.
Je me suis donc résolu à créer mon propre script (en ruby) qui attaque le site en GET et qui parse le résultat à l'aide de l'excellente lib Hpricot.

Actuellement le script permet de faire les traductions suivantes :

  • Anglais vers français
  • Anglais vers italien
  • Français vers anglais
  • Italien vers anglais

Bizzarement, et c'est dommage, le site n'utilise pas le même format d'URL ni d'affichage pour les traductions en espagnol ; que ce soit depuis ou vers l'espagnol.
Toutefois rien n'empêche de patcher le script pour y remédier.

Pour utiliser ce script il te faut rubygems et hpricot. Rubygems est disponible sur la plupart des distributions ainsi que sous Mac OS X avec fink ou port.
Une fois rubygems installé il faut installer Hpricot à partir de ce dernier :

# gem install hpricot

ou

# gem install hpricot --source http://code.whytheluckystiff.net

Personnellement j'ai choisi la deuxième version pour avoir la build la plus récente.
Si tu as une erreur du genre : `require': no such file to load -- mkmf (LoadError) c'est sûrement qu'il te manque le paquet ruby1.8-dev Une fois installé tu peux utiliser le script de manière suivante :

./translate.rb house

Pour avoir un panel de ce que peut faire le script :

./translate.rb -h

Pour avoir quelques exemples :

./translate.rb -e

Note : Tu peux très bien mettre le script directement dans ton path pour l'utiliser depuis n'importe où, comme une commande normale :

$ sudo ln -s /path/to/translate.rb /usr/local/bin/translate

Le script est disponible sur ce post en annexe, mais la version la plus à jour se trouve dans mon dépôt mercurial.
J'essaierai de mettre une documentation un peu plus complète sur le script dans mon espace dédié sous peu.

Tout est dit, j'attends tes commentaires, retours ou patchs !

mardi, janvier 22 2008

Utiliser le même ssh-agent entre plusieurs shells.

La problématique : se connecter entre ses différents machines, en ssh et sans mot de passe

Lorsqu'on commence à avoir des machines dans tous les coins on aime pouvoir y accèder facilement, et de partout.

Souvent on se retrouve avec un petit réseau local contenant plusieurs machines partageant un seul point d'accès à internet. C'est à partir de cette IP publique que l'on peut se connecter à son réseau interne de l'extérieur.

Le problème c'est que tant qu'IPv6 ne sera pas établi (et que ou l'on pourra disposer de plusieurs adresses publiques sans sourciller) on en est réduit à une seule adresse et on se retrouve avec une machine qui sert de passerelle pour rebondir dans son réseau interne.

Machine externe -> Passerelle -> Machine interne

Une solution basique : un jeu de clés privée / publique

Imaginons que l'on souhaite se connecter depuis la passerelle sur la machine interne. On va générer un jeu de clé :

$ ssh-keygen -t dsa

On peut utiliser le fichier par défaut, par contre il faut mettre une passphrase. Une fois notre paire de clés générée on va copier notre clé publique sur la machine sur laquelle on souhaite se connecter :

$ ssh-copy-id -i ~/.ssh/key.pub login@interne

Cela aura pour effet d'aller copier notre clé publique dans le fichier authorized_keys de la machine interne. Dès lors quand on voudra se connecter sur la machine interne depuis la passerelle c'est la passphrase qui sera demandée.

À ce niveau on peut penser avoir juste déplacé le problème : toujours un mot de passe à taper.

Toutefois, pour ne pas avoir à retaper sa passphrase à chaque connexion on peut utiliser ssh-agent.
Pour cela on rattache ssh-agent à un processus sur la passerelle, par exemple ssh-agent /bin/bash.

Cela aura pour effet de lancer un nouveau shell auquel sera rattaché l'agent.
Ensuite on peut rajouter les clés privées à gérer par notre agent : ssh-add ~/.ssh/id_dsa.

ssh-add va nous demander la passphrase, une fois entrée c'est lui qui interceptera les demandes de passphrases de ssh.

Dès lors je peux me connecter de ma passerelle vers ma machine interne sans mot de passe.

Aller un peu plus loin : utiliser le même agent pour faciliter les rebonds ssh

Soit, mais si je connecte depuis la machine externe vers la passerelle, et que depuis la passerelle je souhaite rouvrir une connexion vers la machine interne ma passphrase sera re-demandée.

Pourquoi ? Parce que notre agent est associé à notre shell (ssh-agent /bin/bash). En dehors de ce shell le problème est le même.

Si on y regarde de plus près, comment cela fonctionne t-il vraiment ?

Au lancement du ssh-agent une socket est créée dans le /tmp, du genre /tmp/ssh-xxxpiddushell/agent.piddushell
En fait le ssh-agent est un processus fils du shell nouvellement créé. En plus de ça notre commande génére plusieurs variables d'environnements qui ne sont accessibles qu'à l'intérieur du nouveau shell.

Regardons ça de plus près :

$ env | grep -i ssh

Deux variables nous intéressent :

SSH_AGENT_PID=22659
SSH_AUTH_SOCK=/tmp/ssh-WgkOE22658/agent.22658

Récupérer l'environnement de notre agent, et l'exporter dans le nouveau shell

On le voit ces informations sont facilement accessibles. Partant de là si on se connecte depuis la machine externe vers la passerelle et que l'on fait un export de ces variables dans le nouveau shell alloué lors de notre connexion ssh on peut parfaitement se reconnecter sur la machine interne sans taper de mot de passe :

$ export SSH_AGENT_PID=22659
$ export SSH_AUTH_SOCK=/tmp/ssh-WgkOE22658/agent.22658
$ ssh interne

L'idée c'est d'alouer automatiquement ces variables, en réalisant l'export ... dans notre .bashrc
En fait il y a deux façons de faire : soit on force le nom de la socket, avec un ssh-agent -a, soit on récupère les informations dynamiquement.

Je penche pour la deuxième qui m'évite de penser à passer cette option lorsque que je lance mon agent (et oui, geek == fainéant). En plus il faudra toujours récupérer l'id du pid.

Pour ça deux commandes à mettre dans le .bashrc :

export SSH_AGENT_PID=$(ps aux | grep -v 'grep' | grep ssh-agent | grep $(env | grep "USER" | sed s/USER=// | head -n 1) | head -n 1 | awk '{print $2}')

if [ "" != "$SSH_AGENT_PID" ]; then
  export SSH_AUTH_SOCK=$(find /tmp -iname "agent.$(ps -p $SSH_AGENT_PID -o ppid=)")
fi

Explications :


  • ps aux liste les processus
  • grep -v fait une recherche inverse c'est à dire qu'il exclut les résultats demandés. En l'occurence je demande à grep de s'exclure lui même, sinon la commande apparait dans la liste des résultats
  • grep ssh-agent fait ce qu'on lui demande, il recherche les lignes qui matchent.
  • grep $(env | grep "USER" | sed s/USER=// | head -n 1) fait un grep sur le nom de l'utilisateur. En effet il peut y avoir plusieurs agents sur la machine, appartenant à des utilisateurs différents.
  • head -n 1 renvoie la première ligne uniquement
  • awk '{print $2}' permet de splitter la ligne selon les espaces ou tabulations. Ici on renvoie le deuxième bloc qui contient le pid. On pourrait aussi utiliser cut.
if [ "" != "$SSH_AGENT_PID" ]; then
        export SSH_AUTH_SOCK=$(find /tmp -iname "agent.$(ps -p $SSH_AGENT_PID -o ppid=)")
fi

Explications :

Cette commande recherche la socket correspond à ce ssh-agent s'il existe (présence du pid).
La socket est nommée dans un format spécial : agent.pidduparentdel'agent ; il nous faut donc récupérer le pid parent du pid de l'agent, celui du shell donc.
C'est ce que réalise cette commande : ps -p $SSH_AGENT_PID -o ppid=

Ensuite c'est un find tout bête qui nous renvoie le full path de la socket.

Une fois ces commandes dans votre .bashrc c'est fini, lors de la connexion de externe vers passerelle, un shell est alloué, le bashrc sourcé et les variables d'environnements disponibles, on peut donc se connecter à la machine interne sans soucis.

Bien sûr pour faciliter le tout on peut utiliser un jeu de clés entre la machine externe et la passerelle.

Une pincée de sécurité en plus : empêcher les connexions ssh par mot de passe

Une fois tout ça en place pourquoi ne pas désactiver l'authentification par password ? Dans le fichier /etc/ssh/sshd_config :

PasswordAuthentication no

et au passage :

PermitRootLogin no

Ainsi on est sûr que seules les machines dont la clé publique se trouve sur la machine hôte pourront se connecter.
Toutefois il vaut mieux avoir au moins 3 machines pour utiliser ce système, ou conserver ses clés en lieu sûr, sinon au premier plantage votre machine distante devient inaccessible.
Dommage quand on n'a pas d'accès physique à celle-ci ...

mardi, janvier 15 2008

Flickr et le bug de l'an 2008.

2 147 483 647 : Deux milliards cent quarante sept millions quatre cent quatre vingt trois mille six cent quarante sept.

C'est le nombre de photos (sûrement largement dépassé à l'heure ou j'écris) hébergées sur flickr. Le côté inhumain de ce chiffre fait froid dans le dos.

Le souci c'est que ce chiffre représente aussi une limite, celle de la représentation d'un entier signé.
La majorité des systèmes actuels possèdent une architecture 32 bits. Les entiers sont donc représentés sur 31 bits (1 bit pour le signe).

Tu vois où je veux en venir : 2^31 = 2 147 483 648

Est ce que les auteurs de flickr pensaient un jour atteindre ce chiffre ? J'en doute.
Ce qui est sûr c'est qu'ils ont en tout cas prévu le coup puisque flickr n'a pas planté et que l'on peut continuer à y mettre ses photos.

A priori ils ont dû stocker les identifiants des photos sous une forme autre qu'un entier (une chaîne par exemple) ou alors ils utilisent un système où les entiers sont représentés sur un nombre plus élevés de bits.

Par contre pas sûr que les éditeurs tiers ayant bâtis des applications sur l'API de flickr par exemple, aient anticipés ce genre de désagrément.

A suivre ...

mardi, janvier 1 2008

Installer et tester ruby 1.9

Décidément ça ne chôme pas en cette fin d'année puisque la version 1.9 de ruby est sortie à noël.

Je pense que ce changement de version ne fera pas autant débat que pour rails, d'une part parce que ce n'est pas une version majeure et d'autre part parce que le changelog est vraiment impressionnant.

D'ailleurs le changelog de référence est celui d'eigenclass qui le maintient manuellement depuis 2 ans. Woh. Tiens c'est .
Attention même si le système de numérotation a changé (plus de numéro pair pour les versions stables et impair pour les autres), c'est version n'est pas destinée à être utilisée en production.

Par contre c'est peut être l'occasion de commencer à mettre à jour ses scripts et de mettre son nez dans les nouvelles features.

Pour que tu puisses tester un peu la bête j'ai fait un petit script shell qui installe ça tout bien, sans virer les versions précédentes de ruby.
Le script récupère le tarball depuis le site, vérifie le hash md5, compile et installe ruby1.9 dans /usr/local/bin.
Un lien symbolic est réalisé : /usr/bin/ruby1.9 afin d'être utilisable pour ceux qui n'ont pas le /usr/local/bin dans leur path.

Voilà, plus d'excuses pour ne pas foncer tester.

mardi, décembre 11 2007

Rails 2

Si tu es là je suppose que c'est pour avoir une information pertinente.

Je vais donc éviter de lancer le classique :
Rails 2 est sorti. Youpi. Bang. Chouette.

Tu sais celui qui te laisse comme deux ronds de flan, qui ne te donne aucune info, et que tu as vu plus d'une dizaine de fois dans ton aggrégateur.
Pour éviter ça, je t'invite à aller voir le seul billet qui vaut le coup et qui te donne de vraies informations sur les nouveautés de rails 2.

Quoi tu es encore là ? Bon, les grands moyens :

redirect_to "http://weblog.rubyonrails.org/2007/12/7/rails-2-0-it-s-done"

Non mais.

lundi, novembre 26 2007

Driver nvidia et kernel 2.6.23

En possession d'une carte graphique nvidia GeForce 7300 GS, je suis confronté aux bugs des drivers propriétaires NVIDIA depuis un moment.
Le dernier driver fonctionnel en date est le 1.0-9755 pour ma carte, les autres faisant systématiquement freezer mon système ; rien que ça.

A chaque changement de noyau, le package nvidia est mis à jour dans la foulée, afin d'éviter aux utilisateurs d'avoir à recompiler leur driver manuellement.
De mon côté j'essaie donc toujours le nouveau driver quelques temps avant de m'apercevoir qu'il me fait toujours freezer.

Mais ce n'est d'habitude pas très gênant puisque j'ai gardé une copie du driver 9755, que je recompile à la mano et ça roule. Normalement.
Sauf qu'en 2.6.23 l'API du kernel a changé, et n'est plus compatible avec les anciens drivers, impossible donc de le recompiler.

Heureusement une bonne âme a patché ce driver afin de faire correspondre les prototype des fonctions du driver avec ceux du kernel.
Tu peux rebuilder les packages si tu n'as pas confiance sinon prends les deux tarball et installe les.

Sous Arch c'est trivial :

# pacman -U nvidia-100.14.09-1-i686.pkg.tar.gz
# pacman -U nvidia-utils-100.14.09-1-i686.pkg.tar.gz

Une fois les deux drivers installés tu n'es pas forcément encore au bout de tes peines. De mon côté j'ai viré l'ancien driver nvidia et recharger le nouveau :

# depmod -a 

Pour vérifier les dépendances des modules du noyau.

# modprobe -r nvidia

Pour virer l'ancien driver nvidia.

# modprobe nvidia

Pour charger le nouveau.

Ensuite j'ai tenté un startx en user, mais ça ne fonctionnait pas, j'ai eu droit à un message de la sorte : "The xorg server ABI is newer than the driver version and so X will not open."

Comme suggéré plus loin dans le message j'ai donc tenté de lancer mon serveur X sans cette option :

$ startx -- -ignoreABI

Ça fonctionne mais les plantages reviennent. J'ai donc décidé de downgrader mon serveur X.
Du package xorg-server 1.4-4 (dans le dépôt extra) je suis passé au 1.2.0-5 (dans le dépôt current).

Avant que cela ne fonctionne pour de bon, j'ai aussi downgradé les packages xf86-input-keyboard en version 1.1.1 et xf86-input-mouse en 1.2.1.

Dorénavant ça fonctionne mais plus question d'utiliser le module glx, qui est indispensable pour compiz entre autre. J'essaierai de chercher pourquoi plus tard car l'exposé me manque déjà :-)

Pour éviter de trembler à chaque mise à jour, j'ai décidé d'arrêter de mettre à jour mon X et les drivers nvidia empaquetés, au moins pendant quelques temps.
Pour ce faire sous Arch, il faut ajouter la variable IgnorePkg dans le pacman.conf de la sorte :
IgnorePkg = nvidia nvidia-utils xorg-server

En espérant que ce billet permette à quelqu'un de perdre moins de temps que moi à résoudre ce désagrément.

- page 1 de 2