Ashram de Swâmi Petaramesh - geekerie

Shit happens

Petaramesh — Sat, 14 Jun 2008 14:35:00 +0200

Alors voilà, j'ai voulu rajouter un module Bluetooth acheté à un chinois sur Ebay à mon portable Acer Aspire 3104WLMi...

Le module Bluetooth, c'est la petite carte minuscule avec un petit bout de câble, en bas au milieu, à gauche de la pièce d'un Euro qui donne l'échelle (cliquer sur l'image pour agrandi un poil)

Et pour rajouter un truc comme ça dans un portable Acer, c'est pas comme s'il fallait tout démonter, hein ? Ah si ? C'est même le truc pour lequel il faut le plus tout démonter, même la carte mère, même le radiateur du processeur en ruinant son interface thermique ? Ah oui. Ben hein, c'est pô de chance...

Surtout pour s'apercevoir en fin de compte que le connecteur de la carte vendue par le chinois est plus gros que celui de la carte mère du portable, et qu'il n'y a strictement aucun moyen de brancher l'un sur l'autre en l'état.

Shit happens.

You've got mail !

Petaramesh — Fri, 13 Jun 2008 08:48:00 +0200

Les petits veinards qui décident d'installer GNU/Linux sur leur portable ces jours-ci ne se doutent pas de la chance qu'ils ont : La plupart des fonctions de la plupart des portables (veille, hibernation, touches "[Fn]" de réglage de luminosité, de volume...) fonctionnent out of the box sans qu'il soit besoin de rien faire de spécial.
Il n'en allait pas de même il y a quelques années, époque où gérer avec GNU/Linux les spécificités des portables relevait encore de l'exploit.

Il y a cependant quelques petites choses que le linuxien de base ne pensera le plus souvent même pas à essayer de faire marcher, comme par exemple les touches spécifiques situées en dehors du clavier principal, et sur lesquelles on trouve des symboles du genre courrier, navigateur Internet, maison, etc.

Si vous avez un portable Acer Aspire, par exemple, vous avez 4 touches de ce genre à côté du bouton de mise sous tension, l'une d'elles étant la touche courrier qui, si on la regarde bien, comporte même un voyant LED.

Ne serait-il pas sympathique que cette LED clignote quand on a du courrier non lu ?

Nous allons voir dans cet article qu'il n'est franchement pas difficile de contrôler le clignotement de ce voyant, et de l'utiliser pour signaler la présence de nouveau courrier.^[1] Pour l'utilisation des touches elles-mêmes, nous verrons peut-être ça dans un prochain article...

Cet article est consacré à un portable de type Acer Aspire 3104 WLMi sous Kubuntu 8.04 Hardy, mais peut également être valable pour d'autres modèles, et même des portables de certaines autres marques qui peuvent aussi être gérés avec les pilotes Acer.

Si vous avez installé Ubuntu Hardy sur un portable Acer, il y a de bonnes chances que le module acer_acpi ait été automatiquement chargé. Si c'est le cas, vous verrez dans le répertoire virtuel /proc un sous-répertoire /proc/acpi/acer contenant divers pseudo-fichiers, dont un fichier "mailled".

# ls -l /proc/acpi/acer/
total 0
-rw-r--r-- 1 root root 0 2008-06-13 08:43 brightness
-rw-r--r-- 1 root root 0 2008-06-13 08:43 interface
-rw-r--r-- 1 root root 0 2008-06-13 08:43 mailled
-rw-r--r-- 1 root root 0 2008-06-13 08:43 threeg
-rw-r--r-- 1 root root 0 2008-06-13 08:43 version
-rw-r--r-- 1 root root 0 2008-06-13 08:43 wireless

Si vous ne voyez pas ce répertoire, vérifiez avec la commande "lsmod" que le module "acer_acpi" est chargé, sinon tentez de le charger avec la commande "modprobe acer_acpi".

# lsmod | grep acer
acer_acpi              18112  0
led_class               6020  1 acer_acpi
wmi_acer                9644  1 acer_acpi

Si vous voyez le fichier /proc/acpi/acer/mailled, essayez donc (comme root) :

echo 1 > /proc/acpi/acer/mailled
echo 0 > /proc/acpi/acer/mailled

Amusant, n'est-ce pas ?

Nous avons quand même un petit problème : Seul root peut normalement écrire dans ce fichier (donc contrôler la LED), et nous voudrions bien pouvoir l'utiliser pour signaler la présence de courrier pour un utilisateur "ordinaire".

On pourrait envisager de "chmod 666 /proc/acpi/acer/mailled" pour autoriser n'importe quel utilisateur à contrôler la LED, ce qui ne pose pas de problème de sécurité, mais /proc est un système de fichiers virtuel, et ce réglage disparaîtrait au prochain reboot, ou à la prochaine suspension ou hibernation de la machine.

Le plus simple pour contourner ce problème est alors de contrôler la LED via un petit script "/usr/local/bin/mail-led" que l'on appellera à travers "sudo", tout en indiquant à sudo qu'il peut exécuter ce script en tant que root, depuis n'importe quel utilisateur et sans demander de mot de passe. Voici le contenu du script "/usr/local/bin/mail-led" que je vous propose :

# Sets Acer mail LED on or off
#
# Needs to be run as root, use sudo with an /etc/sudoers entry such as:
# ALL ALL=NOPASSWD: /usr/local/bin/mail-led
#
[ $# -eq 1 ] || exit 1
[ -w /proc/acpi/acer/mailled ] || exit 1

case $1 in
        0|no|NO|No|off|OFF|Off|false|FALSE|False)
                echo 0 > /proc/acpi/acer/mailled
                ;;
        1|yes|YES|Yes|on|ON|On|true|TRUE|True)
                echo 1 > /proc/acpi/acer/mailled
                ;;
        *)
                exit 1
                ;;
esac
exit 0

Après l'avoir sauvegardé, rendez-le exécutable pour n'importe quel utilisateur : "chmod 755 /usr/local/bin/mail-led", puis utilisez la commande "visudo" qui appellera votre éditeur de texte standard pour vous permettre de modifier le fichier "/etc/sudoers".
À la fin de ce fichier, rajoutez simplement la ligne :

ALL     ALL=NOPASSWD: /usr/local/bin/mail-led

...et sauvegardez.

Essayez alors, depuis un terminal "utilisateur ordinaire" :

sudo mail-led on
sudo mail-led off

Ça devrait fonctionner, sans vous demander de mot de passe.

Maintenant que nous pouvons contrôler la LED à l'aise Blaise, il n'y a plus qu'à utiliser l'un des nombreux petits logiciels "notificateurs de courrier" disponibles, pour peu que celui-ci permette d'exécuter une commande arbitraire (pour allumer la LED) quand il détecte du nouveau courrier, et une autre commande (pour éteindre) quand il n'en détecte plus.

Sous KDE, le package "kbiff" fera parfaitement l'affaire. Sous Gnome ou d'autres environnements, vous pouvez utiliser le package "mail-notification".^[2] Vous n'avez plus qu'à configurer ce logiciel pour qu'il appelle "sudo mail-led on" pour signaler la présence de nouveau courrier, et, bien sûr "sudo mail-led off" quand il n'y en a plus.

Vous devrez également configurer dans ce logiciel les paramètres de votre serveur de courrier et de votre boîte-aux-lettres, puisque ce logiciel de notification est indépendant de votre "client mail" habituel. (Pour cette raison, il pourra y avoir un décalage entre le moment où vous lisez le courrier et le moment où la LED s'éteindra, puisqu'il faudra attendre que le logiciel de notification revérifie votre boîte pour qu'il se rende compte qu'il n'y a plus de nouveau courrier).

Moi, je trouve ce petit truc super-pratique ;-)

Notes

[1] Sur une machine ne disposant pas de LED "spéciale", il existe des outils permettant de contrôler le clignotement des LEDs habituelles du clavier (NumLock, etc...)

[2] Il existe aussi des packages spécialement "orientés gmail", comme chekckgmail, kcheckgmail ou kgmailnotifier...

Dent bleue

Petaramesh — Tue, 10 Jun 2008 16:40:00 +0200

Je fais mumuse depuis quelques jours avec du Bluetooth sous GNU/Linux, et je constate que la chose y fonctionne avec une facilité déconcertante : Impeccable pour transférer photos, musique et carnet d'adresses avec son téléphone mobile.

Dans KDE, on peut explorer les périphériques bluetooth directement avec Konqueror et coupier / copier / coller des fichiers comme on le ferait sur un répertoire monté en réseau.

Mais il y a aussi une petite chose couplée à KBluetooth que je trouve extrêmement utile : KBlueLock : Ce machin active l'économiseur d'écran et verrouille l'écran dès qu'un périphérique bluetooth choisi disparaît. En pratique, si on "choisit" comme périphérique son téléphone mobile, la portée du bluetooth étant d'une dizaine de mètres gromaxi, il suffit de s'éloigner de sa bécane téléphone mobile en poche ou à la ceinture pour que l'écran se verrouille aussitôt qu'il "voit" qu'on est parti :-)

Plus besoin de régler des délais d'économiseur d'écran très courts, et on peut même régler le machin pour qu'il déverrouille l'écran tout seul dès que le téléphone revient dans le coin. Magique ! ;-)

Pour ceux qui n'utilisent pas KDE mais Gnome, on peut faire la même chose en installant le package "blueproximity".

Hibernatus

Petaramesh — Wed, 28 May 2008 18:03:00 +0200

Depuis que les CNILonautes ont été placés en hibernation dans leur caisson cryogénique en 1978 et n'en sont jamais ressortis, l'idée a fait son chemin.

C'est ainsi que désormais, Ubuntu gère très convenablement l'hibernation (et la suspension) des ordinateurs portables. Mais qu'est-ce donc ?

Les ordinateurs portables fonctionnant sur de misérables petites batteries pouilleuses, leur autonomie est fortement limitée. On a donc cherché dès l'origine à augmenter cette autonomie par diverses méthodes, la plus évidente étant de mettre en "veille" ou d'éteindre l'ordinateur dès qu'on ne l'utilise pas.

Eteindre l'ordinateur et le rallumer pose cependant deux problèmes :

Celui du temps nécessaire à l'extinction complète et au redémarrage (boot, ouverture de session...)
Celui de pouvoir retrouver les choses dans l'état exact où on les avait laissées (connexions réseau, affichage, documents ouverts...)

En l'absence de solution à ces problèmes, devoir éteindre et rallumer un ordinateur représente une importante perte de temps et est donc peu praticable.

Des méthodes "améliorées" ont donc été mises au point, et leur usage n'est d'ailleurs pas limité aux seuls ordinateurs portables - on peut très bien les utiliser avec une machine de bureau pour en limiter autant que possible la consommation électrique quand on ne s'en sert pas, par exemple.

Les versions récentes de GNU/Linux gèrent très bien ces méthodes sur les ordinateurs dont le matériel (ACPI) (et les périphériques !) les supportent, et Ubuntu Hardy sait aussi bien effectuer la suspension que l'hibernation des 3 modèles très différents de portables sur lesquels je les ai essayées.

La suspension "en RAM"

La suspension en RAM est la méthode la plus rapide, mais la moins complète. Elle consiste à placer les périphériques du système ^[1] soit :

Dans un état de "sommeil" à très faible consommation d'énergie
ou complètement hors-tension
ou à les laisser en fonction

...selon ce que chaque périphérique et le BIOS de la machine permettent, puis à interrompre le fonctionnement du processeur, laissant uniquement la mémoire RAM alimentée et rafraîchie, ce qui consomme très peu d'énergie.

Dans cet état, l'autonomie de la batterie du portable peut passer de quelques heures à plusieurs jours ; toutefois la machine n'est pas "éteinte" et continue de consommer. Une fois la batterie complètement vide, elle s'éteindra "pour de bon" ce qui aura sur le système un effet à peu près équivalent à ce qu'aurait eu une coupure de courant brutale, à ceci près que l'état des systèmes de fichiers sera meilleur au redémarrage (puisque les systèmes de fichiers auront été "synchronisés" juste avant la mise en suspension et qu'aucune écriture sur disque ne pouvait être en cours durant la suspension).

Le "réveil" de la machine depuis l'état de suspension est rapide (quelques secondes), puisque la mémoire RAM est restée chargée. Il n'y a pas de "boot" à faire ; le système doit "seulement" redémarrer son processeur et remettre les périphériques dans leur état de fonctionnement antérieur - ce qui est la partie le plus longue et la plus susceptible de causer des problèmes.

L'"hibernation" sur disque

L'hibernation sur disque est une méthode complète qui permet de réellement éteindre la machine, lui permettant de demeurer en l'état sans consommation électrique pour une durée indéfinie.
La mise en hibernation commence par la suspension de l'exécution de toutes les tâches en cours, puis l'enregistrement de l'état actuel des périphériques (quand cela est possible), puis la "compression" du contenu de la mémoire RAM suivie de l'écriture de cette "image mémoire compressée" dans la partition de swap. Une fois tout ceci fait, la machine est alors (complètement) éteinte et peut donc rester dans cet état indéfiniment.

Le "réveil" de la machine depuis l'état d'hibernation est plus long et plus complexe que pour la simple suspension. Pour le BIOS de l'ordinateur, c'est d'abord une mise en route "ordinaire", le chargement du bootloader (grub, lilo...), suivi du chargement de l'initramfs et du démarrage du noyau. Ça commence donc réellement comme un boot ordinaire.

Ensuite, le programme "resume" est appelé et decouvre la présence de l'image mémoire compressée dans la partition de swap. Le programme resume prend alors le pas sur la séquence de démarrage habituelle, il recopie et décompresse l'image mémoire sauvegardée en RAM, réinitialise les périphériques à partir de leur état sauvegardé (un peu comme lors d'un réveil de suspension), puis reprend l'exécution à partir de l'image restaurée en mémoire : l'ordinateur se trouve alors (théoriquement) dans l'état exact qui était le sien juste avant la mise en hibernation : utilisateur connecté, systèmes de fichiers montés, connections réseau, applications et fichiers ouverts, etc.^[2]

N.B.: Il est possible de booter normalement sans reprise une machine qui a été hibernée si l'on passe au noyau le paramètre de boot "noresume". Dans ce cas, la machine bootera "normalement" dans l'état qui aurait été le sien après avoir subi une coupure de courant brutale.

Problèmes techniques

Les plus gros problèmes rencontrés avec les systèmes de suspension ou d'hibernation sont ceux relatifs aux périphériques du système. En effet, en fonctionnement normal, ils ont été initialisés par le BIOS, puis par leur pilote, puis leur état a été éventuellement modifié par l'application qui les utilise, etc.
Au "réveil", l'application (qui n'a rien vu) s'attend à retrouver les périphériques dans l'état exact où ils étaient auparavant, sans avoir besoin de les initialiser à nouveau.
Ceci implique que le système de suspension / hibernation / réveil doit être en mesure de déterminer et enregistrer l'état précis de tous les périphériques (par exemple mode vidéo en cours, vitesse actuelle du port série, volume réglé sur la carte son, firmware chargé dans une carte Wi-Fi, etc...) avant de les éteindre, et de restaurer cet état précis au réveil, avant de rendre la main au fonctionnement normal du système. Or ce n'est pas toujours possible, certains périphériques (surtout les anciens ou ceux non prévus pour des ordinateurs capables d'hibernation) étant capables d'exécuter une commande de changement d'état, mais incapables de faire un "rapport" de leur état courant au système. D'autres périphériques peuvent avoir des états tellement complexes (carte vidéo) qu'il n'est pas forcément possible de récupérer l'ensemble des informations nécessaires.
On peut alors rencontrer des problèmes avec de tels périphériques,^[3] comme avoir un périphérique qui ne fonctionne plus au réveil, une image vidéo qui ne se rétablit pas complètement, une connexion réseau qui refuse de revenir, etc.
Ceci est d'autant plus vrai dans le mode hibernation, où les périphériques sont complètement éteints que dans le mode suspension où certains périphériques peuvent être placés en mode sommeil et conserver eux-mêmes leur "état" - ils ne sont pas complètement éteints.
De gros progrès ont été faits, et les suites logicielles d'hibernation et de réveil comportent des kyrielles de "méthodes spéciales" pour différents types de périphériques^[4] ; toutefois, il peut encore parfois demeurer des problèmes. Vous vous montrerez indulgent après avoir lu cet article ;-)

Pièges à prévoir

Problèmes liés à la suspension :
- Lors de la suspension, le système n'est pas complètement hors-tension. Il peut donc continuer à chauffer (et sur certains modèles, se décider à ventiler) dans certaines situations. De plus, il est possible que l'appui accidentel sur une touche^[5] provoque le réveil de la machine. Si vous enfermez votre portable suspendu dans une housse ou un sac et que celui-ci se réveille inopinément, ou chauffe, il risque de surchauffer et de griller faute de ventilation et par excès d'isolation ! Étudiez bien votre machine pour connaître son comportement avant de vous décider ou non à la trimballer suspendue dans un sac (ce que je fais sans problème régulièrement avec mon Asus EeePC par exemple).

Problèmes liés à l'hibernation :
- Pour pouvoir hiberner votre machine, vous devez disposer d'une partition de swap de taille appropriée, typiquement grosso-modo 2 fois la taille de la RAM de votre machine, et l'ensemble de vos périphériques doit accepter l'opération sans casse (faut essayer ;-)

Problèmes liés à la suspension et à l'hibernation :
- Retrait ou ajout de périphériques : Quand votre ordinateur est hiberné, et dans une certaine mesure, suspendu, il ne peut pas se rendre compte de l'ajout ou de la suppression de nouveaux périphériques (branchement ou débranchement d'un câble secteur, d'un bidule USB, etc). Il se peut qu'au réveil il ne puisse pas effectuer les actions nécessaires à ce changement dont il ne se sera pas aperçu (changement du mode de gestion d'énergie, prise en compte du nouveau périphérique...). Pour cette raison, je conseille, si vous prévoyez de déplacer votre portable après l'avoir suspendu ou hiberné, de toujours retirer les périphériques (cordon secteur, clés USB...) avant de le suspendre, et de toujours le réveiller complètement avant de les reconnecter, de manière à ce qu'il soit toujours dans le même état précis à l'endormissement et au réveil et qu'il prenne en compte les changements de périphériques alors qu'il est "pleinement réveillé".
- Systèmes de fichiers sur périphériques USB : À la suspension ou l'hibernation, le système perd le montage de tous les systèmes de fichiers sur périphériques USB, ce qui peut poser problème (perte de données) s'il y a des fichiers ouverts ou des caches non vidés pour ces périphériques. Il est donc conseillé de démonter et ôter les périphériques de stockage USB avant de suspendre ou d'hiberner. Sur les noyaux 2.6.24 et supérieurs, la fonction "usb persist" permet de résoudre le problème et de conserver les montages USB au réveil.^[6] Ceci marche particulièrement bien avec mon Asus EeePC pour conserver l'accès à sa carte mémoire SD à travers une suspension ou une hibernation.^[7]

Considérations de performances

Si la suspension et son réveil sont généralement très rapides, l'hibernation et son réveil peuvent prendre beaucoup de temps. Sur une machine relativement peu puissante, il peut être bien plus long de l'hiberner que de l'arrêter normalement, et bien plus long de la réveiller que de faire un démarrage normal "à froid".
Ceci remet fortement en question l'intérêt de l'hibernation puisqu'elle ne fait plus gagner aucun temps, et peut même en faire perdre, le seul intérêt demeurant alors est de retrouver le système dans l'état exact où on l'avait laissé, intérêt toutefois minoré par la capacité de KDE à restaurer au démarrage toutes les applications (ou presque) qui étaient en cours quand il a été arrêté.

Il y a moyen (voir plus bas) d'agir sur le temps de mise en hibernation, mais ce sera au prix de la vitesse et de la réactivité de la machine après son réveil.

En effet, une machine réveillée après hibernation se montrera pour un temps plus lente et moins réactive qu'une machine fraîchement bootée, notamment parce que son cache-disque et ses buffers auront été vidés et qu'une partie de sa mémoire aura été (et sera encore) swappée...

Considérations de sécurité

La suspension et l'hibernation peuvent avoir d'importantes conséquences sur la sécurité d'un portable, ne serait-ce que parce que toutes deux réveillent le système dans l'état où il était à sa mise en veille, toutes applications et documents ouverts, et notamment que l'utilisateur n'a pas besoin de rouvrir sa session en tapant son login et son mot de passe.
Normalement, une session graphique au réveil soit se retrouver en mode "verrouillé et économiseur d'écran activé", ce qui nécessite la frappe du mot de passe de l'utilisateur pour accéder à la session, mais j'ai vu des cas plus ou moins imprévisibles où la session n'était pas verrouillée au réveil.
D'éventuelles sessions ouvertes sur des "consoles texte" ne seront pas verrouillées au réveil de la machine.

La suspension d'une machine peut être considérée du point de vue de la sécurité comme strictement équivalente à laisser la machine allumée avec la session verrouillée par un économiseur d'écran, ce qui est une sécurité assez "moyenne", et encore faut-il que l'économiseur d'écran s'active effectivement...

L'hibernation d'une machine a des conséquences très différentes :
- Tout d'abord, l'hibernation d'une machine est compatible avec une installation sur un disque complètement chiffré (LVM chiffrée contenant également le swap), ce qui protège pleinement la machine pendant son hibernation si on est dans un tel cas de figure.
- Comme la machine doit booter avant de se réveiller, elle pourra être verrouillée par un éventuel mot de passe de BIOS (qui n'offre par ailleurs pas une sécurité bien grande).
- Si la machine est installée sur LVM chiffrée, il faudra déverrouiller la LVM (comme lors d'un boot normal) pour pouvoir réveiller une machine hibernée.

L'hibernation d'une machine au swap non chiffré pose de sérieux problèmes de sécurité !
- Pensez qu'au moment de la mise en hibernation, absolument tout ce qui se trouve en mémoire vive est copié sur le swap et y demeurera éventuellement un temps indéfini, y compris tous documents ouverts ainsi que des éléments qui sont d'habitude éventuellement protégés par le noyau pour ne pas être écrits sur le swap en fonctionnement normal, comme des clés de chiffrement, des mots de passe, etc...
- Le programme swsusp possède une fonction de chiffrement de l'image mémoire avec une "clé jetable", mais celle-ci ne semble pas active sur Ubuntu 8.04. Quoi qu'il en soit, cette fonction permet de rendre inutilisable ce qui avait été écrit sur le swap après le réveil de la machine, mais elle reste entièrement vulnérable pendant qu'elle est en état hiberné, puisque la clé de déchiffrement doit également être stockée dans le swap pour permettre le réveil de la machine. Ceci de mon point de vue proscrit l'usage de l'hibernation pour toute machine pouvant contenir des données confidentielles, sauf si l'hibernation est effectuée sur un swap situé à l'intérieur d'une LVM entièrement chiffrée.
- L'utilisation d'un swap dans une LVM chiffrée protège de ce problème, mais offre une sécurité moindre que celle apportée par un swap chiffré séparément par une clé aléatoire générée à chaque boot (ce qui est incompatible avec l'hibernation...). En effet, dans ce dernier cas, après chaque boot le contenu précédent du swap est irrémédiablement perdu pour tout le monde, tandis que dans le cas du swap en LVM chiffrée, celui qui obtiendrait par force ou par ruse la clé de déchiffrement de la LVM pourrait alors aller farfouiller également dans les anciens contenus du swap.

Résolution de problèmes

Si vous avez une machine qui vous dit swsusp: Not enough free memory quand vous tentez de l'hiberner, puis se réveille aussitôt, essayez :

echo 2048248 > /sys/power/image_size

...et recommencez.^[8]

Si vous trouvez que votre machine est bien trop longue à hiberner et à se réveiller, essayez :

echo 0 > /sys/power/image_size

...vous obtiendrez en contrepartie une machine qui hibernera plus vite mais sera plus lente pendant un temps après s'être réveillée.

Une fois que vous avez trouvé la commande qui vous convient, ajoutez-la une fois pour toutes dans /etc/rc.local.

Pour plus d'infos à ce sujet, installer le package linux-doc-2.6.24 et lire le document /usr/share/doc/linux-doc-2.6.24/Documentation/power/swsusp.txt.gz.

Voilà, on dira que ça sera tout pour cette fois ;-)

Notes

[1] Affichage, carte vidéo, carte réseau, modem, disques, contrôleurs de disque, contrôleurs USB, etc...

[2] Pour plus d'infos sur l'hibernation, installer le package linux-doc-2.6.24 et lire les documents /usr/share/doc/linux-doc-2.6.24/Documentation/power/swsusp*.

[3] En particulier certains périphériques qui utiliseraient des pilotes Windows via ndiswrapper risquent de ne pas aimer...

[4] Jetez donc un coup d'oeil au contenu des répertoires /etc/acpi/suspend.d et /etc/acpi/resume.d...

[5] Avec certains portables, cela peut se produire si on appuie fort sur le "couvercle", même fermé...

[6] Pour plus d'infos sur "usb persist", installer le package linux-doc-2.6.24 et lire le document /usr/share/doc/linux-doc-2.6.24/Documentation/usb/persist.txt.gz.

[7] Le lecteur de carte mémoire de l'Asus EePC a en interne une interface USB...

[8] Sur l'un de mes portables, j'utilise la valeur 268435456.

Retailler à la volée une LVM chiffrée LUKS

Petaramesh — Tue, 27 May 2008 11:58:00 +0200

(English abstract at end.)

Et encore un article en bas moldave qui s'annonce ;-)

J'explique ci-dessous comment il est possible d'agrandir à la volée une LVM chiffrée LUKS sur laquelle est installé tout un système GNU/Linux chiffré (ici une Ubuntu 8.04 Hardy).

Si cela vous parle autant que l'élevage du Yaka-Faucon en Patagonie septentrionale, passez votre chemin ;-)

Ma problématique pour cette manip' était la suivante : un ordinateur portable entièrement chiffré (sauf /boot) dont le disque dur était partitionné de la manière suivante :

sda1: /boot (non chiffré)
sda2: LVM chiffrée contenant le root filesystem et la quasi-totalité des volumes logiques usuels (/var, /home...)
sda3: un /tmp chiffré utilisant une clé aléatoire générée au boot.
sda4: un swap chiffré utilisant une clé aléatoire générée au boot.

L'objectif de la manip était d'"incorporer" le /tmp et le swap à l'intérieur de la LVM chiffrée principale et non plus à l'extérieur de celle-ci, de manière à pouvoir utiliser la fonction "hibernation sur disque" de la machine, qui nécessite en pratique que le déchiffrement du root filesystem au boot permette également l'accès au swap sur lequel est stocké le fichier de reprise, le plus simple étant alors de mettre le swap dans la même LVM chiffrée que le reste des partitions.

La même manip pourrait être utilisée à d'autres fins, par exemple augmenter l'espace disque utilisable après avoir recopié l'ensemble d'un système chiffré sur un disque neuf plus gros.

Pour que ça soit plus drôle, nous allons faire ça en live, sur le système tournant et bien chaud, et sans recourir au boot sur un CD-Rom.

Cet article est en partie inspiré de l'article de Bodhi.Zazen : How to Resize a LUKS Encrypted File System.

Avertissement : Ce type de manipulation est susceptible de provoquer la perte irréparable de l'ensemble des données présentes sur votre disque, si vous faites la moindre erreur durant les opérations, ou si j'ai fait la moindre erreur en les décrivant ! Faites une copie de sauvegarde de l'ensemble de votre système, vous êtes seul(e) responsable des dégâts que vous vous apprêtez à causer, même si une erreur s'est glissée dans mon article et si c'est moi qui vous ai foutu dedans. À vos risques et périls ! ;-)

Dans mon cas particulier, je vais donc commencer par supprimer les partitions sda3 et sda4, dont le contenu sera perdu durant l'opération, mais cela est sans importance s'agissant d'un /tmp et d'un swap, puis je vais étendre la partition sda2 sur laquelle réside la LVM chiffrée afin de récupérer dedans l'espace laissé libre par les partitions supprimées, puis j'agrandirai le container chiffré qui occupe cette partition, puis j'agrandirai le volume physique de LVM qui est dedans, ce qui ajoutera à la LVM chiffrée l'espace ainsi récupéré, permettant alors d'y créer de nouveaux volumes logiques, ou d'étendre les volumes logiques existants.

Dans le cas général, on considèrera que nous disposerons d'une manière ou d'une autre d'espace disque libre immédiatement après la partition contenant la LVM chiffrée à étendre.

Dans mon cas particulier, il me faut commencer par désactiver le swap (swapoff -a) dont je vais supprimer la partition, démonter le /tmp, et le démontage du /tmp nécessite de fermer toute session graphique X (KDE ou Gnome) et d'arrêter le gestionnaire de session graphique (invoke-rc.d kdm stop ou invoke-rc.d gdm stop selon le cas), ce qui me fera donc travailler en mode console texte. Il me faudra ensuite désactiver les volumes chiffrés correspondants avant de pouvoir en supprimer les partitions.
Dans le cas général, si vous n'avez pas besoin de démonter une partition nécessaire, vous pouvez travailler dans un terminal depuis une session graphique.

Retaillage des partitions

Commençons donc par décrire l'étape de suppression des partitions inutiles, et de redimensionnement de la partition à agrandir.

Nous allons pour cela utiliser le bon vieux fdisk en console, et non pas un outil graphique, car seul fdisk nous permettra de supprimer notre partition essentielle (celle de la LVM chiffrée) et de la recréer exactement au même endroit, mais plus grande.

Lançons donc: fdisk /dev/sda

La première chose à faire est d'afficher la table de partitions actuelle en utilisant la commande "p", et de noter absolument tous les jolis chiffres qui apparaîssent alors, de manière à pouvoir remettre manuellement les choses en l'état en cas de problème.

Puis nous utiliserons la commande "d" de fdisk afin de détruire sans regret les partitions "4" et "3" dont nous n'avons plus besoin.

Puis nous arrivons à l'étape vraiment terrifiante de la manoeuvre, qui consiste à supprimer la partition sda2, c'est-à-dire celle de notre LVM chiffrée, ce qui revient très exactement à scier la branche sur laquelle notre système est assis. Supprimons donc courageusement la partition "2" à l'aide de la commande "d".

Pas de panique toutefois, les modifications ne seront réellement apportées sur le disque qu'au moment où nous exécuterons la commande "w" finale, et nous aurons recréé la partition vitale d'ici-là, mais en plus grand. D'autre part, la modification de la table de partitions sera alors écrite sur le disque dur lui-même, mais le noyau Linux n'en tiendra aucun compte puisqu'il est incapable de relire la table de partitions d'un disque ayant des partitions montées. Il faudra donc rebooter le système pour que le changement de taille de la partition concernée soit pris en compte.

Après avoir supprimé la partition "2", nous la recréons maintenant aussitôt, comme partition primaire, en utilisant la commande "n". Nous veillerons alors à ce que la "nouvelle partition 2" commence à l'endroit exact du disque (numéro de cylindre) où elle commençait précédemment, et nous la laisserons s'étendre jusqu'à la fin du disque, utilisant ainsi tout l'espace disponible.

Après avoir recréé la partition, utilisons la commande "p" pour afficher la nouvelle table de partitions, et vérifions soigneusement à l'aide de nos notes qu'elle commence effectivement exactement au même endroit que précédemment.

Si c'est bien le cas, nous pouvons alors écrire nos modifications de manière définitive avec la commande "w", qui nous fera également quitter fdisk.

Nous allons maintenant devoir rebooter le système pour que la nouvelle table de partitions soit prise en compte. Toutefois, si nous avons (dans mon cas particulier) supprimé des partitions qui servaient antérieurement, nous devons en faire disparaître toute trace dans /etc/fstab et /etc/crypttab, puis régénérer notre initramfs (update-initramfs -u) pour éviter de cruelles erreurs lors du reboot.

Rebootons donc bien proprement le système. Ceci devrait se dérouler sans erreur.

Extension du volume LUKS chiffré

Après avoir rebooté, il nous faut théoriquement agrandir le volume chiffré supportant notre LVM. Je dis théoriquement car mes observations semblent démontrer que le volume chiffré utilise automatiquement la nouvelle taille entière de la partition, mais comme je n'en suis pas absolument certain, le redimensionner quand même ne fera pas de mal.

Affichons tout d'abord la taille actuelle de notre container de LVM chiffrée, supposant qu'il s'appelle "encVG" par exemple :

# cryptsetup status encVG
/dev/mapper/encVG is active:
 cipher:  aes-cbc-essiv:sha256
 keysize: 192 bits
 device:  /dev/sda2
 offset:  1032 sectors
 size:    312061593 sectors
 mode:    read/write

"Agrandissons" (en théorie) maintenant le container :

cryptsetup resize encVG

Affichons de nouveau sa taille (cryptsetup status encVG) : Surprise : il semble que rien n'a changé, et que notre manip n'a donc servi à rien ? Ce n'est pas grave : nous utilisons désormais bel et bien la totalité de l'espace attribué à la partition sda2.

Agrandissement du volume physique de la LVM

C'est là que nous allons nous apercevoir que la manip' a marché !

# pvs
 PV                       VG   Fmt  Attr PSize   PFree
 /dev/mapper/encVG VG1 lvm2 a-   144.80G    0

pvresize /dev/mapper/encVG

# pvs
 PV                       VG   Fmt  Attr PSize   PFree
 /dev/mapper/encVG VG1 lvm2 a-   148.80G    4.0G

Eh oui ! le "pvresize" nous a bien fait gagner 4 Go d'espace libre dans la LVM chiffrée !

Création des nouveaux volumes logiques

Nous pouvons maintenant créer (lvcreate) un ou plusieurs nouveaux volumes logiques dans l'espace désormais disponible sur la LVM. Dans mon cas, j'en recréerai deux, pour le /tmp et pour le swap bien sûr.

Si vous souhaitez utiliser ce nouvel espace non pas pour créer de nouveaux volumes logiques, mais pour agrandir un volume déjà existant (lvextend), je vous conseille toutefois de commencer par créer un nouveau volume logique, que vous supprimerez ensuite, mais entre-temps vous l'aurez rempli de données aléatoires, ce qui est toujours conseillé avant de commencer à utiliser un volume chiffré.

Remplissage des nouveaux volumes logiques avec des données aléatoires

Par exemple :

dd if=/dev/urandom of=/dev/mapper/VG1-newvolume bs=1M

(Si vous voulez accélérer cette étape, vous pouvez utiliser /dev/zero à la place de /dev/urandom, puisque, s'agissant d'un volume chiffré, le chiffrement donnera de toute manière un aspect parfaitement aléatoire aux données qui seront physiquement écrites sur le disque (les zéros seront transformés en random apparent).

Formatage des nouveaux volumes logiques

Nous n'avons plus désormais qu'à formater les nouveaux volumes logiques en fonction de leur utilisation projetée : mke2fs, mkswap, etc... ou, pour l'extension d'un volume existant, lvextend puis resize2fs^[1] par exemple.

Mise à jour de fstab

Enfin, nous pouvons monter nos nouveaux volumes, sans oublier bien sûr de les mentionner dans /etc/fstab - il n'y a rien à ajouter dans /etc/crypttab puisque l'entrée servant à déverrouiller globalement la LVM chiffrée y figure déjà.

That's all, folks !

English abstract : This article explains how to expand a LUKS-encryped LVM on which resides a fully encrypted GNU/Linux System, including its root filesystem. This can be done on the "live" system without needing to boot from a live CD or the like. Use an online translator such as Google translate or babelfish to obtain a truly bad, automated translation of this document ;-)

Help Google : resize enlarge expand LUKS encrypted partition LVM container on the fly

Notes

[1] À effectuer sur un volume préalablement démonté

C'est toujours les meilleurs qui s'en vont...

Petaramesh — Tue, 13 May 2008 00:04:00 +0200

Triste nouvelle : Les éditions O'Reilly France ont mis la clé sous le paillasson...

<deuil> Sniff... Les seuls bouquins d'informatique lisibles, bien écrits, et parlant de Logiciels Libres, bouhouhou </deuil>

Les merdes infâmes écrites avec les pieds en paraphrasant la doc avec des erreurs dedans demeurent...

Une clé de contact pour votre portable chiffré : Mise à jour

Petaramesh — Sun, 11 May 2008 09:46:00 +0200

Ce billet est là uniquement pour signaler une importante mise à jour de mon précédent billet Une clé de contact pour votre portable chiffré et du script bootkeyscript^[1] qu'il propose.

En effet, ce script s'est avéré dans sa version précédente pouvoir très mal fonctionner avec une clé non chiffrée sur une clé USB formatée en FAT. Le voici maintenant bien débuggé, partiellement réécrit et enrichi, ainsi que les explications qui vont avec.

Que demande le peuple ? ;-)

Instructions de mise-à-jour :

Si vous utilisiez la précédente version de mon script bootkeyscript, il vous suffit d'installer la nouvelle à la place de la précédente (typiquement dans /usr/local/sbin) et de régénérer votre initramfs avec "update-initramfs -u". C'est tout.

Bon c'est pas tout ça, faut qu'on va aller pique-niquer ;-))

(Rectificatif : Ah non, tiens, le programme de la journée a l'air plutôt réglé sur "Monstre engueulade familiale et hurlements uxoriens"... Soyons zen...)

Notes

[1] (Signature GnuPG, licence GPL)

Mise à jour (K)Ubuntu 7.10 Gutsy => 8.04 Hardy LTS

Petaramesh — Wed, 30 Apr 2008 15:20:00 +0200

Plusieurs estimés disciples m'ont demandé par mail quelques infos ou conseils pour la mise à jour de leur machine vers la toute nouvelle (K) Ubuntu 8.04 Hardy LTS.

Je n'avais pas encore fait cette mise à jour ; je viens de la faire sur deux machines : Au rapport !

Je viens donc de mettre à jour deux Kubuntu 7.10 vers 8.04, et la bonne nouvelle c'est que ça s'est plutôt très bien passé, comme une lettre à la poste, en utilisant l'updateur de Kubuntu et sans rien faire de particulier.

Si ça c'est bien passé avec Kubuntu, je m'attends à ce que ça se passe encore plus facilement (si toutefois c'est possible) avec Ubuntu.

Les deux machines que j'ai mises à jour étaient une station de travail (Bipro Intel Xeon, système installé sur LVM) et mon bon vieux portable (système entièrement installé sur LVM chiffrée). Ce ne sont donc pas les configs les plus simples qui soient, et ça fait un bon test de mise à jour.

Première note : Ces jours-ci, les miroirs primaires FTP Ubuntu sont totalement saturés. On comprend pourquoi. Je vous conseille donc très fort de sélectionner comme source de paquetages des miroirs alternatifs avant de lancer la mise à jour :

Mise à jour de mon portable en utilisant les miroirs de free.fr : 2 heures.
Mise à jour de l'autre station en utillisant le miroir "primaire France" : Plus de 24 heures.

Qu'on se le dise ;-)

Après mise à jour, tout fonctionne impec sur les deux machines, y compris le Wi-Fi de mon portable qui utilise pourtant ndiswrapper, typiquement le truc qui se casse à la mise à jour, ben là, même pas.

Je note un problème après cette mise à jour : Mon portable a une carte graphique ATI^[1] et j'utilisais le pilote propriétaire fglrx. Là, j'ai vu une belle marche arrière :

Avec Ubuntu 7.04 : Tout marchait parfaitement
Avec Ubuntu 7.10 : Impossible d'utiliser la "suspension" ou "l'hibernation" du portable. le pilote fglrx coince.
Avec Ubuntu 8.04 : Impossible de sortir de l'environnement graphique. Plantage systématique en quittant ou fermant la session (écran noir, plus rien ne répond, il est cependant possible de débloquer la machine en utilisant la MagicSysRq key "E", qui tue tous les processus et permet alors de réobtenir la console et de voir ensuite la machine s'arrêter normalement).

Pour cette raison, je viens (pour le moment) d'abandonner l'usage du pilote propriétaire fglrx pour le pilote ATI générique libre, abandonnant au passage l'utilisation de l'accélération 3D matérielle de ma carte graphique (dont je n'ai cependant que faire 98% du temps) et divisant par 2 les performances OpenGL. Bon.

Je ne peux cependant pas en vouloir à Ubuntu, car il semble que c'est ATI qui rame très loin derrière les versions de noyau et de xorg dans le développement de son pilote propriétaire... Espérons (voeu pieux) qu'ATI va se décider à pondre une mise à jour qui marche pour son pilote. Ils commencent à me flégon... :-/

Si vous avez une carte ATI utilisant fglrx, je vous suggère de le désactiver (repasser au pilote ordinaire) et de rebooter ensuite votre machine avant de lancer la mise-à-jour vers Hardy.

Pour le reste, RÀS, alors si vous vous sentez l'âme aventureuse, vous pouvez tenter le coup - sachant bien que si vous cassez votre bécane, ce ne sera pas ma faute ;-)

Addendum 2 mai 2008 10:36 : Mon problème de blocage à la fermeture de session avec le pilote fglrx a été résolu comme décrit ici, merci à Olivier Lacroix pour le tuyau.

Solution reçue moins de 24h après avoir posé la question. Décidément, le support de la communauté dans le Logiciel Libre, c'est vraiment que du bonheur ! Ramez une fois dans votre vie avec un problème similaire sous Windows, vous comprendrez la différence... (Typiquement, vous n'aurez la solution qu'en attendant 2 ans une hypothétique corrective, ou à défaut le jour où vous changerez de matériel...)

Notes

[1] J'en vois déjà des qui rigolent...

Error ? Success !

Petaramesh — Fri, 08 Feb 2008 17:02:00 +0100

Heureusement que c'est vendredi, y'a des jours où l'on ne peut même plus prétendre que ce genre de chose n'arrive que sous Windows...

partimage est certes bien utile, mais cette cochonnerie est bugguée de sa mère, et pas maintenue. S'en servir consiste essentiellement à ruser pour passer entre les bugs :~\

Cartes Flash "SD" et portables Ubuntu Linux

Petaramesh — Mon, 28 Jan 2008 14:26:00 +0100

Ce n'est pas histoire de faire de la pub' (sinon, j'accepte volontiers que Sandisk m'en envoie deux caisses ;-) mais après avoir pas mal galéré, j'ai pensé que l'info pourrait être utile à d'autres que moi...

Sur deux portables tournant sous Ubuntu Gutsy et possédant un lecteur de cartes SD/MMC :

Un Acer Aspire 3104 WLMi avec lecteur SD/MMC interne "ENE"
Un Asus EeePC avec lecteur interne SD/MMC vu en USB 2.0, s'identifant comme "Kingston technologies" mais laissant également à penser qu'il est fabriqué par "ENE"

Je constate que :

Les cartes Flash SD de marque / type Sandisk Ultra II, de capacité de 1 Go ou 2 Go, fonctionnent à la perfection, plein pot et sans la moindre erreur.
Toutes les autres cartes SD que j'ai essayées (5 ou 6 de marques et capacités différentes) merdoient lamentablement. Dans le meilleur des cas des gerbes d'erreurs de de retries dans /var/log/kern.log causant de considérables ralentissements, et dans l'écrasante majorité des cas, ça finit par foirer complètement.

Donc, sur ces machines et avec Linux, je ne me pose plus de questions oiseuses quant au type de cartes que j'achèterai à l'avenir.

gOS ?

Petaramesh — Sun, 27 Jan 2008 00:38:00 +0100

Quelqu'un a déjà essayé cet OVNI ?

Chuis en train de donnelouder ça pour me faire une idée.

La maison qui fait ça est là et y'a tellement de Gougoule inside qu'on peut se demander qui paie les factures et si ce ne serait pas le nouveau moyen de foutre Petitmou dehors... Un moyen pas forcément idiot.

Leur profession de foi est amusante :

We started in this business because we saw a big need for a good operating system (OS) company.

We saw today’s world in a crisis with but a single, dominant OS that is expensive to license, demanding on hardware, and lacking in included software. We saw a need for changes, and formed gOS to help effect them. We believe there must be better ways of being an OS company, and we're commited to finding them with you.

gOS is a new, friendly OS designed to just work out of the box with Google applications online. Also inside, all you need to browse the web, e-mail, chat, play music and movies, create and edit documents using Google and other free software. In addition, gOS performs well on almost any computer, costs nothing for users, and has a beautiful user interface.

...Après, ils affirment qu'ils ont la ferme intention de gagner des sous.

Et y'a un petit concurrent de l'EeePC, l'Everex Cloudbook^[1] qui sort avec ça dans le coffre et No Petitmou inside...

Notes

[1] Un peu plus gros, beaucoup moins beau, avec un disque dur mécanique (donc bien plus gros), un processeur Via nettement plus rapide, la même quantité de RAM et la même taille d'écran que l'EeePC.

Une clé de contact pour votre portable chiffré

Petaramesh — Thu, 29 Nov 2007 16:44:00 +0100

Article mis à jour le 11 mai 2008

Dans mon précédent article, je vous ai expliqué comment chiffrer intégralement le disque dur de votre portable sous Linux, rendant l'ensemble des données et programmes qu'il contient absolument indéchiffrables et inaccessibles pour qui ne connaît pas la phrase secrète nécessaire à son déchiffrement.

Nous allons aujourd'hui nous intéresser à une autre méthode de démarrage d'un tel portable : Celle qui consiste à utiliser une clé de déchiffrement stockée sur un support externe, qui jouera alors le rôle de "clé de contact" de la machine : Si ce support externe est inséré, le portable pourra démarrer ; s'il est absent, le portable sera inutilisable.

Nous verrons qu'il est également possible d'utiliser ce qu'on appelle "dual form authentication", une authentification forte basée à la fois sur quelque chose que vous avez, et quelque chose que vous savez : Un support externe, que vous avez, plus un mot de passe nécessaire à son utilisation. Si l'un des deux manque, point d'accès. C'est d'ailleurs ce que vous faites, comme monsieur Jourdain, à chaque fois que vous payez avec une carte bancaire.

(Short english summary at end)

L'un des avantages à avoir chiffré tout son disque avec LUKS, c'est que ce système permet de modifier après coup la ou les phrases secrètes ou clés qui le verrouillent. On peut donc assez aisément : ^[1]

Installer plusieurs phrases secrètes différentes permettant de déverrouiller la machine, ce qui est utile si la machine a plusieurs utilisateurs légitimes : ainsi, aucun n'a besoin de connaître la phrase secrète de l'autre. Chacun la sienne !
Ajouter une clé de déchiffrement qui ne sera pas une phrase secrète, mais un fichier hébergé sur un stockage externe (qui peut lui-même être chiffré, ce qui permet d'obtenir la "dual form authentication", ou authentification à double critère).
Supprimer une phrase ou clé existante si l'on ne souhaite plus utiliser l'une des méthodes, si l'un des utilisateurs ne doit plus avoir accès à la machine ou si une phrase ou clé a été compromise, etc.

La méthode hybride permet également de verrouiller le système avec une phrase secrète longue et complexe - donc fastidieuse à taper - et alternativement avec un support externe contenant une clé qui peut être protégée par un mot de passe plus simple, voire pas de mot de passe du tout, en fonction des besoins de sécurité que l'on aura.

En terme de support externe, nous pourrons envisager l'usage d'une clé "flash drive" USB,^[2] ou d'une carte mémoire type SD, etc, pour peu que la machine considérée soit équipée d'un lecteur adéquat.

En partant du principe que nous avons déjà un système entièrement chiffré sur la base de mon précédent article, la mise en oeuvre d'une clé sur support externe - avec ou sans double authentification - va être relativement simple : Je fournis ici un "bootkeyscript"^[3] qui fait tout le boulot.

En premier lieu, procurons-nous évidemment un support externe utilisable sur notre machine, et que nous utiliserons. Nous pouvons le partitionner et le formater de la manière de notre choix, le script "bootkeyscript" détectera automatiquement le système de fichiers utilisé.

Si nous voulons utiliser une clé "simple" sur support externe, non protégée elle-même par mot de passe, nous pouvons nous contenter de mettre celle-ci dans une partition FAT existante de n'importe quel support externe, que nous pourrons également utiliser "comme d'habitude" pour y stocker tous documents et fichiers de notre choix, en prenant simplement grand soin de ne jamais effacer par mégarde la clé de notre système !

Si nous voulons chiffrer la clé elle-même, nous créerons sur le support externe une petite partition que nous chiffrerons avec LUKS avant d'y créer un filesystem ext2 sur lequel nous stockerons enfin la clé.
Ceux qui ne désirent pas cette "double protection" peuvent sauter l'étape de création d'une partition chiffrée sur le support externe.

Création d'une partition chiffrée sur le support externe

Nous utiliserons donc un outil de partitionnement (fdisk, gparted, etc...) pour créer sur le support amovible une petite partition (typiquement 10 Mo) de type "Linux" (83), non formatée. Pour la suite de cet article, nous considérerons la partition créée, et située sur /dev/sdb2. Adaptez bien évidemment les instructions qui suivent à l'emplacement de votre propre partition, sur votre propre périphérique, au risque de détruire irrémédiablement des données sur votre système.

Commençons par remplir notre partition de clés de données aléatoires, selon la méthode habituelle :

dd if=/dev/urandom of=/dev/sdb2 bs=1M

Compte tenu de sa taille modeste, ça ne devrait prendre que quelques secondes.

Faisons ensuite de cette partition un volume chiffré LUKS :

cryptsetup luksFormat /dev/sdb2

Après un avertissement auquel il nous faut répondre "YES", il nous sera demandé de taper deux fois la phrase secrète ou mot de passe que nous utiliserons pour protéger nos clés. Rappelons-nous que nous devrons le taper à chaque boot, et que cela vient en supplément de la possession matérielle du support. À moins d'être paranoïaque, nous pouvons donc nous contenter d'un mot de passe relativement court et facile à taper - mais de préférence, pas à deviner ;-)
Une fois le volume chiffré créé, nous devons l'activer :

cryptsetup luksOpen /dev/sdb2 ext_keys

Après avoir tapé le mot de passe, si nous tapons "ls -l /dev/mapper", nous devrions voir y apparaître un périphérique nommé "ext_keys", qui correspond au volume chiffré "/dev/sdb2" actuellement ouvert.

Il nous faut maintenant "formater" cette partition pour y créer un filesystem ext2 :

mke2fs -m 0 -L ext_keys /dev/mapper/ext_keys

Génération d'un fichier-clé de 256 octets aléatoires

Nous allons maintenant monter le volume externe de manière à pouvoir y créer un fichier-clé. Commençons par créer le répertoire qui servira de point de montage :

mkdir /mnt/ext_keys

Puis :

Si nous n'avons pas chiffré le volume, nous utilisons directement la partition de l'unité externe :
- mount -t vfat -o defaults /dev/sdb2 /mnt/ext_keys
Si nous avons chiffré le volume, nous montons sa version ouverte depuis /dev/mapper :
- mount -t ext2 -o noatime /dev/mapper/ext_keys /mnt/ext_keys

Nous n'avons plus qu'à générer un fichier de 256 octets aléatoires que nous nommerons .bootkey (par exemple).

N.B.: Veillez bien à utiliser ici /dev/random et non pas /dev/urandom :

dd if=/dev/random of=/mnt/ext_keys/.bootkey

...à la suite de quoi un "ls -la /mnt/ext_keys/" devrait bien nous montrer la présence de notre fichier-clé aléatoire de 256 octets.

=> Un support externe peut être endommagé ou perdu ! Une mémoire flash n'est pas infaillible ! A ce stade, je vous conseille vivement de faire une copie de votre fichier-clé sur un ou plusieurs autres supports !

Maintenant que notre fichier est généré (et sauvegardé), nous pouvons démonter l'unité externe :

umount /mnt/ext_keys
sync

et, si nous avions utilisé un volume chiffré, nous pouvons le désactiver :

cryptsetup luksClose ext_keys

Première regénération de l'initramfs

Pour pouvoir accéder à notre unité externe lors du boot, nous devrons nous assurer que les modules nécessaires (USB ou SD/MMC) sont bien présents sur l'initramfs que nous utilisons.

Les modules à charger dépendent fortement du matériel que vous possédez. Utilisez la commande "lsmod" pour lister les modules actuellement chargés sur votre système, et déterminer ceux qu'il vous faudra inclure dans l'initramfs.

On aura typiquement pour de l'USB :

usbcore
ohci_hcd (ou uhci_hcd selon le matériel)
ehci_hcd
usb_storage
sd_mod

Pour un lecteur SD/MMC :

mmc_core
sdhci
mmc_block

Si vous voulez mettre votre clé sur une partition FAT (sur une clé USB par exemple, il faudra également ajouter :

fat
vfat
nls_cp437
nls_iso8859_1

Mettez alors cette liste de modules, un par ligne, dans le fichier /etc/initramfs-tools/modules. Le mien, pour une utilisation de cartes SD, contient les lignes suivantes :

mmc_core
sdhci
mmc_block
aes_i586
sha256
dm_mod
dm_crypt

Une fois ceci fait, récréons notre initramfs :

update-initramfs -v -u

Insertion de la nouvelle clé dans le container LUKS principal du système

Nous allons maintenant rebooter notre système (antérieurement chiffré), et, quand celui-ci nous demandera notre phrase secrète, nous allons volontairement taper 3 fois de suite un mot de passe invalide, puis attendre. Au bout d'une trentaine de secondes, nous devrions obtenir un message d'erreur indiquant que le root filesystem est indisponible, puis nous retrouver dans un shell minimal (busybox) à l'intérieur de notre initramfs.

(initramfs)

À partir de là, nous ne pouvons pas faire grand-chose, mais nous pouvons en faire assez pour ajouter notre clé au container :

Créons un point de montage "/ext_keys" : mkdir /ext_keys
Montons notre unité externe sous ce point : mount -t vfat -o ro /dev/sdb2 /ext_keys (si nous avions chiffré la partition, nous devons d'abord l'ouvrir avec "cryptsetup luksOpen'' avant de la monter à partir de /dev/mapper exactement comme expliqué plus haut)

Ajoutons maintenant la clé au container chiffré du disque dur (en supposant qu'il s'appelle /dev/sda2) :

cryptsetup luksAddKey /dev/sda2  /ext_keys/.bootkey

Le système nous demandera alors la phrase secrète actuelle du container, avant d'ajouter la clé qui se trouve sur le périphérique externe.

Une fois ceci fait, nous pouvons démonter le volume externe (umount /ext_keys), et si nécessaire refermer le volume chiffré correspondant (cryptsetup luksClose ext_keys).
Puis, nous pouvons rebooter "normalement" :

sync
reboot

=> Lors de ce reboot, nous devons toujours taper la phrase secrète habituelle de notre système, car son initramfs ne sait pas encore utiliser la clé résidant sur le support externe.

Génération d'un initramfs compatible avec la clé sur support externe.

Pour que notre système puisse utiliser la clé que nous avons fabriquée puis installée, il nous faut ajouter dans l'initramfs le script "bootkeyscript" que j'ai écrit et que vous trouverez en attachement.
Ce script est très souple, car il détecte automatiquement si la partition contenant la clé est chiffrée ou non, et en demande le mot de passe le cas échéant. De plus, si l'unité externe n'est pas présente, il vous sera possible de taper une phrase secrète à la main - si toutefois votre système en reconnaît encore une comme valide.

Installation du script "bootkeyscript"

Installez ce script dans un répertoire approprié de votre système (je vous suggère /usr/local/sbin), et rendez-le exécutable avec "chmod 755 /usr/local/sbin/bootkeyscript".

Inclusion de l'utilitaire "stty" dans l'initramfs

Créez un script que vous appellerez "include_stty" dans le répertoire /etc/initramfs-tools/hooks, avec le contenu suivant :

#! /bin/sh
. /usr/share/initramfs-tools/hook-functions
copy_exec /bin/stty /bin

Rendez ce script exécutable : chmod 744 /etc/initramfs-tools/hooks/include_stty

Inclusion de l'utilitaire "udevsettle" dans l'initramfs

Créez un script que vous appellerez "include_udevsettle" dans le répertoire /etc/initramfs-tools/hooks, avec le contenu suivant :

#! /bin/sh
. /usr/share/initramfs-tools/hook-functions
copy_exec /sbin/udevsettle /sbin

Rendez ce script exécutable : chmod 744 /etc/initramfs-tools/hooks/include_udevsettle

Edition de /etc/crypttab

Editez votre fichier /etc/crypttab : C'est lui qui indiquera au système qu'il faut utiliser le script, et où se trouve la clé. En fonction du périphérique externe que vous utilisez et du nom que vous avez choisi pour votre fichier-clé, la ligne concernant votre LVM chiffrée devra désormais prendre l'aspect suivant :

# <target name> <source device> <key file> <options>
crypt_VG1 /dev/sda2 sdb2/.bootkey   luks,tries=3,lvm=crypt_VG1-LV_ROOTFS,keyscript=/usr/local/sbin/bootkeyscript

À noter : l'emplacement du "key file" se note ici sous la forme partition/fichier (avec des sous-répertoires si vous le souhaitez), mais sans indiquer "/dev/..." ni le point de montage, qui sont automatiques.

Ne vous trompez pas en modifiant ce fichier ! Par rapport à votre installation antérieure, il vous faut seulement :

Modifier "key file" de "none" à l'emplacement de votre fichier-clé ;
Ajouter à la fin des options "keyscript=/usr/local/sbin/bootkeyscript"

Le reste ne change pas par rapport à précédemment.

Nous avons presque terminé.

Génération de l'initramfs final :

update-initramfs -v -u

...Et il ne nous reste plus qu'à rebooter proprement.

- Si le périphérique contenant la clé est présent, la machine bootera automatiquement (elle demandera le mot de passe du périphérique-clé automatiquement, uniquement ci celui-ci a été créé ainsi).

- Si le périphérique contenant la clé est absent, vous obtiendrez (et c'est intentionnel) uniquement le message d'erreur :

Missing boot device /dev/sdb2!

...mais en réponse à ce messages d'erreur, vous pouvez taper une phrase secrète, s'il en existe une valide pour le container chiffré du disque dur, et le démarage se poursuivra alors normalement.

Vous avez désormais un système chiffré capable d'être "trimodal" : Il peut démarrer soit avec une phrase secrète, soit avec une clé externe non protégée, soit avec une clé externe protégée, vous offrant ainsi une sécurité extrême.

Si les choses ne fonctionnent pas comme désiré, vous pouvez passer le script en mode "debug" en ajoutant "cryptdebug" à la ligne de paramètres de démarrage de votre noyau. Le script affichera alors des messages indiquant sa progression et d'éventuels problèmes.

Une fois que vous serez certain que votre clé externe permet effectivement le démarrage du système, et que vous en avez fait une copie de secours (ailleurs que sur le portable qu'elle protège ;-) vous pourrez, si vous le souhaitez, supprimer complètement la phrase secrète antérieure de votre disque dur chiffré, en utilisant "cryptsetup luksDelKey (voir man cryptsetup), après avoir booté dans l'initrd'' comme expliqué plus haut.

Il ne vous reste plus qu'à penser à ne pas laisser votre clé de contact en permanence sur votre machine : Aussitôt que la machine a démarré, vous pouvez la retirer - et donc utiliser votre lecteur de carte ou prise USB pour y connecter, comme d'habitude, tout autre périphérique de votre choix.

Vous pouvez également vous référer avec fruit au Two Form Factor Authentication and LUKS Whole Disk Encryption with Feisty Fawn HowTo, notez cependant que le script "maison" que je vous fournis ici n'en provient pas : J'ai la faiblesse de penser que mon script est beaucoup plus puissant, et il a l'avantage de ne nécessiter aucune modification des scripts standard du système.

Short english summary :

In this article, I propose a "bootkeyscript" that allows easy use of dual form factor authentication on a fully encrypted LVM Ubuntu (7.10 Gutsy Gibbon) Linux installation. (See one of these excellent HowTos for installing Ubuntu on a fully-encrypted LVM base : "EncryptedFilesystemLVMHowto", "FeistyLUKSTwoFormFactor")

The script that I propose here has some advantages over existing scripts :

Doesn't need any change or patch to Ubuntu Gutsy existing scripts, with which it integrates well, making future packages upgrads easy ;
Automatically allows in a smart way any combination of the following authentication methods :
- Single form-factor authentication, using an unencrypted keyfile on an external removable device ;
- Dual-form factor authentication, using a keyfile residing on a LUKS-encrypted partition on an external device ;
- Possible automatic fallback to typing a passphrase if keyfile external device is missing (with a purposely obscure Missing boot device! error message).

Short installation instructions :

Create a fully (passphrase-controlled) LVM encrypted system as usual, possibly following one of the existing HowTos. Do not change anything in the existing Ubuntu encryption scripts.
Create a random keyfile. Install it on an external device partition, either itself LUKS-encrypted with a passphrase (for 2 form-factor auth) or unencrypted (1 form-factor, with key device, without passphrase).
Install the key to the main system LUKS container (following usual instructions).
List all the modules you will need to access your key device and its filesystem, in the /etc/initramfs-tools/modules file
Put such an executable script (mode 744) into /etc/initramfs-tools/hooks, let's call it "include_stty" :

#! /bin/sh
. /usr/share/initramfs-tools/hook-functions
copy_exec /bin/stty /bin

(This will include "stty" into the initramfs, to avoid echoing typed passphrase if not using bootsplash. Using bootsplash wouldn't actually need this)

Create an include_udevsettle script the same way :

#! /bin/sh
. /usr/share/initramfs-tools/hook-functions
copy_exec /sbin/udevsettle /sbin

Install my "bootkeyscript" script wherever you like on your system (I suggest /usr/local/sbin), mode 755.
Update /etc/crypttab with the columns :
- Key : device/keyfilename i.e. sdb1/.mysystemkey or mmcblk0p2/somedir/somekeyfile (Syntax is devicepartition/filepath)
- Options : Add "keyscript=/usr/local/sbin/bootkeyscript"
Regenerate initramfs (update-initrafms -u)
Reboot, enjoy.

Changelog

2008/05/10: bootkeyscript V. 1.5:

Much debugged and rewritten version of the script.
Works much better than previously for keys on USB flash disks.
Includes a "debug" mode that you can set by adding "cryptdebug" to the kernel command line.
This article completed with some missing infomation.
Compatible with Ubuntu 8.04 Hardy or 7.10 Gutsy

Help Google : Ubuntu Linux 7.10 Gutsy Gibbon LUKS whole disk encryption external device keys, two form factor authentication, how to howto

Notes

[1] Les possibilités de ce système sont immenses. On peut par exemple imaginer, pour un serveur - qui doit être capable de booter sans intervention humaine - de stocker une clé sur une machine distante, et de l'obtenir via Internet, la machine distante étant configurée pour ne fournir cette clé qu'à une adresse IP précise. Le serveur sera ainsi capable de booter tout seul dans son "environnement habituel", mais si jamais il est volé, il deviendra inutilisable en dehors de son adresse IP habituelle, et il sera possible de supprimer la clé de la machine distante sur laquelle elle est stockée. Un tel setup est toutefois extrêmement complexe et va bien au-delà des objectifs de cet article.

[2] L'avantage d'une clé USB est qu'elle peut être bootable, alors qu'une SD-card ne le sera pas - parce que le BIOS du système ne le prévoit généralement pas. Si on utilise une clé USB, on peut même envisager de mettre dessus le "/boot" non chiffré du système (moins de 100 Mo), ainsi que le bootloader grub, ne laissant sur le disque dur qu'un container totalement chiffré et non bootable contenant tout le reste du système. Ce n'est pas particulièrement compliqué à faire, mais c'est là encore en dehors du sujet de cet article.

[3] Évidemment sous licence GNU GPL.

Flinguez le disque dur de votre portable avec Linux !

Petaramesh — Thu, 22 Nov 2007 23:41:00 +0100

Ou une méthode particulièrement involontaire d'effacement sécurisé de vos fichiers : Ruiner le disque dur de votre portable à l'insu de votre plein gré, sans une leçon et en un exercice pratique !

Linux peut vous y aider...

Mais comment donc ? Linux sur mon portable pourrait transformer son disque dur en une ruine fumante en l'espace de quelques mois ? Il se pourrait bien que oui, quoique cela ne soit pas certain...

Les disques durs des portables ont ceci de particulier, par rapport aux disques durs des machines de bureau, qu'ils sont étudiés pour minimiser autant que possible leur consommation d'énergie - pour prolonger l'autonomie de la batterie - et également pour mieux résister aux chocs en fonctionnement.

L'une de leurs fonctions pour ce faire est de pouvoir rétracter leurs têtes de lecture (les parquer) assez rapidement dès que le disque "ne fait rien" depuis quelques instants, permettant de cesser d'alimenter l'actuateur des têtes d'une part, et d'autre part de rendre le disque insensible à un éventuel choc - les têtes n'étant plus sur le disque, qui continue cependant à tourner. Les têtes sont alors rétractées sur une petite "rampe" où elles sont verrouillées en position, ne risquant plus de se crasher sur le disque en cas de choc un peu violent.

Jusqu'ici, ça semble bel et bon.

Sauf que...

Sauf que le parquage des têtes sur la rampe sollicite la mécanique du disque considérablement plus que le simple fonctionnement en lecture-écriture. Cela provoque une usure qui peut se terminer par des choses très désagréables.

Le nombre de fois qu'une tête peut être parquée et déparquée est variable selon le modèle de disque, mais tourne en moyenne autour de 600.000. Après quoi, le mécanisme est théoriquement usé.

600.000, c'est beaucoup si une tête une fois parquée n'est pas déparquée avant plusieurs minutes.

Mais ça devient relativement peu si la tête est parquée et déparquée plusieurs fois par minute, en permanence. Ça peut ruiner un disque dur de portable en l'espace de quelques mois, s'il est utilisé tous les jours...

Or, le parquage automatique des têtes est une tâche gérée directement par le disque dur, dès lors que le mode "économie d'énergie" est activé. Il parque alors ses têtes tout seul au bout de typiquement 5 à 10 secondes sans accès disque.

Or, un système Linux est plein de gentils petits démons qui font des accès disque réguliers, typiquement toutes les 30 secondes, même quand le système ne fait "rien".

Or, les noyaux Linux récents, qui sont malins, s'ils détectent (via l'ACPI) qu'ils tournent sur un portable et que son disque possèdent une fonction d'économie d'énergie, activent automatiquement celle-ci lors du boot. Ben ouais, quoi ?

Résultat ?

Parquer... Déparquer... Parquer... Déparquer... Parquer... Déparquer... Parquer... TZZzzzoiiiinnngg ! Aïe !

Mais comment savoir si c'est en train d'arriver à votre disque en ce moment même ? Pas dur : À l'oreille.

Lors des accès disque ordinaires, un disque dur de portable fait un gratouillis à peine audible. Lors du parquage, il fait un petit "Cloc !"

Allumez votre portable dans une pièce calme, laissez-le 10 minutes que les cronjobs quotidiens puissent être exécutés, et écoutez-le. Entendez-vous le disque dur émettre un léger "Cloc !" 2 ou 3 fois par minute ? Si oui, vous avez le problème.

Vérifions : Installez le package smartmontools :

aptitude install smartmontools

Déterminez (avec la commande "mount" sans paramètre) si votre disque dur s'appelle "hda" ou "sda". Ce sera probalement "hda" pour un disque PATA, ou "sda" pour un disque SATA.

Affichons maintenant les paramètres SMART du disque :

smartctl -A /dev/sda

smartctl version 5.37 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   062    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   100   100   040    Pre-fail  Offline      -       0
  3 Spin_Up_Time            0x0007   253   253   033    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       261
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   100   100   040    Pre-fail  Offline      -       0
  9 Power_On_Hours          0x0012   099   099   000    Old_age   Always       -       461
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       260
191 G-Sense_Error_Rate      0x000a   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       63
193 Load_Cycle_Count        0x0012   093   093   000    Old_age   Always       -       71733
194 Temperature_Celsius     0x0002   203   203   000    Old_age   Always       -       27 (Lifetime Min/Max 18/52)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   253   000    Old_age   Always       -       0
223 Load_Retry_Count        0x000a   100   100   000    Old_age   Always       -       0

Vous obtenez une liste de valeurs définissant l'état de santé de votre disque, dont les colonnes sont les suivantes :

ID# : Le numéro du paramètre
ATTRIBUTE_NAME : La signification technique de ce paramètre
FLAG : Un flag hexa. laissez tomber ;-)
VALUE : La valeur actuelle de ce paramètre, ramené à une base 100 ou 200 le plus souvent. Il est généralement assez facile de savoir si l'on est sur base 100 ou 200. Plus la valeur est haute, plus c'est bon, plus la valeur est basse, plus c'est mauvais. Typiquement, 100 ou 200, c'est "parfait".
WORST : La valeur la plus basse jamais mesurée pour ce paramètre.
THRESH : Seuil d'alerte "défaillance imminente". Si la VALUE s'approche de ce seuil ou descend en-dessous, votre disque est à l'agonie.
TYPE : Peut être "Pre-fail" : Ce paramètre, s'il descend, est indicatif d'une défaillance imminente. Ou "Old_age" : Ce paramètre descend continuellement avec l'utilisation du disque, c'est un peu comme un compteur kilométrique qui n'indique pas que quelque chose va mal, mais que quelque chose a beaucoup servi...
UPDATED : "Always": Ce paramètre est mesuré en permanence. "Offline" : Ce paramètre n'est mesure QUE si l'on lance une "offline data collection".
WHEN_FAILED : Le nombre d'heures de vol qu'avait le disque la première fois que ce paramètre a foiré.
RAW_VALUE : La valeur brute mesurée (non ramenée à une base particulière). Elle peut être humainement compréhensible (heures de fonctionnement, température, compteur d'évènements...) ou incompréhensible (certaines valeurs de mesure des erreurs).

Et voilà.

Les seules valeurs auxquelles nous nous intéresserons ici sont :

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  9 Power_On_Hours          0x0012   099   099   000    Old_age   Always       -       461
193 Load_Cycle_Count        0x0012   093   093   000    Old_age   Always       -       71733

Ce disque dur a fonctionné 461 heures, et a subi 71733 cycles de parquage des têtes, soit en moyenne 155,6 par heure ou 2,6 par minute. Aïe ! On a un problème. Le disque risque de ne pas vivre vieux à ce rytme.

Relançons la commande "smartctl -A /dev/sda" plusieurs fois toutes les une ou deux minutes, et voyons si la "RAW VALUE" du "Load_Cycle_Count" augmente régulièrement. Il est probable que oui.

Essayons maintenant d'y remédier :

hdparm -B 254 /dev/sda

Relançons la commande encore plusieurs fois. La valeur n'augmente plus ? Très bien, nous avons résolu provisoirement le problème.

Si ça n'a pas marché, essayons :

hdparm -B 255 /dev/sda

Si ça ne marche toujours pas, c'est que le disque n'est pas influençable, et qu'il fait ça de lui-même un point c'est tout. On ne pourra alors rien y faire.

Si on a trouvé la solution, Il faut maintenant demander à notre gentil Linux de passer ce paramètre à chaque démarrage.

Sous Ubuntu, nous éditerons le fichier /etc/hdparm.conf, et à la fin de ce fichier, nous ajouterons le paragraphe :

/dev/sda {
	apm = 254
	keep_settings_over_reset = on
}

Sous Mandriva, par contre, nous copierons le fichier /etc/sysconfig/harddisks sous le nom /etc/sysconfig/harddisksda, puis, ceci fait, nous éditerons ce fichier et ajouterons à la fin la ligne magique :

EXTRA_PARAMS="-B254 -k1"

Puis nous n'aurons plus qu'à rebooter notre machine, et à vérifier comme indiqué plus haut que le problème n'existe plus.

Nous venons de sauver la vie de notre disque dur !

N.B.: Si vous avez l'habitude d'hiberner votre portable sur disque dur, il n'est pas certain qu'au réveil ce paramètre soit automatiquement réappliqué. Il vous faudra vérifier, le scripter au besoin, ou... vivre avec.

(Maintenant, je dis ça comme ça, rien ne me permet d'affirmer que les versions récentes de Winchoze n'ont pas le même problème, hein... Vous avez un portable sous Winchoze ? Tendez l'oreille...)

Une autre chose que nous pouvons faire pour réduire les écritures sur disque inutiles (et que je fais quasi-systématiquement sur tous types de machines) est de cesser d'enregistrer sur disque les timestamps d'accès (même en simple lecture) à tous les fichiers. Ces timestamps génèrent quantité d'écritures et de déplacements de têtes, et, le plus souvent, ne servent à rien.

C'est extrêmement facile. Il vous suffit d'éditer votre fichier /etc/fstab, et, pour tous les points de montage correspondant à votre disque dur, à chaque fois que vous voyez l'option "defaults", remplacez-la simplement par "noatime". Enregistrez, et voilà !