Ce n'est pas un scoop ! Cette session de formation a été une occasion supplémentaire de constater que l'outil Security Device Manager (SDM) est beaucoup trop instable pour que l'on puisse construire des travaux pratiques ou des évaluations en s'appuyant exclusivement dessus.

J'avais déjà publié un billet consacré à l'installation de SDM dans lequel je relatais toutes les difficultés rencontrées.

Toute accusation de parti pris «pro» logiciel libre tient encore moins la route que dans le précédent billet. Dans les universités britanniques que j'ai fréquentées, on connaît tout juste le mot «Linux». Le découpage métier entre gestion du parc des postes informatiques et enseignements sur les réseaux est tout à fait frappant. Le formateur ne se soucie absolument pas du système installé sur les PCs.

Dans les salles de travaux pratiques réseau du tic Learning Centre de l'université de Birmingham, chaque poste de travail dispose de deux unités centrales raccordées au même jeu écran/clavier via un micro KVM. Une UC est utilisable pour accéder au Web ; principalement au site netacad pour les tests en ligne. L'autre UC est réservée aux travaux pratiques. Un compte utilisateur générique permet de reconfigurer les interfaces réseau à volonté et d'installer les logiciels requis par les supports de travaux pratiques. Parmi ces logiciels, on retrouve le fameux Security Device Manager.

Le choix effectué ici est donc d'utiliser SDM sur le système Windoze XP du poste dédié. Ce choix est motivé par un souci d'économie dans l'utilisation de la mémoire flash des routeurs. Dans le cadre du cours CCNA Security, plusieurs travaux pratiques entraînent une consommation accrue de l'espace disponible sur les cartes CompactFlash.

En plus du plantage système complet rencontré avec l'utilisation conjointe des signatures IPS et de SDM, la partie 5 du support de travaux pratiques du chapitre 9 : Use SDM to configure Easy VPN Server n'a donné aucun résultat dans la mesure le menu de configuration n'est jamais apparu !

Voilà ce qui justifie le titre de cette section : l'utilisation du Security Device Manager a été un fiasco.

Côté université Paul Sabatier, j'avais choisi d'installer SDM sur les cartes CompactFlash des routeurs 1841 du bundle CCNA et de charger le système d'exploitation via TFTP lors de l'initialisation. Les travaux pratiques du module Accessing the Wan de l'été dernier ont pu fonctionner normalement sur cette base. J'espère donc pouvoir continuer sur cette base lors de la prochaine session compte tenu de l'échec de l'utilisation de SDM à partir d'une installation sur Windoze. Il va cependant falloir passer par un remplacement des cartes CompactFlash.

Le coût des cartes CompactFlash vendues chez Cisco™ étant exorbitant, il faut utiliser des cartes de fournisseurs tiers offrant des capacités beaucoup plus importantes pour assurer correctement les travaux pratiques de ce cours.

Heureusement, on trouve des références telles que celle proposée par l'excellent PacketLife.net.

Après avoir dit tout le mal possible sur SDM, que peut-on proposer comme alternative constructive ? Eh bien, pas grand chose.

La difficulté pédagogique est de taille. Comment construire une progression qui puisse permettre de se lancer dans l'utilisation des technologies de filtrage réseau ? Bien sûr, le plan du cours est tout tracé : filtrage de paquets, suivi de communication (stateful), inspection applicative et enfin filtrage par politique de sécurité. C'est la partie la plus facile et l'enseignant, aussi brillant soit-il, a tout loisir de disserter sur ces questions jusqu'au moment fatidique où les travaux pratiques arrivent. Lorsque l'on interroge les étudiants novices à l'oral ou que l'on demande de mettre en place une démarche de validation des règles de filtrage étudiées, on prend la mesure du décalage entre le discours et le niveau de compréhension de l'auditoire.

Chaque année, le support que je propose sur l'Introduction au filtrage réseau sur les systèmes GNU/Linux est celui qui pose le plus de problèmes aux étudiants. Tous les autres supports de la série «passent» beaucoup plus facilement. En évaluation, la partie sur le filtrage réseau est rarement traitée.

Pourtant, la conception du couple netfilter/iptables est très bien faite, très claire et plus simple à aborder que les fonctions de filtrage de l'IOS dans lesquelles on retrouve beaucoup plus de jargon et plus d'étapes historiques.

Dans les premières versions du curriculum CCNA, le filtrage de paquets était vu de façon complète et l'accent était mis sur la distinction entre masque réseau et wildcard dans les règles de filtrage. L'exercice emblématique consistant à autoriser l'accès Internet à une moitié seulement des adresses du réseau routé. On retrouvait ainsi une mécanique de décodage d'adresses.

Quand il a fallu intégrer le suivi de communication (ou stateful inspection), la question a été repoussée au cours CCNA Security Course. La commande auto secure sert d'échappatoire pour mettre en place un suivi de communication entre deux interfaces ; l'une exposée au réseau public l'autre au réseau interne d'une entreprise. Le support demande ensuite de modifier le jeu de protocoles soumis au suivi de communication et d'examiner les entrées de la table de suivi. Cette démarche convient très bien en phase de découverte de ces fonctions. La question qui vient ensuite est de savoir jusqu'où aller dans la prise en main de l'outil à un niveau donné. Pour qui a déjà une expérience d'exploitation sur une infrastructure réelle, s'arrêter là peut s'avérer très frustrant et la tentation de vouloir montrer des choses plus intéressantes est très grande. Le choix qui a été fait au niveau du CCNA Security Course est cohérent si l'on s'en tient à la «prise de contact» avec cette technique de filtrage et que l'on craint de perdre trop rapidement l'attention de l'auditoire.

C'est avec le filtrage par politique de sécurité (ou Zone Based Firewall) que les choses se corsent vraiment. Comment faire pour introduire un «mélange» de classification venant des fonctions de qualité de service (QoS) et de règles de filtrage ? Le choix qui a été fait dans le CCNA Security Course s'appuie sur quelques clicks dans SDM. Cette manipulation pourrait s'apparenter au recours à la commande auto secure si l'on demandait d'intervenir sur la configuration ensuite. Le problème ici, c'est que le jeu de commandes généré par les quelques clicks est tellement complexe qu'il n'est plus question d'intervenir sur la configuration autrement qu'à travers l'interface graphique. La syntaxe des commandes de validation du fonctionnement du filtrage impose que l'on comprenne l'enchaînement entre la classification et le filtrage réseau proprement dit. Là, je crois pouvoir dire que l'on «perd le contact» avec les étudiants encore plus rapidement.

Ceci-dit, je n'ai pas de méthode alternative de présentation simple introduisant ces fonctions. Le chantier est ouvert !

Le traitement de la sécurité au niveau d'un réseau local est très bon dans ce cours. On y retrouve toutes les fonctions caractéristiques d'un commutateur. Les travaux pratiques reprennent la démarche proposée dans le guide de la NSA : Cisco IOS Switch Security Configuration Guide.

Cette fois-ci, aucun «clickodrome» ne vient perturber l'attention et les démarches de validation sont bien décrites.

J'ai particulièrement apprécié l'utilisation de la fonction Switched Port Analyzer (SPAN) combinée avec WireShark pour analyser de façon déportée le trafic entre deux hôtes. C'est une technique très pédagogique !

Le chapitre sur les techniques de cryptographie est très équilibré et convient parfaitement pour une première approche sur la question. Les algorithmes y sont présentés sous forme synthétique et contextuelle. L'exercice d'équilibre entre niveau scientifique et exploitation est une fois de plus délicat à négocier. Dans le cas présent c'est réussi. On dépasse le simple catalogue d'algorithme et on dispose d'un premier niveau de choix suivant les contextes d'exploitation. Ici, l'objectif principal est d'aboutir à une synthèse comparative entre IPsec et SSL dans le but d'implémenter des solutions VPNs de différentes catégories.

Voilà pour l'analyse succincte du cours CCNA Security. Comme c'est une formation que je dois assurer au début du mois de Juillet prochain, j'ai encore du pain sur la planche. Je dois notamment préparer des images de machines virtuelles assurant les services Tacacs+ et Radius. J'aurai donc l'occasion de revenir sur ce sujet dans d'autres billets.

Ce billet est disponible en version imprimable au format PDF : ccnasecinst.pdf.

$Id: ccnasecinst.xml 1470 2010-02-16 20:23:44Z latu $

La documentation officielle sur la conversion à rebours du mode allégé en mode autonome est détaillée en dix étapes qui consistent à réinitialiser le point d'accès alors qu'il est directement relié par un câble droit avec une machine disposant d'un service TFTP.

On repère le mode de configuration à la console via la version de l'IOS installé.

AP0023.5e13.4ea2#sh ver

Cisco IOS Software, C1200 Software (C1200-RCVK9W8-M), Version 12.3(11)JX1, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2006 by Cisco Systems, Inc.
Compiled Mon 17-Jul-06 11:41 by alnguyen

ROM: Bootstrap program is C1200 boot loader
BOOTLDR: C1200 Boot Loader (C1200-BOOT-M) Version 12.3(2)JA4, RELEASE SOFTWARE (fc1)

AP0023.5e13.4ea2 uptime is 23 minutes
System returned to ROM by power-on
System image file is "flash:/c1200-rcvk9w8-mx/c1200-rcvk9w8-mx"

cisco AIR-LAP1232AG-E-K9   (PowerPC405GP) processor (revision A0) with 15038K/1336K bytes of memory.
Processor board ID FCZ1251Z0DR
PowerPC405GP CPU at 196Mhz, revision number 0x0145
Last reset from power-on
LWAPP image version 3.0.51.0
1 FastEthernet interface

32K bytes of flash-simulated non-volatile configuration memory.
Base ethernet MAC Address: 00:23:5E:13:4E:A2
Part Number                          : 73-8704-14
PCA Assembly Number                  : 800-23211-14
PCA Revision Number                  : A0
PCB Serial Number                    : FOC12482M20
Top Assembly Part Number             : 800-29149-01
Top Assembly Serial Number           : FCZ1251Z0DR
Top Revision Number                  : A0
Product/Model Number                 : AIR-LAP1232AG-E-K9

Configuration register is 0xF

Suivre la procédure donnée dans la documentation ne pose pas de difficulté particulière. Ce qui est déroutant, c'est le message d'erreur obtenu : Premature end of tar file. Cette erreur n'est pas très explicite au regard du problème réel. Le transfert se termine d'autant plus prématurément qu'il n'a jamais débuté !

Xmodem file system is available.
flashfs[0]: 3 files, 2 directories
flashfs[0]: 0 orphaned files, 0 orphaned directories
flashfs[0]: Total bytes: 7741440
flashfs[0]: Bytes used: 1861632
flashfs[0]: Bytes available: 5879808
flashfs[0]: flashfs fsck took 11 seconds.
Reading cookie from flash parameter block...done.
Base ethernet MAC Address: 00:23:5e:13:4e:a2
Initializing ethernet port 0...
Reset ethernet port 0...
Reset done!
ethernet link up, 100 mbps, full-duplex
Ethernet port 0 initialized: link is up
button is pressed, wait for button to be released...
button pressed for 27 seconds
process_config_recovery: set IP address and config to default 10.0.0.1
process_config_recovery: image recovery
image_recovery: Download default IOS tar image tftp://255.255.255.255/c1200-k9w7-tar.default

examining image...
extracting info (274 bytes)
Premature end of tar file
ERROR: Image is not a valid IOS image archive.Loading "flash:/c1200-rcvk9w8-mx/c1200-rcvk9w8-mx"...##

À quelques jours d'intervalle, je venais juste de publier une révision de la section Échanges avec le protocole TFTP de l'article Gestion des équipements réseau avec GNU/Linux. Cette révision était motivée par la prise en charge de la configuration du paquet tftpd-hpa via un jeu de (menus|écrans) debconf.

$ dpkg -l tftpd-hpa | grep ^ii
ii  tftpd-hpa           5.0-7           HPA's tftp server

Parmi ces menus, on trouve celui relatif à l'adresse sur laquelle le service est en écoute. Cette adresse est définie à la valeur 0.0.0.0:69 et ne correspond pas à l'adresse de diffusion 255.255.255.255.

Le résumé de la configuration du paquet est donné par le fichier /etc/default/tftpd-hpa.

$ cat /etc/default/tftpd-hpa
# /etc/default/tftpd-hpa

## The configuration of this file is managed by debconf as long
## as a line beginning with the '#DEBCONF#' token is included.
##
## Do not edit this file manually, use:
## dpkg-reconfigure tftpd-hpa

#DEBCONF#

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/var/lib/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="--secure --create"

Dans le contexte particulier de la mise à jour système du point d'accès, il est nécessaire de redéfinir l'adresse d'écoute du service en 255.255.255.255.

Après exécution de la commande # dpkg-reconfigure tftpd-hpa, on obtient :

$ cat /etc/default/tftpd-hpa | grep ADDRESS
TFTP_ADDRESS="255.255.255.255"

Au prix de cette reconfiguration, le service TFTP pourra traiter la requête du point d'accès.

flashfs[0]: 3 files, 2 directories
flashfs[0]: 0 orphaned files, 0 orphaned directories
flashfs[0]: Total bytes: 7741440
flashfs[0]: Bytes used: 1861632
flashfs[0]: Bytes available: 5879808
flashfs[0]: flashfs fsck took 11 seconds.
Reading cookie from flash parameter block...done.
Base ethernet MAC Address: 00:23:5e:13:4e:a2
Initializing ethernet port 0...
Reset ethernet port 0...
Reset done!
ethernet link up, 100 mbps, full-duplex
Ethernet port 0 initialized: link is up
button is pressed, wait for button to be released...
button pressed for 23 seconds
process_config_recovery: set IP address and config to default 10.0.0.1
process_config_recovery: image recovery
image_recovery: Download default IOS tar image tftp://255.255.255.255/c1200-k9w7-tar.default

examining image...
extracting info (274 bytes)
Image info:
Version Suffix: k9w7-.123-8.JED
Image Name: c1200-k9w7-mx.123-8.JED
Version Directory: c1200-k9w7-mx.123-8.JED
Ios Image Size: 4342272
Total Image Size: 5079552
Image Feature: WIRELESS LAN
Image Family: C1200
Wireless Switch Management Version: 1.0
Extracting files...
extracting info (274 bytes)
c1200-k9w7-mx.123-8.JED/ (directory) 0 (bytes)
c1200-k9w7-mx.123-8.JED/html/ (directory) 0 (bytes)
c1200-k9w7-mx.123-8.JED/html/level/ (directory) 0 (bytes)
c1200-k9w7-mx.123-8.JED/html/level/1/ (direc

<snipped/>

Deleting current version...
Deleting flash:/c1200-rcvk9w8-mx...done.
New software image installed in flash:/c1200-k9w7-mx.123-8.JED
Configuring system to use new image...done.
Requested system reload in progress...download took about 289 seconds
Loading "flash:/c1200-k9w7-mx.123-8.JED/c1200-k9w7-mx.123-8.JED"...###

Voilà des années que l'on est habitué à voir ces requêtes TFTP à destination de l'adresse All-Ones et que l'on cherche à s'en débarrasser à toute force. Le jour où on est contraint de l'utiliser, on ne réagit même pas au fait que le service n'est pas configuré correctement. Bref, je devrais certainement compléter la documentation avec cet exemple.

Ce billet est disponible en version imprimable au format PDF : tftpd-hpa-allones.pdf.

$Id: tftpd-hpa-allones.xml 1432 2009-11-04 22:05:26Z latu $

À l'heure de la rédaction de ce billet, GRUB est en cours de transition entre une version «historique» fournie avec le paquet grub-legacy et une version plus actuelle distribuée via plusieurs paquets : grub-common et grub-pc.

Attention ! Il n'est pas question ici de promouvoir cette nouvelle version. La transition entre les deux versions n'est pas achevée et j'ai trois ou quatre machines sur lesquelles la migration n'a pas fonctionné comme prévu. Dans ce genre de cas, la version de GRUB correspondant au paquet grub-legacy ayant largement fait ses preuves, le passage à un nouveau gestionnaire d'amorce n'est pas justifié.

En revanche, j'ai découvert presque par hasard que le shell de la nouvelle version possède des fonctions dites auto completion particulièrement séduisantes lorsque la gestion d'amorçage est dans un état calamiteux. Ces mêmes fonctions utilisées via un dispositif de stockage externe tel qu'une clé USB deviennent indispensables pour amorcer un système d'exploitation sur une machine dont le partitionnement et les versions de noyaux disponibles sont inconnus.

Cette section relève du plagiat éhonté puisque ce type d'installation a déjà été maintes fois présenté sur la toile. Voici tout de même la liste des instructions d'installation.

Dans cet exemple, le disque dur du transportable M6300 est référencé /dev/sda et la clé USB /dev/sdb. Ses caractéristiques se retrouvent dans les messages système après connexion.

usb 1-4: new high speed USB device using ehci_hcd and address 3
usb 1-4: New USB device found, idVendor=090c, idProduct=1000
usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-4: Product: USB Flash Disk
usb 1-4: Manufacturer: General
usb 1-4: SerialNumber: AA08061700013029
usb 1-4: configuration #1 chosen from 1 choice
Initializing USB Mass Storage driver...
scsi5 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 3
usb-storage: waiting for device to settle before scanning
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb-storage: device scan complete
scsi 5:0:0:0: Direct-Access     General  USB Flash Disk   1100 PQ: 0 ANSI: 0 CCS
sd 5:0:0:0: Attached scsi generic sg2 type 0
sd 5:0:0:0: [sdb] 3917824 512-byte logical blocks: (2.00 GB/1.86 GiB)
sd 5:0:0:0: [sdb] Write Protect is off
sd 5:0:0:0: [sdb] Mode Sense: 43 00 00 00
sd 5:0:0:0: [sdb] Assuming drive cache: write through
sd 5:0:0:0: [sdb] Assuming drive cache: write through
sdb: sdb1
sd 5:0:0:0: [sdb] Assuming drive cache: write through
sd 5:0:0:0: [sdb] Attached SCSI removable disk

Ces deux étapes accomplies, la phase d'installation est achevée et on peut passer à l'exploitation du gestionnaire d'amorçage GRUB à partir d'une clé USB.

Dans cette section, on utilise la séquence d'initialisation du transportable M6300 pour illustrer les fonctions du shell GRUB à l'aide de clichés de qualité remarquable pris avec un téléphone mobile.

On commence par la sélection du périphérique de démarrage. Sur le transportable, la touche F12 permet de choisir la clé USB. Sur un poste fixe, il faut utiliser les menus du BIOS pour désigner le premier périphérique de stockage utilisé pour lancer un système d'exploitation.

Une fois que l'invite de commande du shell GRUB est disponible, la première opération à réaliser consiste à choisir la racine du gestionnaire d'amorçage à l'aide de la commande root.

Pour choisir le noyau Linux à utiliser pour le lancement du système d'exploitation, on dispose de deux commandes du shell : linux et initrd. La commande linux sert à désigner le fichier contenant la partie monolithique du noyau. Généralement, ce fichier est baptisé vmlinuz-*. La commande initrd sert elle aussi à désigner un fichier. Il s'agit cette fois ci de l'initial ramdisk qui contient une pseudo arborescence racine du système d'exploitation dans laquelle on trouve un shell minimal (BusyBox), un ensemble d'outils et les modules du noyau.

Pour chaque utilisation des commandes linux et initrd, le shell GRUB renvoie un message de confirmation. Dans le cliché ci-dessous, on utilisé la touche de tabulation pour obtenir la liste des fichiers disponibles.

Une fois les deux fichiers du noyau choisis, il ne reste plus qu'à utiliser la commande boot pour lancer le système d'exploitation normalement ou presque ... Lors de l'utilisation de la commande linux j'ai malencontreusement oublié de préciser la véritable racine du système d'exploitation. En fait, cet oubli était volontaire. Il permet de montrer comment identifier les volumes logiques disponibles à partir du shell BusyBox fourni via initrd.

Comme précisé plus haut, l'arborescence contenue dans le fichier initrd contient un certain nombre d'outils, dont ceux nécessaires à la gestion de volumes logiques. Dans le scénario de découverte d'une machine inconnue, on peut activer tous les volumes disponibles à l'aide de la commande vgchange -a y. On identifie ainsi le volume correspondant à la fameuse racine du système d'exploitation.

Une fois l'identification faite, il est possible de relancer le système à l'aide de la commande reboot et de reprendre les étapes précédentes en précisant le paramètre root=/dev/mapper/Amethyste-root à la commande linux. Et cette fois-ci, le système d'exploitation pourra se lancer normalement.

Avec la version de GRUB utilisée, le shell est essentiellement modulaire. Qu'il s'agisse de ses propres fonctionnalités comme la commande ls ou du support des systèmes de fichiers nécessaires au lancement d'un système d'exploitation, tout est disponible sous forme de modules.

Il n'est pas question ici de reprendre la documentation officielle sur les commandes que l'on trouve à l'adresse http://grub.enbug.org/. Simplement, voici quelques exemples de commandes et de syntaxe utiles pour la rédaction de ce billet.

Si vous êtes parvenu jusqu'à la lecture de ces lignes, vous serez peut-être moins intimidé par ce terrible monstre qu'est le gestionnaire d'amorce ! Il faut dire que dans le contexte d'exploitation professionnelle, ces manipulations se font dans des conditions de stress très importantes. Si un système ne se lance plus normalement, c'est que l'on est face à un problème sérieux.

Disposer d'un gestionnaire d'amorce sur périphérique externe comme une clé USB peut être déterminant dans ces situations critiques.

Enfin, c'est l'occasion de recycler une superbe clé USB Canal+ qui aurait été totalement inutile autrement ! Vous l'aurez constaté, je n'ai aucun goût pour les goodies.

Ce document est disponible en version imprimable au format PDF : grub-usb.pdf.

$Id: grub-usb.xml 1430 2009-11-02 22:39:06Z latu $

Sur un système GNU/Linux, le logiciel Linux Kernel Device Mapper est en charge de la gestion des volumes logiques LVM, RAID et quelques autres. De façon classique, ce logiciel est réparti entre les espaces mémoire noyau et utilisateur. La partie utilisateur est fournie à l'aide du paquet Debian baptisé dmsetup.

Ce paquet est notamment responsable de la mise en place des entrées représentant les volumes logiques dans l'arborescence du système ; le répertoire /dev. Cette «responsabilité» est partagée avec les fonctions du démon udevd dont les règles servent à ajouter ou supprimer des entrées dynamiquement en fonction de périphériques de stockage physiquement branchés ou débranchés sur le système.

Cet été, dans la branche unstable de la distribution Debian, il y a eu quelques «croisements gênants» dans les attributions des entrées de périphériques. Il s'agissait de savoir lesquelles des entrées /dev/dm-* ou des entrées /dev/mapper/* devaient être des liens symboliques ou des fichiers nodes de périphériques. Ce conflit a eu des effets de bords sur l'exécution de quelques autre outils  dont GRUB qui est devenu inutilisable.

Dans un pareil cas de figure, il faut s'en remettre au processus d'assurance qualité de la distribution. Deux méthodes d'accès types sont à notre disposition.

Si on retient la seconde méthode dans le contexte présent, c'est le paquet dmsetup qui constitue le point de départ. On utilise l'adresse donnée et on saisit le nom du paquet dans le champ de recherche. On est alors renvoyé automatiquement vers la page de la famille lvm2 puisque dmsetup en dépend.

En consultant la liste des bugs de ce paquet, on retrouve le numéro 542422 dont l'historique retrace le problème rencontré et donne quelques explications essentielles.

Si on suit la même démarche avec le paquet grub-common qui contient la commande grub-probe, on retrouve le numéro 542435 qui lui aussi correspond parfaitement au problème rencontré. On trouve même une référence au bug cité précédemment.

This is now fixed with 

lvm2 (2.02.51-2) unstable; urgency=low

  * Make mapper/* the real device, dm-* a symlink. (closes: #542422)

Enfin, maintenant que les causes sont bien identifiées et que le problème a été corrigé, il reste à trouver la méthode de correction des entrées mal référencées. En revenant à la liste des bugs du paquet dmsetup, on trouve le numéro 543795 qui propose une commande de correction en forçant une nouvelle exécution du processus de création pour chaque entrée de périphérique.

# echo change > /sys/block/dm-0/uevent

Une fois ce traitement fait, les entrées /dev/dm-* sont redevenues des liens symboliques pointant vers les fichiers nodes du répertoire /dev/mapper/ et le gestionnaire d'amorce GRUB fonctionne à nouveau.

Voici donc un exemple d'utilisation du processus d'assurance qualité de la distribution Debian. Cet exemple est représentatif de l'importance de la diffusion de l'information en toute transparence. Avec un système propriétaire, il serait tout simplement impossible de mener la démarche décrite dans ce billet.

Ceci-dit, le processus à ses limites. Si le paquet qui fournit la fonctionnalité n'est pas très utilisé ou que les utilisateurs ne prennent pas le temps de remonter les problèmes, la dynamique de la démarche qualité se rompt facilement et tous les bénéfices sont perdus.

Ce document est disponible en version imprimable au format PDF : dmsetup-udev.pdf.

$Id: dmsetup-udev.xml 1419 2009-09-19 13:00:41Z latu $

Les deux logiciels phares de gestion du lancement de système d'exploitation qui dominent le monde GNU/Linux sont : LILO et GRUB.

LILO ou LInux LOader est la solution historique avec laquelle j'ai débuté il y a quelques années déjà. À l'usage, le fait de devoir passer par une écriture du Master boot record (MBR) à chaque modification du ou des noyaux utilisables sur un système et le manque d'options lors de l'initialisation de la machine ont conduit à l'émergence d'un nouveau gestionnaire de démarrage. De plus, il semble que le développement de LILO ait été abandonné.

GRUB ou GRand Unified Bootloader est la solution qui a gagné les faveurs de la majorité des distributions GNU/Linux. Relativement au gestionnaire historique, il est possible de modifier les paramètres de démarrage du système d'exploitation lors de l'initialisation de la machine. De plus, le système de menus permet d'offrir plus de choix aux utilisateurs novices.

Si l'on doit retenir une différence de conception importante entre les deux gestionnaires d'amorce, c'est la capacité à accéder à un système de fichiers. En effet, LILO utilise les fonctions du BIOS pour accéder directement au contenu du disque dur sans se préoccuper du système de fichiers utilisé. À l'inverse, GRUB a besoin de reconnaître un système de fichiers ext2 pour accéder à l'ensemble de ses fonctions et menus.

Suivant les cas de figure, cet accès à un système de fichiers peut être un avantage ou un gros inconvénient comme on le voit ci-dessous.

Même si les fonctionnalités offertes par GRUB sont très séduisantes, le développement de cet outil connaît quelques soubresauts assez gênants : Le billet The grub drama publié sur Planet Debian au printemps dernier résume assez bien les griefs nés entre utilisateurs et développeurs suite à la décision d'initier un nouveau développement.

Ensuite, les soucis récents sont venus des contradictions entre le développements des règles udev de création des entrées de l'arborescence des périphériques et d'autres outils ; dont GRUB.

L'histoire commence avec une énième mise à jour du noyau et un «pic de stress» en constatant que la liste des noyaux disponibles donnée par la commande update-grub -v est vide. La commande ci-dessus n'étant qu'un script shell, une nouvelle exécution en mode debug via la directive sh -x montre que c'est le programme grub-probe qui échoue lamentablement dans la reconnaissance du système de fichiers !

Une fois de plus, Google n'est pas mon ami et la quasi totalité des liens renvoyés correspondent à des listes de disques érronées dans le fichier device.map. Sur mon transporable, il n'y a qu'un disque SATA référencé /dev/sda ; donc peu de chance de se tromper de ce côté là.

Voici une copie du fichier /etc/fstab qui montre une utilisation du gestionnaire de volumes logiques LVM2.

$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/mapper/Amethyste-root /               ext4    errors=remount-ro 0       1
/dev/sda1                  /boot           ext3    defaults        0       2
/dev/mapper/Amethyste-home /home           ext4    defaults        0       2
/dev/mapper/Amethyste-tmp  /tmp            ext4    defaults        0       2
/dev/mapper/Amethyste-usr  /usr            ext4    defaults        0       2
/dev/mapper/Amethyste-var  /var            ext4    defaults        0       2
/dev/mapper/Amethyste-swap none            swap    sw              0       0
/dev/hda                   /media/cdrom0   udf,iso9660 user,noauto     0       0

Relativement à ces définitions de points de montages, l'exécution de la commande mount ne correspond pas tout à fait. Les entrées du répertoire /dev/mapper ne sont pas utilisées.

$ mount
/dev/dm-0 on / type ext4 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
/dev/sda1 on /boot type ext3 (rw)
/dev/dm-4 on /home type ext4 (rw)
/dev/dm-2 on /tmp type ext4 (rw)
/dev/dm-3 on /usr type ext4 (rw)
/dev/dm-5 on /var type ext4 (rw)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
capifs on /dev/capi type capifs (rw,mode=0666)

À ce moment là, je n'ai pas vu le lien entre les points de montages et grub-probe. J'ai donc tenté un redémarrage de la machine. C'est là que le drame s'est produit : plus de noyau accessible ! La machine était inutilisable.

Dans mon billet précédent sur les joies de la gestion de parc avec Ghost, j'avais déjà eu à utiliser la version 6.0.0 de KNOPPIX pour jouer avec les propriétés du systèmes de fichiers ext3. Une fois de plus, ce live-cd a servi à récupérer une situation calamiteuse.

Une fois la machine initialisée avec KNOPPIX, je suis logiquement retombé sur le même problème avec grub-probe. Cette commande refusait obstinément de reconnaître le moindre système de fichiers. Il était bien possible d'installer GRUB, mais une fois le Shell lancé, les commandes root DEVICE et setup DEVICE échouaient.

C'est là que l'idée d'utiliser LILO s'est imposée. Il fallait nécessairement utiliser un gestionnaire d'amorce qui ne dépende absolument pas d'un accès aux systèmes de fichiers du disque de la machine.

Là où l'utilisation de KNOPPIX devient intéressante, c'est que même lorsqu'un outil n'est pas disponible sur le CD il est toujours possible d'utiliser le gestionnaire de paquets et d'accéder via le réseau aux dépôts Debian. Une fois le câble réseau de la machine branché et une requête DHCP plus tard, il était possible d'installer LILO.

Lors de l'initialisation du CD, j'ai l'habitude de donner les options suivantes :

# knoppix lang=fr 2

Une fois que l'accès au réseau est établi, on utilise la gestion de paquets de façon tout à fait classique :

# apt-get update
# apt-get install lilo

La gestion de volume logiques n'est pas activée automatiquement lors de l'initialisation du live-CD. Il est donc nécessaire de le faire manuellement.

# modprobe dm-mod
# vgchange -a y
# lvdisplay -c
File descriptor 7 (/proc/6669/status) leaked on lvdisplay invocation. Parent PID 11242: bash
  /dev/Amethyste/root:Amethyste:3:1:-1:1:1048576:128:-1:0:-1:254:0
  /dev/Amethyste/swap:Amethyste:3:1:-1:2:4194304:512:-1:0:-1:254:1
  /dev/Amethyste/tmp:Amethyste:3:1:-1:1:1048576:128:-1:0:-1:254:2
  /dev/Amethyste/usr:Amethyste:3:1:-1:1:25165824:3072:-1:0:-1:254:3
  /dev/Amethyste/home:Amethyste:3:1:-1:1:125829120:15360:-1:0:-1:254:4
  /dev/Amethyste/var:Amethyste:3:1:-1:1:154787840:18895:-1:0:-1:254:5

Une fois que le noyau est au courant de la présence des volumes logiques, on peut commencer les manipulations sur le gestionnaire d'amorce. On commence par le montage manuel des partitions ou volumes nécessaires.

# mount /dev/Amethyste/root /mnt
# mount /dev/sda1 /mnt/boot

La partie la plus facile à traiter est l'écriture du Master Boot Record. Cette étape passée, GRUB à disparu.

# lilo -M /dev/sda mbr

Vient ensuite la phase de configuration à l'aide du fichier /etc/lilo.conf. Fort heureusement, un fichier exemple est fourni dans la documentation du paquet LILO : /usr/share/doc/lilo/examples/conf.sample. Sur la base de cet exemple, on s'adapte au contexte de la machine.

# cat /mnt/etc/lilo.conf
# /etc/lilo.conf: Sample Debian LILO boot loader configuration.

boot=/dev/sda1
root=/dev/mapper/Amethyste-root
compact
large-memory

# To use the new LILO boot menu, add the following
bitmap=/boot/sid.bmp
bmp-colors=1,,0,2,,0
bmp-table=120p,173p,1,15,17
bmp-timer=254p,432p,1,0,0
install=bmp

# install=menu
map=/boot/map
vga=normal
delay=20
timeout=150
prompt

image=/vmlinuz
        root=/dev/mapper/Amethyste-root
        initrd=/initrd.img
        label=Linux
        read-only

image=/vmlinuz
        root=/dev/mapper/Amethyste-root
        initrd=/initrd.img
        label=Linux_single
        append=" single "
        read-only

image=/vmlinuz.old
        root=/dev/mapper/Amethyste-root
        initrd=/initrd.img.old
        label=Linux_old
        read-only

Dernière étape essentielle, il faut appliquer cette configuration à l'aide d'une nouvelle écriture dans le Master Boot record.

# lilo -r /mnt/

Après réinitialisation de la machine, on dispose à nouveau d'une liste de noyaux et le système d'exploitation se lance normalement. Une seule réaction OUF !

Voilà comment échapper à une grosse galère sur la gestion du démarrage d'un système. Même si LILO n'est plus du tout le gestionnaire d'amorce en vogue, il peut s'avérer fort utile et le fait qu'il ne dépende d'aucun accès à un système de fichier est un avantage déterminant dans certains cas. Il est vraiment dommage que son développement se soit arrêté.

Dans le prochain billet, je dois traiter le problème de la gestion des entrées de périphériques LVM2 via udev ou dmsetup. Tous mes soucis venaient en fait de là !

Ce document est disponible en version imprimable au format PDF : lilo-revival.pdf.

$Id: lilo-revival.xml 1417 2009-09-12 10:17:12Z latu $

La documentation officielle du produit annonce un support du système de fichiers ext3 dans la gestion des images. Ce support apparaît aujourd'hui comme complètement dépassé et la restauration d'un système de fichiers issu de l'installation classique de la distribution Debian GNU/Linux stable échoue systématiquement.

Si le système de fichiers ext3 avait été publié récemment ou si ses spécifications n'étaient pas ouvertes, cette situation serait «prévisible». Or, il n'en est rien ; ext3 est devenu le système de fichiers par défaut des distributions GNU/Linux il y a plusieurs années et ses évolutions sont parfaitement connues.

On peut donc s'étonner légitimement en constatant qu'un logiciel de gestion de parc qui se veut professionnel n'ait pas intégré la moindre évolution. Comment se fait-il que l'on puisse procéder à un archivage à partir d'un jeu de paramètres figé sans même relever, à l'aide d'une simple lecture, l'état du système de fichiers courant ?

La commande tune2fs nous renseigne simplement sur les caractéristiques du système de fichiers. Voici un exemple extrait d'une installation récente.

# cat /etc/issue
Debian GNU/Linux 5.0 \n \l

# tune2fs -l /dev/mapper/vm--debian-usr | egrep 'features|Inode size'
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Inode size:               256

L'extrait ci-dessus illustre les deux principales caractéristiques non supportées par Symantec Ghost™ en version 11. Pour pouvoir archiver une installation il est nécessaire de dégrader le système de fichiers ext3.

Après de multiples itérations d'archivage/restauration d'une image Symantec Ghost™, les deux paramètres sensibles qui ressortent sont les suivants.

Voici donc un exemple de commande de formatage à utiliser pour obtenir un système de fichiers ext3 dégradé mais permettant de créer des archives utilisables avec Symantec Ghost™ en version 11.

# mkfs.ext3 -I 128 -O^resize_inode,^dir_index /dev/sda3

Dans cet exemple, /dev/sda3 désigne la partition sur laquelle le système GNU/Linux doit être installé.

Comme il n'est logiquement pas possible de dégrader le système de fichiers lors de l'installation du système, on doit passer par un transfert intermédiaire lors de la création du poste maître.

Voilà comment échapper à un piège supplémentaire posé par un logiciel propriétaire ! Bien évidemment, si cette «recette» a le mérite de fonctionner, il doit certainement être possible de faire mieux. N'hésitez pas à me contacter si vous avez des propositions ;)).

Ce document est disponible en version imprimable au format PDF : lenny-ghost.pdf.

$Id: lenny-ghost.xml 1410 2009-07-11 16:27:57Z latu $

Les routeurs 1841 fournis dans le bundle sont d'excellentes machines qui permettent de faire les manipulations des curriculas CCNA et CCNP BSCI dans des conditions très confortables.

Sur ces modèles, le système d'exploitation (IOS) est stocké sur une mémoire de type CompactFlash. Dans le contexte de cet article, la capacité de stockage est limitée à 32Mo, ce qui ne permet pas de faire cohabiter le système d'exploitation et SDM sur la même carte.

Heureusement, il existe une astuce assez répandue qui consiste à télécharger le fichier image du système d'exploitation à partir d'un serveur TFTP lors de l'initialisation du routeur. De cette façon, on économise l'espace de stockage du système et on peut implanter les fichiers nécessaires au fonctionnement de SDM à la place.

Pour la mise en œuvre d'un serveur TFTP, il est possible de consulter la section correspondante de l'article Gestion des équipements réseau avec GNU/Linux. Ici, on considère que le service TFTP est disponible.

Du point de vue de l'organisation des travaux pratiques, ce mode de fonctionnement impose une connexion particulière lors de la mise sous tension des routeurs en début de séance. Il faut que le port FastEthernet fa0/0 soit raccordé à un commutateur qui permette de joindre le service TFTP de la salle. Dans le cas de l'architecture STRI, la passerelle de la salle joue justement ce rôle.i

Une fois la phase d'initialisation du système d'exploitation achevée, il est possible de rebrasser et reconfigurer les interfaces réseau suivant les besoins des questions de travaux pratiques.

Autre contrainte, en fin de séance il est nécessaire de restaurer une configuration minimale contenant les instructions nécessaires au rechargement du système via TFTP lors de la remise sous tension suivante du routeur.

Voici les opérations de préparation d'un routeur 1841 en fonction des éléments énoncés.

Dans l'exemple qui suit, l'adresse IP du routeur est 192.168.1.3 et celle du serveur TFTP est 192.168.1.1.

Dans certains cas, la manipulation ci-dessus ne suffit pas et une image système doit nécessairement être présente sur la mémoire flash avant le téléchargement réseau. Il s'agit probablement d'un problème de gestionnaire de démarrage (boot loader) qui se bloque sur l'absence d'image système en mémoire flash. Il est donc nécessaire de placer une image système la plus petite possible de façon à répondre à l'objectif initial : installer SDM.

Voici un extrait du processus d'initialisation en trois étapes.

Router#reload
Proceed with reload? [confirm]

*Jun 16 07:09:22.619: %SYS-5-RELOAD: Reload requested  by console. Reload Reason: Reload Command.
System Bootstrap, Version 12.4(13r)T5, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 2007 by cisco Systems, Inc.
PLD version 0x10
GIO ASIC version 0x127
c1841 platform with 131072 Kbytes of main memory
Main memory is configured to 64 bit mode with parity disabled


Upgrade ROMMON initialized
program load complete, entry point: 0x8000f000, size: 0xcb80
program load complete, entry point: 0x8000f000, size: 0xcb80

program load complete, entry point: 0x8000f000, size: 0xc7d244
Self decompressing the image : ######<snipped/>################# [OK]

Smart Init is enabled
smart init is sizing iomem
ID            MEMORY_REQ         TYPE
Unable to read eeprom
                0X003AA110 public buffer pools
                0X00211000 public particle pools
0X0013          0X00035000 Card in slot 1

If any of the above Memory Requirements are
"UNKNOWN", you may be using an unsupported
configuration or there is a software problem and
system operation may be compromised.

Allocating additional 8246951 bytes to IO Memory.
PMem allocated: 117440512 bytes; IOMem allocated: 16777216 bytes

%Error opening tftp://192.168.1.1/c1841-ipbasek9-mz.124-24.T.bin (Timed out)
Retrying...

Loading c1841-ipbasek9-mz.124-24.T.bin from 192.168.1.1 (via FastEthernet0/0): !!
<snipped/>!!!!!!!!!!!!!!!!!!!!!!!!!
[OK - 27542552 bytes]
program load complete, entry point: 0x8000f000, size: 0x1a44278
Self decompressing the image : ######<snipped/>################# [OK]

Le routeur est maintenant prêt. Il reste à traiter le volet interface utilisateur sur le poste de travail.

La principale difficulté rencontrée lors de l'utilisation de SDM vient de son intégration sur le poste de travail. Côté routeur, Cisco™ a une «bonne maîtrise du système». Dès que l'on sort du châssis de l'équipement réseau, c'est une autre affaire.

Tout comme dans la section précédente, on a recours à une astuce pour utiliser un navigateur 32 bits et une machine virtuelle Java ancienne. Les opérations présentées ci-après sont effectuées sur un poste de travail installé et configuré avec une distribution Debian GNU/Linux AMD64. Normalement, n'importe quelle installation de distribution doit faire l'affaire dans la mesure où la configuration mise en œuvre ne dépend pas du gestionnaire de paquets.

Au risque de paraître «lourd», il faut rappeler que ce qui suit n'est pas du tout conforme à une bonne pratique d'administration système qui veut que le gestionnaire de paquets ne propose que des paquets contenant les derniers correctifs de sécurité.

Une fois la validation terminée, il est possible de constituer une archive de sauvegarde de cette configuration de navigation dans l'arborescence utilisateur.

:~/cna$ tar cjf sdm-firefox.tar.bz2 sdm/
:~/cna$ ls -sh sdm-*
66M sdm-firefox.tar.bz2

Voilà ! Si vous êtes arrivés jusque là vous disposez d'une interface d'utilisation de Security Device Manager fonctionnelle. Il ne reste plus qu'à implanter le navigateur «local» sur l'image maître des postes de la salle de travaux pratiques. Pour les quatre routeurs 1841 du bundle, il est possible d'implanter un fichier de configuration type à recharger depuis le serveur TFTP.

Le mode d'exploitation présenté ici est certainement critiquable en bien des points. Si vous avez d'autres propositions, n'hésitez pas à en faire part !

Merci d'avoir eu le courage de lire ces lignes jusqu'à la fin.

Ce document est disponible en version imprimable au format PDF : sdm-ccna.pdf.

$Id: sdm-ccna.xml 1405 2009-06-19 15:50:48Z latu $

Voilà de nombreuses années que j'ai pris l'habitude d'utiliser une configuration d'interface graphique à «double tête» : un écran pour les manipulations personnelles et un écran de vidéo-projection à destination des étudiants. De cette façon, il est possible de consulter des notes différentes des vues projetées lors d'un cours ou de préparer une configuration sur un équipement pendant que les étudiants traitent une série de questions lors d'une séance de travaux pratiques.

Du point de vue du gestionnaire graphique X.Org, cette configuration à «double tête» était basée sur l'extension Xinerama. Cette extension permet de disposer de deux écrans de configuration indépendante. Avec les version KDE 3.5.x, le gestionnaire de bureau est aussi indépendant : fond d'écran, icônes, raccourcis, etc. Depuis le passage à X.Org 1.6.1 et KDE 4.2, tout çà ne fonctionne plus du tout. L'interface X.Org redémarre de façon aléatoire et certaines touches du clavier bloquent l'interface graphique. Il a donc fallu reprendre la configuration à zéro.

Dans les sections suivantes, on trouve une description point par point des choix retenus pour revenir à un fonctionnement nominal.

Avec l'arrivée des paquets de la version 1.6.1 de xorg, on passe à un mode de reconnaissance dynamique des périphériques d'entrée. Normalement, les fichiers de configuration historiques comportant les définitions de ces mêmes périphériques devraient être correctement gérés. Force est de constater que ce n'est pas toujours le cas.

Une fois ces deux opérations effectuées, il reste à supprimer les sections InputDevice correspondantes du fichier /etc/X11/xorg.conf ainsi que les références dans la section ServerLayout. Voir la section intitulée « Le fichier de configuration xorg.conf ».

Cette extension est une option propriétaire du constructeur NVIDIA disponible uniquement avec les pilotes propriétaires des cartes graphiques de la marque. Au moment de la rédaction de ces lignes, c'est la version 180.51 qui est utilisée.

L'outil nvidia-settings autorise la reconfiguration dynamique de la disposition des écrans avec l'extension TwinView.

Dans le cas qui nous intéresse, on place le deuxième écran ou le vidéo projecteur à droite de l'écran du portable. Du point de vue configuration, on active l'extension TwinView dans la section de l'écran du portable et on positionne le second écran à droite en ajoutant le nombre de pixels nécessaires.

Ici, la définition graphique du portable, référencé DFP est de 1920x1200. On ajoute donc 1920 pixels à la position du second écran référencé CRT. Ce mode d'utilisation de l'extension est appelé DynamicTwinView.

Option "metamodes" " DFP: 1920x1200 +0+0, CRT: nvidia-auto-select +1920+0"

Les options de l'extension sont présentées au chapitre 13 de la documentation NVIDIA dans le fichier /usr/share/doc/NVIDIA_GLX-1.0/README.txt. Cette même documentation est aussi disponible en ligne.

Voir la section intitulée « Le fichier de configuration xorg.conf » pour avoir une vue complète du fichier de configuration. Une fois que cette configuration est activée, on obtient le résultat suivant.

Dans le cycle amour/haine entre GNU/Linux et NVIDIA, on peut regretter qu'il n'existe pas encore de pilotes de carte graphique libres à 100% qui permettent d'obtenir le même mode de fonctionnement. Le fait qu'Intel ait publié l'ensemble des spécifications de ses composants graphiques finira peut-être par contraindre les autres constructeurs à suivre la même démarche.

Pour utiliser correctement la configuration «double tête» avec une présentation, il faut distinguer les applications utilisées.

Voilài ! Ce billet est là pour relativiser l'enthousiasme de la migration de l'environnement graphique KDE 4.2. Sans sombrer dans la déprime et passer à Gnome, on constate simplement que toutes les difficultés ne sont pas soldées. Les évolutions sont tellement importantes que les migrations d'une version à l'autre entraînent pas mal de désagréments. Nous avons été bien mal habitués ces dernières années en utilisant les paquets de la branche unstable jour après jour sans rencontrer la moindre difficulté.

Je serais beaucoup plus sévère sur les distributions qui proposent des versions «intermédiaires» sans assurance qualité aux utilisateurs novices. Ce n'est définitivement pas le meilleur moyen d'attirer de nouveaux utilisateurs dans le monde du logiciel libre.

Enfin, il existe une extension du projet X.Org que je n'ai pas pris le temps d'évaluer : XRandR qui doit permettre d'obtenir les mêmes résultats avec des cartes graphiques d'autres marques ; Intel notamment. Si j'ai l'occasion de tester un netbook un jour, il faudra l'envisager sérieusement. Pour l'instant, je reste fidèle au transportable M6300 sur lequel on peut «faire tourner» une petite collection d'instances virtuelles de systèmes (et|ou) de routeurs.

Ce document est disponible en version imprimable au format PDF : xorg-hal-twinview.pdf.

$Id: xorg-hal-twinview.xml 1390 2009-05-11 20:24:10Z latu $

Le fichier ci-dessous est assez «léger» relativement à ce que l'on a connu dans le passé ! Toutes les sections InputDevice ont été supprimées. L'extension Xinerama a été désactivée globalement et l'extension TwinView a été activée dans la définition des paramètres de l'écran ; c'est à dire la section Screen.

Section "ServerLayout"
        Identifier     "Default Layout"
        Screen      0  "NVIDIA Quadro FX 1600M" 0 0
EndSection

Section "ServerFlags"
        Option         "Xinerama" "0"
EndSection

Section "Files"
        RgbPath         "/usr/lib/X11/rgb"
EndSection

Section "Module"
        Load           "dbe"
        Load           "extmod"
        Load           "glx"
EndSection

Section "Monitor"
        Identifier      "Laptop"
        ModelName       "Seiko"
        Option          "DPMS"
EndSection

Section "Device"
        Screen          0
        Identifier      "NVIDIA Quadro FX 1600M"
        Driver          "nvidia"
        VendorName      "NVIDIA Corporation"
        BusID           "PCI:1:0:0"
        Option          "Coolbits"              "1"
EndSection

Section "Screen"
        Identifier      "NVIDIA Quadro FX 1600M"
        Device          "NVIDIA Quadro FX 1600M"
        Monitor         "Laptop"
        DefaultDepth    24
        Option          "TwinView" "1"
        Option          "TwinViewXineramaInfoOrder" "DFP-0"
        Option          "TwinviewXineramaInfo"  "True"
        Option          "metamodes" " DFP: 1920x1200 +0+0, CRT: nvidia-auto-select +1920+0"
        SubSection "Display"
                Depth   24
        EndSubSection
EndSection