Entre OS X El Capitan (10.11) et Sierra (10.12) le driver de gestion du clavier a été complètement revu par Apple. L’outil Karabiner qui nous permettait de jouer directement au niveau du driver a dû être complètement réécrit par Takayama Fumihiko ce qui a pris un certain temps. Le nouveau nom de cette application est Karabiner-Elements.
La référence en la matière c’est cet article pour Microsoft® ODBC Driver 11 for SQL Server. Une majorité d’information reste valide et il ne s’agit ci-dessous que d’une mise à jour.
Le plus dur c’est de prendre la bonne version des drivers ODBC sur le site de Microsoft. En effet, en version 11 seule une version RedHat était disponible et heureusement compatible. Par contre, en version 13, les librairies RedHat ne sont plus compatibles. Cependant Microsoft propose désormais plusieurs versions du driver dont une « Ubuntu » plus proche de Debian que de RedHat. Elle est disponible à cette adresse : https://download.microsoft.com/download/2/E/5/2E58F097-805C-4AB8-9FC6-71288AB4409D/msodbcsql-13.0.0.0.tar.gz.
Cette catégorie contient tous les messages de la famille. Pour pouvoir les voir tous, il suffit de se connecter avec les identifiants que nous vous avons transmis en suivant ce lien. Si votre navigateur vous informe que le certificat n’est pas conforme et qu’il existe des risques de sécurité, n’hésitez pas à accepter ce certificat : il n’est pas dangereux.
Mise à jour Janvier 2013 : A partir de Mac OS X Sierra, la gestion du clavier par l’OS a complètement changé ce qui rend cette solution inexploitable. Karabiner a dû être réécrit. Depuis près d’un mois, cette nouvelle version permet de gérer à nouveau notre clavier correctement sous Sierra et suivant. Apprenez-en plus en lisant : Clavier français avec Microsoft Remote Desktop App sous Sierra et plus
Depuis plus d’un an déjà, Microsoft fournit gratuitement une application appelée Microsoft Remote Desktop pour accéder à une machine (souvent sous Windows) à travers RDP, depuis un Mac ou un périphérique iOS ou Androïd. Cette version devrait un jour remplacer une autre application gratuite fournie par Microsoft : Connexion Bureau à Distance pour Mac. De mémoire, cette dernière avait pris son temps pour gérer pleinement les claviers Mac en langue étrangère. Il semble qu’il en est de même pour cette nouvelle App pour qui ce problème ne semble pas une priorité. En effet, pour l’heure cette App considère que vous utilisez un clavier de type PC sur votre Mac.
Comme Microsoft Remote Desktop reste quand même un produit prometteur (en particulier, il supporte RemoteApp depuis un Mac, xfreerdp étant un peu décevant sur ce point), je me suis dit que cela méritait un peu de recherche. Après pas mal de fausses pistes, j’ai trouvé 2 méthodes différentes pour pallier au problème, l’une étant plus élégante que l’autre.
Oser dire qu’on se trompe, c’est selon moi un véritable gage de progrès. Il faut apprendre de ses erreurs et pour cela les reconnaitre. Je passe tellement de temps à essayer de comprendre les petites erreurs du quotidien que mes utilisateurs n’osent pas m’avouer… S’ils savaient que le temps pour corriger leur erreur est tellement plus cours que celui de les identifier ! Psychanalyste : voilà surement une sortie honorable pour un informaticien en réorientation…
Tout ça pour dire que dans le message qui suit, publié initialement le 21/11/2012, il y a des choses vraies mais surtout une grosse erreur d’analyse qu’il m’aura fallu bien du temps à mettre en évidence.
Le SPAM est une plaie. Les solutions techniques se suivent plus ou moins complexes et plus moins contournables. Concernant la limitation de l’usage du protocole SMTP, il y a semble-t-il plusieurs approchent : ceux qui documentent les règles (OVH, Free) et ceux qui en appliquent sans prévenir (Orange). Voici un retour d’expérience avec le FAI Orange, ni pire ni meilleur que d’autres. Depuis qu’on vit dans un monde soi-disant compétitif, la qualité de service n’a plus vraiment de sens : à bien y réfléchir, seul le prix compte ! L’opérateur unique d’État ça pouvait avoir aussi du bon… Il n’y a pas de solution idéale.
Donc, ce jour-là, on commence à me dire que j’ai dû trituré des trucs sur le serveur de courrier parce qu’on commence à recevoir des messages de retour (Authentication required) dès qu’on veut envoyer des messages ou du moins, trop souvent. Généralement, dans ces moments-là, on commence toujours à se tromper de piste, peut-être par manque de confiance en soi : Mais qu’est-ce que j’avais bien pu toucher qui aurait eu comme effet de bord d’empêcher l’envoi de message par un de nos FAI ?
Il est des billets qui ne servent pas à grand si ce n’est juste de bloc-note à mon intention. L’autre jour, déçu du mode de facturation des snapshots sur les VPS OVH, je me suis mis à la recherche d’outils plus radicaux qui me permettraient de redémarrer mon serveur Debian depuis n’importe quelle machine. J’ai fini par tomber sur le couple duplicity/backupninja dont la simplicité de mise en oeuvre est telle que ce billet devrait vous paraitre inutile.
L’autre jour, je devais installer Debian sur une machine Windows. Malheureusement, pas de CD à me mettre sous la main, juste ma clef USB sushi de 4 Go dans ma poche. Je me suis donc mis à la recherche d’un logiciel de boot sur clef USB et je suis tombé sur YUMI (mais il y en a d’autres : SARDU, XBOOT…). Ces outils sont assez merveilleux puisqu’ils vous permettent de créer une clef USB bootable sans détruire les données initialement présentes dessus. Ils permettent par ailleurs de sélectionner la distribution à installer sur la clef (éventuellement plusieurs) et se charge du rapatriement des images ISO de ces distributions si vous le désirez.
Un inconvénient, du moins pour YUMI, c’est que cette capacité à fournir plusieurs distributions sur une même clef casse l’architecture classique d’un simple Debian LiveCD, ce qui rend inopérant le script debian-installer. Dans ce cas, en modifiant quelques lignes ou en réalisant un montage disque, on peut faire tourner le script et parvenir à ses fins.
En effet, si au lancement de la commande debian-installer-launcher (en sudo) vous obtenez :
no suitable d-i initrd image found, aborting. |
vous avez peut-être une chance de vous en sortir en lisant la suite de l’article.
Un ami m’a récemment envoyé un lien pour partager son album Picasa. Malheureusement, j’utilise plutôt iPhoto. Il me fallait donc télécharger toutes les photos de cet album pour les gérer localement. J’ai alors interrogé les moteurs de recherche et je suis tombé sur de nombreuses solutions qui ne me satisfaisaient pas (téléchargement/installation d’un logiciel, besoin d’identifiants google…). Or, il existe une procédure simple et certainement largement connue, dommage que l’on ne tombe pas si simplement dessus. Aussi, n’hésitons pas à la redonner.
Il s’agit de passer par le flux proposé par Picasa. En effet, quand on suit le lien vers l’album, on observe à droite dans l’interface un lien « flux RSS ». Or, iPhoto permet de s’inscrire à des flux de photos. Copier l’adresse du lien puis la coller dans iPhoto permet de récupérer des photos. Si ensuite, vous demandez la suppression de cette inscription au flux, iPhoto vous propose automatiquement de garder une copie des photos ainsi téléchargées.
Elle n’est pas belle la vie ? Non, pas vraiment, car les photos ainsi récupérées sont des miniatures et non les originaux. Heureusement, Picasa a pensé à tout. Il suffit d’ajouter une variable à la fin de l’URL du flux pour récupérer les originaux. Dans le cas présent : &imgmax=d.
Bon, ben voilà, y a plus qu’à… Que dites-vous ? « Ce n’est pas encore le top, car vous ne récupérez pas toutes les images… ». Ah oui ? En effet, Google limite volontairement son système de feed. Vous pouvez encore une fois retirer cette limite en ajoutant : &max-results=9999 ou toute autre valeur qui vous semble convenir pour ce flux.
Pour ceux qui me lisent régulièrement, je fais du multisite WordPress à ma sauce. Or, une des instances que j’héberge ainsi, a une vocation privée : une sorte d’extranet. Pour y parvenir, j’utilise un dispositif simple et efficace qui repose sur des outils particulièrement éprouvés : SSL et l’authentification HTTP Basic. Seulement voilà, les navigateurs de nos jours, pour des raisons bassement mercantiles font tout pour contraindre les propriétaires de site à acquérir des certificats souvent onéreux sans quoi ils effraieront vos usagers en leur disant que votre site n’est pas protégé. Ils vous préviennent aussi que si vous voulez vraiment y accéder, il va falloir lire plein de messages incompréhensibles et cliquer à droite à gauche.
OVH en son temps, proposait des certificats SSL bon marché opérationnels sur leur serveur mutualisé, mais il semble là aussi que le côté bon marché n’ait pas vraiment séduit. J’y vois 2 raisons selon qu’on se place du côté du développeur ou du décideur (les 2 principaux intéressés) :
Bilan, pour pallier à l’impossibilité d’installer un certificat personnel sur un serveur mutualisé, j’ai été contraint d’utiliser mon serveur VPS comme un simple proxy mais avec un certificat valide. Voici le schéma de fonctionnement :
Internet --- HTTPS ---> family.e-gaulue.com --- HTTPS ---> family-direct.e-gaulue.com
(certificat conforme sur VPS) (certificat non conforme du mutu OVH) |
La suite de cet article décrit cette installation.
…
On trouve un peu de documentation sur la transformation d’un fichier .vmdk en .vdi. Qui plus est, cette simple transformation n’est pas toujours suffisante. En effet, en fonction de votre installation Debian, votre système peut refuser de booter car les drivers qui lui sont présentés ne sont pas les mêmes d’une plate-forme de virtualisation à l’autre.
Dans le cas présent, cette méthode est valable pour Mac OS X Lion.
Tout d’abord, il vous faut récupérer le bon fichier vmdk, celui qui contient les données. Sur des plates-formes VMware récentes, le fichier correspondant à la VM pipo est censé se nommer pipo-flat.vmdk.
Une fois récupéré le fichier, nous allons utiliser la technique de conversion QEMU, je n’ai jamais réussi à faire fonctionner celle qui consiste à demander directement à VirtualBox de faire la conversion.
Il faut donc QEMU. Personnellement, j’utilise MacPort pour récupérer ce type de programme.
> sudo port install qemu |
Attention, ça peut être long. Une fois terminé, on convertit notre .vmdk en .img (une image disque classique identique à ce que nous fournirait la commande dd).
> qemu-img convert -p pipo-flat.vmdk pipo.img |
Attention, c’est assez long (fonction de la taille du disque) et vous n’avez pas d’autre moyen de suivre la progression qu’en ajoutant l’option -p. Enfin, vous transformez cette image en image .vdi grâce à VirtualBox (que je suppose installé).
> VBoxManage convertfromraw --format VDI pipo.img pipo.vdi |
Là encore, il va falloir attendre mais ls -l vous donnera des indications sur l’état d’avancement.
Si vous êtes un fan de l’esprit « J’ai de la chance », vous pouvez y aller : vous créez votre VM que vous associez au fichier .vdi obtenu. On ne sait jamais… Des fois, sur un malentendu…
Dans mon cas, j’ai reçu ce message :
Gave up waiting for root device. Common problems:3f06f945760 - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Check root= (did the system wait for the right device?) - Missing modules (cat /proc/modules; ls /dev) Alert! /dev/disk/by-uuid/XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX does not exist. Dorpping to a shell! BusyBox v1.13.3 (ubuntu 1:1.13.3-1ubuntu11) built-in shell (ash) Enter 'help' for a list of built-in commands. |
En gros, je l’ai traduit par : « je n’ai pas trouvé ton disque » et j’en ai déduit que certainement les drivers émulés par VMware et VirtualBox pour le SATA ne devaient pas être les mêmes.
J’ai donc décidé de faire appel à mon couteau suisse préféré : SystemRescueCD.
Après téléchargement, on crée une machine virtuelle avec un CD qui pointe vers l’iso de SystemRescueCD et un disque SATA qui pointe vers notre fichier pipo.vdi en vérifiant que l’amorce se fera sur le CD.
Une fois la machine virtuelle lancée, SystemlRescueCD vous demandera de spécifier votre langue (pratique pour le clavier) et vous fournira une invite.
fdisk -l vous fournira une liste des partitions de votre image disque. Il vous reste à identifier la partition system, à la monter (dans mon cas /dev/sda1) et à chrooter dedans.
> mkdir pipo > mount /dev/sda1 pipo > chroot pipo /bin/bash |
On se retrouve alors dans notre système, mais attention, il exécute le noyau de SystemRescueCD. Reste à reconstruire un initramfs qui convient. Pour cela, il convient d’aller faire un tour dans /boot pour identifier votre noyau.
> ls /boot -rw-r--r-- 1 root root 655316 Oct 17 2010 abi-2.6.32-25-generic-pae -rw-r--r-- 1 root root 116502 Oct 17 2010 config-2.6.32-25-generic-pae drwxr-xr-x 2 root root 4096 Nov 17 2010 grub -rw-r--r-- 1 root root 2429568 Sep 20 20:23 initrd.img-2.6.32-25-generic-pae -rw-r--r-- 1 root root 1730990 Oct 17 2010 System.map-2.6.32-25-generic-pae -rw-r--r-- 1 root root 1200 Oct 17 2010 vmcoreinfo-2.6.32-25-generic-pae |
Ça sent fort le noyau de version 2.6.32-35-generic-pae. Maintenant, sauvegardons l’ancien initrd et générons-en un nouveau :
> cd /boot > mv initrd.img-2.6.32-25-generic-pae initrd.img-2.6.32-25-generic-pae.old > update-initramfs -k 2.6.32-25-generic-pae -c mkinitramfs: missing sda root /dev/sda1 /sys entry mkinitramfs: workaround is MODULES=most mkinitramfs: Error please report the bug update-initramfs: failed for /boot/initrd.img-2.6.32-25-generic-pae |
Ah oui… j’oubliais… Avec cette méthode d’exécution chroot de votre système, tous les montages n’ont pas eu lieu. Ici, il semble manquer /sys. Qu’à cela ne tienne, il suffit de le monter.
> mount /sys > update-initramfs -k 2.6.32-25-generic-pae -c |
Reste alors à éteindre la machine virtuelle, supprimer le CD correspondant à SystemRescueCD et redémarrer la machine virtuelle.
Si vous avez bien suivi, cette méthode peut aussi s’appliquer à la réalisation d’un P2V (transfert d’une machine physique vers une machine virtuelle) d’un système basé sur Debian, car on peut aller bien au-delà de la simple reconstruction de l’initramfs en installant un nouveau noyau compatible VM (pae) par exemple.