| Le royaume de Eric Buist >> Informatique >> Configuration informatique | ||
| Me contacter | Plan du site | |
| << Résurrection de Linux | Mise à jour à RedHat 7.3 | Support ACPI sous Windows XP >> |
Lundi, 20 mai 2002, je me suis décidé à entamer le téléchargement de la version 7.3 de RedHat Linux. Comme d'habitude, l'opération fut plutôt... rock'n roll! Afin de profiter du gestionnaire de téléchargement Download Accelerator Plus, je devais l'effectuer sous Windows et Internet Explorer allait servir à établir les premiers contacts avec les sites FTP. Les adresses des sites miroirs sont inscrites sur une page Web et il serait long et fastidieux de les copier/coller une par une dans un client FTP, effectuer le branchement, puis trouver le fichier. Souvent, un clic sur un site FTP provoquait un blocage complet d'Internet Explorer et il fallait alors tuer le processus avec CTRL+ALT+DEL. Lorsqu'un branchement était établi, il fallait par la suite accéder au site, trouver les images ISO puis copier/coller l'URL complète afin de la passer à DAP.
Il y avait un total de six images ISO et la connexion était extrêmement lente, car j'avais mal choisi mes miroirs. Je finis par le découvrir et parvins enfin à accélérer les choses un peu. À quelques reprises, je me demandai s'il serait possible, cette fois, d'obtenir Linux de cette façon. Dans le cas contraire, il m'aurait fallu soit acheter une distribution, soit tenter de tomber sur quelqu'un qui aurait eu plus de chance que moi... J'effectuais cette mise à jour en grande partie pour passer à KDE 3 et obtenir une version intégrée à ma distribution de XFree86 4.2, version à partir de laquelle les fonctionnalités 3D de ma carte ATI sont prises en charge par le DRI.
Samedi, le 25 mai 2002, je disposais enfin de tous les fichiers et j'avais gravé les disques. Tout était fin prêt pour la réinstallation. Tout d'abord, je supprimai ma partition ext2fs pour en créer une nouvelle. En fait, j'aurais simplement pu la reformater sans la supprimer. Je dus indiquer au programme d'installation de monter cette partition dans /, comme d'habitude en fait. La procédure se passa comme un charme, sauf que des surprises m'attendaient...
J'eus beau le chercher sur les 3 CD de la distribution, le logiciel de configuration avait disparu complètement. C'est pourtant avec ce dernier que je configurais le réseau, les points de montage, les utilisateurs, ... Bref, c'est un gros morceau que je perds là! Le point de montage de ma partition de données fut configuré à la main. J'utilisai man fstab afin de connaître la syntaxe du fichier /etc/fstab et j'y ajoutai la ligne nécessaire.
/dev/hda6 /mnt/data vfat auto,nouser,rw,umask=0 0 0
L'option auto indique de monter le disque au démarrage, nouser indique que l'utilisateur ne peut ni le démonter, ni le monter. rw active la possibilité de lire et écrire tandis que le umask=0 indique de n'inhiber aucun droit. Ainsi, l'usager peut lire et écrire dans tous les répertoires, comme c'est le cas sur un lecteur FAT32 sous Windows. Je dus aussi paramétrer pour permettre l'utilisation du CD-ROM par l'utilisateur. J'indiquai owner et user comme options de montage.
GRUB n'avait pas détecté Windows XP et je dus lui indiquer où le trouver afin que le système apparaisse dans le menu. Ce qui se résuma à calquer l'entrée commentée pour le DOS.
title Windows XP Professionnel
rootnoverify (hd0,0)
chainloader +1
Dès que ces lignes furent ajoutées à /etc/grub.conf, Windows XP put démarrer de nouveau grâce au boot loader.
Restait le problème de la configuration réseau. Je découvris, sur le Bureau KDE, une icône Control Panel qui activait un panneau de configuration regroupant plusieurs outils de configuration RedHat. J'y découvris un outil de configuration réseau avec lequel je pus effectuer le travail.
Je nommai la machine faucondefer.buistgroup.ca, ce qui eut pour effet de modifier /etc/hosts et /etc/sysconfig/network. Le dernier fichier reçut également l'IP de la passerelle, soit 192.168.0.1. En utilisant le logiciel de configuration, j'assignai à ma carte réseau une IP fixe, soit 192.168.0.2, masque de sous-réseau 255.255.255.0. C'est la seule façon d'avoir le réseau et de pouvoir démarrer ma machine Linux sans que l'ordinateur familial soit toujours ouvert. Ce qui eut pour effet de modifier le fichier /etc/sysconfig/networking/devices/ifcfg-eth0. Le fichier /etc/resolv.conf contenait le nom du DNS utilisé, soit 192.168.0.1, lorsque la manipulation fut terminée. Je lui indiquai d'utiliser le domaine buistgroup.ca, ce qui ne veut rien dire, mais il en voulait un...
Il allait encore me falloir installer XEmacs, mais je ne me souvenais plus de quels packages il fallait installer. Malheureusement, utiliser rpm pour installer le package xemacs-21.4.6-7 ne suffisait pas, car libcanna.so et libpq.so étaient nécessaires. Naturellement, aucun package ne portait ce nom!
Il me fallut user d'astuce pour retrouver ces librairies. Tout d'abord, je dus dresser la liste de tout ce que procurait chacun des packages de la distribution de RedHat! Heureusement, une simple ligne de commande permet de l'obtenir pour un disque donné. Après avoir inséré le disque, j'ai tapé quelques commandes.
mount /mnt/cdrom cd /mnt/cdrom/RedHat/RPMS for i in *.rpm; do echo $i; rpm -qp --provides $i; done > ~/diskx.txt
Chacun des fichiers fut alors examiné et, grâce à la fonction de recherche de GNU Emacs, je pus trouver dans quelques packages se trouvait quoi.
| Package | Librairie | Disque |
|---|---|---|
| Canna-libs-3.5b2-62 | libcanna.so | 1 |
| postgresql-libs-7.2.1-5 | libpq.so | 2 |
| xemacs-21.4.6-7 | - | 3 |
| xemacs-info-21.4.6-7 | - | 3 |
Bref, rock'n'roll! XEmacs fonctionnait après tout cela, mais il restait à paramétrer la taille des polices. J'utilise actuellement la fonte LucidaBright, avec une taille de 24 points depuis que j'ai augmenté ma résolution à 1024x768. Malheureusement, l'éditeur affiche certaines fontes en minuscule et il n'y a rien à faire pour lui indiquer de faire autrement d'une façon simple et rapide. Avec le temps, j'ai aussi découvert que quelques lignes étaient absolument nécessaire dans ~/.xemacs/init.el, soient
(require 'tex-site)
(setq bell-volume 0)
(setq sgml-catalog-files (append sgml-catalog-files '("/usr/lib/xemacs/xemacs-packages/etc/psgml/CATALOG")))
La première active le système AuC-TeX, utile pour les documents LaTeX. La seconde inhibe les beeps très fatigants que l'éditeur émet encore avec le PC Speaker. La troisième indique où trouver les DTD pour le HTML, ce qui permet d'utiliser le mode HTML de l'éditeur pour travailler sur des pages Web. Sans cette ligne, je recevais constamment le message External entity not found et l'indentation était très mauvaise.
Mon modem Intel MD5628D me causa aussi des problèmes infinis lors de cette mise à jour. Je constatai rapidement que le pilote développé par Intel ne supportait pas le kernel 2.4.18. Une version était disponible pour les kernels 2.2, l'autre allait jusqu'à 2.4.12. Il allait me falloir oublier le modem ou recompiler une ancienne version du noyau. Pour un modem, cela n'en valait pas le coup, mais je voulais tout de même le faire fonctionner.
Avant de tenter la compilation, il fallut bien entendu installer le package kernel-source-2.4.18-3 afin de disposer du code source du noyau et des en-têtes requises pour compiler les modules pour le modem.
Je tentai malgré tout de compiler le pilote et j'eus droit à des messages d'erreur incompréhensibles. Je tentai alors d'obtenir une version à jour du fichier et j'obtins le fichier Intel-v92ham-440-RH72. La commande make ham, utilisée à l'intérieur du répertoire produit en décompressant le fichier, provoqua de nouvelles erreurs.
Si je tenais à faire fonctionner ce modem sous Linux, il allait me falloir modifier ce pilote! Je découvris que le bogue venait d'une macro, EXPORT_SYMBOLS_NOVERS. En examinant cette macro, je découvris un moyen de contourner le bobo. Dans le fichier coredrv/makefile, je dus modifiai la ligne CFLAGS pour y ajouter -DEXPORT_SYMTAB. Après cette découverte relevant d'un peu de logique, de chance et de devinette, le module principal du pilote du modem, hamcore, compila avec succès!
Toutefois, le serial driver servant d'interface entre ce module principal et l'utilisateur s'obstinait à ne pas compiler. Le fichier serialdrv/clmdrvr.c ne compilait pas pour xyz raisons. L'erreur était due à un champ interne d'une structure qui n'existait plus. Il semblait nécessaire qu'Intel révise le pilote une nouvelle fois et en attendant, je retournais à la case départ: pas de modem sous Linux. Heureusement, je n'en ai pas besoin, car j'accède à Internet par carte réseau, mais je voulais le faire fonctionner!
Aux grands maux les grands moyens! J'ouvris le fichier problématique dans XEmacs et localisai la ligne causant l'erreur, soit la ligne 776 dont voici le texte
current->counter = 0; /* make us low-priority*/
Cela ressemblait à une petite optimisation, le jeu en valait la chandelle; je la commentai! Cela fonctionna, le pilote compila enfin et je pus exécuter le reste de la procédure d'installation pour l'intégrer à mon noyau. Quelques raffinements furent nécessaires pour permettre à l'utilisateur d'accéder au modem, mais il semble fonctionner. Je faillis en conclure autrement lors d'un test avec l'utilitaire minicom, car celui-ci se bloquait sans établir de communication avec le modem. Je me rappelai toutefois qu'il fallait utiliser, au moins une fois et en root, la commande minicom -s afin de configurer le logiciel de communication. Par défaut, minicom utilise un modem branché sur /dev/ttyS0. Je dus lui apprendre que le modem se trouvait dans /dev/modem, un lien symbolique vers /dev/ham. On ne saura toutefois jamais si ce pilote est réellement fonctionnel, les conséquences de mon acte plutôt téméraire pourraient se faire sentir à tout moment!
Un tel scénario démontre toutefois clairement la flexibilité qu'offre un système à code source ouvert. Sous Windows, une telle incompatibilité aurait été impossible à lever temporairement. Bien entendu, lorsque je saurai qu'Intel a fabriqué un nouveau pilote fonctionnant réellement pour mon kernel, je le mettrai en place!
Imprimer sous Linux avec une imprimante non PostScript relève parfois du tour de magie! J'eus droit à des problèmes lors de ma première tentative d'impression sous mon nouveau système Linux. La commande lpr ne fonctionnait pas, car le daemon lpd ne tournait pas du tout. Je tentai donc, en root, de passer la commande /etc/rc.d/init.d/lpd restart, ce qui eut pour effet d'afficher un message d'erreur. Non seulement lpd ne fonctionnait-il pas, en plus il ne voulait pas fonctionner!
TurboPrint, le logiciel me permettant d'imprimer sous Linux avec plus de simplicité qu'avec les outils de RedHat, causait décidément problème. J'utilisai donc xtpsetup pour tenter de reconfigurer les imprimantes; ma Canon était bien là. Et pourtant, lpd ne la détectait pas, car elle ne figurait pas dans /etc/printcap. Je découvris que le Common UNIX Printing System (CUPS) avait été installé dans RedHat 7.3 et TurboPrint l'avait pris en charge au lieu du système LPRng. lpr, lpq, lprm et compagnie n'avaient donc plus cours. Je tentai de trouver les équivalents, rien à faire. On aurait dit que pour contrôler CUPS, il fallait impérativement appeler des fonctions de librairie ou, pour l'utilisateur, utiliser la fonction Print des applications KDE qui proposait de choisir entre LPRng et CUPS pour l'impression.
Désireux de conserver la possibilité de contrôler mon imprimante, je tentai de contourner le bobo, mais rien à faire: TurboPrint se prenait toujours les pieds dans CUPS. Je dus donc supprimer complètement les packages cups et cups-drivers.
TurboPrint voulait toujours en découdre. Conservateur, il cherchait à reconfigurer son affaire avec CUPS. Je devrais donc supprimer ses fichiers de configuration. Je supprimai donc le répertoire /etc/turboprint, mais le logiciel ne voulait plus se reconfigurer du tout, car il manquait d'informations.
Je dus donc le réinstaller, mais la bête se réinitialisa sur CUPS de nouveau. Je dus finalement tenter de modifier la configuration, un fichier /etc/turboprint/system.cfg semblait un bon candidat et il contenait la ligne TP_CUPS=1. Je la remplaçai par TP_CUPS=0 puis essayai de nouveau. Enfin, cela fonctionna après un nouveau xtpsetup! Le démarrage de lpd réussit par la suite et je pus imprimer!
J'aime qu'après un certain temps d'inutilisation, l'écran de mon ordinateur s'éteigne automatiquement pour ne se rallumer qu'à l'appui sur une touche de clavier ou au mouvement de la souris. Malheureusement, ce réglage n'est pas acquis sous X. Sous KDE, on peut le régler à l'aide du Control Panel, mais il n'est pas effectif lorsque KDE ne tourne pas. Il n'est pas system-wide.
La commande xset permet d'effectuer des réglages au niveau du serveur X. Avec le temps, et un man xset, j'avais découvert que xset dpms standby suspend off permettait de configurer le nombre de secondes après lesquelles l'écran entrait dans les modes d'énergie minimale. Je pensais donc placer la ligne xset dpms 900 1050 1200 le plus tôt possible dans la séquence d'amorçage de X. Je décidai de la placer dans /etc/X11/prefdm. Je découvrirais plus tard qu'elle n'a là aucun autre effet que d'afficher un message d'erreur qui se perd.
Afin de paramétrer les options DPMS par défaut, une modification du fichier /etc/X11/XF86Config-4. Je consultai pour cela le manpage et je me rendis compte avec étonnement qu'il allait me falloir créer une nouvelle section qui se présente comme suit.
Section "ServerFlags"
Option "StandbyTime" "15"
Option "SuspendTime" "17"
Option "OffTime" "20"
EndSection
Je modifiai également mon fichier ~/.Xresources afin d'y intégrer la ligne *visualBell: True, ce qui évite d'entendre des beeps provenant du damné haut-parleur interne du PC qui devrait à mon avis disparaître des machines modernes! Les cartes sons, devenues presque un standard, parfois même intégrées à la carte mère, effectuent un travail infiniment meilleur. Reste malheureusement à établir une interface standard...
Décidément, je devrais faire l'achat d'une coûteuse imprimante PostScript, installer VMWare pour utiliser Windows et Linux simultanément (avec perte de performance sur l'un d'eux), avoir deux PC (une machine Windows et une machine Linux côte à côte) ou opter pour la simplicité et renoncer à Linux! Pour des raisons aussi personnelles que pratiques, aucune de ces solutions radicales ne m'intéressaient et pourtant, les bogues d'imprimante persistaient toujours!
Cette fois-ci, lors de l'impression, le contenu se trouvait décalé vers le bas de la page et le bas était tout simplement perdu! Le bogue se produisait autant avec des document LaTeX convertis par la commande dvips que de simples fichiers textes traités par a2ps. Seul Acrobat Reader pouvait, pour des raisons inconnues, imprimer les PDF correctement. Vendredi, le 13 avril 2002, je me rendis compte que pour le cours de Technologie de l'Internet (IFT3220), les énoncés de devoir se trouvaient en format HTML et non en PDF. Pour imprimer l'énoncé avec Mozilla, il me fallut imprimer dans un PostScript, convertir en PDF avec ps2pdf puis imprimer le PDF avec Adobe Acrobat Reader. Cela fait plutôt beaucoup d'acrobaties pour imprimer un simple fichier!
Le lendemain soir, l'opération échoua pour l'impression du plan de cours de IFT3220. Sur papier, le texte se trouvait minuscule, si bien qu'il me fallut utiliser une stratégie plus complexe consistant à convertir la page Web en LaTeX en utilisant html2latex. Le fichier dut être modifié de fond en comble afin de devenir imprimable.
L'application commerciale nommée TurboPrint n'accomplissait plus son travail adéquatement, je n'en voulais donc plus! Je me décidai à la supprimer par rpm -e turboprint puis réinstallai CUPS, souhaitant savoir de quoi il retournait avec ce système. J'installai non pas seulement cups et cups-drivers du premier CD de RedHat mais aussi gimp-print-cups du second disque et qtcups et qtcups-devel du troisième.
Maintenant, comment savoir faire fonctionner CUPS? Une astucieuse commande allait vite m'y aider: rpm -ql cups | grep bin. Je découvris ainsi lpq.cups, lpr.cups et lprm.cups, mais aussi cupsconfig. Je démarrai donc la commande et obtins l'affichage d'un navigateur avec un message d'erreur: la page demandée était introuvable!
Je dus démarrer le service CUPS par l'entremise de la commande /etc/rc.d/init.d/cups start puis un nouvel essai me révéla la page. Mieux encore, il suffit de pointer tout navigateur Web sur http://localhost:631 pour pouvoir configurer CUPS! Je pus ajouter avec grande aisance, après avoir à tout hasard entré root et le mot de passe approprié pour mon système lorsqu'il me fut demandé de m'authentifier, ajouter mon imprimante Canon BJC-250. Bien entendu, je m'étais rendu compte, avant de passer mon mot de passe root, que je me trouvais sur un site hébergé localement. Le système aurait bien pu me rediriger à un endroit sur le Web et fournir mon mot de passe root était bien entendu inadmissible en un tel cas!
Un test me révéla que l'imprimante fonctionnait, et elle ne décalait plus le contenu des pages. CUPS a ainsi résolu mon problème d'impression! Il restait par la suite à utiliser /sbin/chkconfig --add cups puis /sbin/chkconfig --del cups pour que CUPS démarre au lieu de LPRng lors du démarrage système. Je raffinai le réglage en conservant l'ordre des services. Pour ce faire, je renommai toutes les instances, dans /etc/rc.d/rc[0-6].d, de S99cups en S60cups et K00cups en K60cups.
Quelques temps plus tard, je me rendis compte que l'imprimante produisait du texte très pâle, souvent difficile à lire. Il me fallut beaucoup de temps et beaucoup de feuilles pour enfin découvrir que régler la densité à 2.0 plutôt que 1.0 permet de résoudre le problème.
Mardi, le 15 octobre 2002, je constatai qu'une nouvelle version des pilotes de mon modem était disponible sur le site d'Intel. Je me rendis compte qu'elle supportait le kernel 2.2.18, j'allais donc l'installer et enfin avoir un pilote de modem réellement fonctionnel!
La compilation se passa sans histoires, l'installation aussi se passa bien. Un petit bogue écarté.
Non, cette fois-ci, ce n'est pas ma Canon, c'est l'Epson Stylus Color 660 branchée à l'ordinateur familial. Je manquais d'encre noire dans ma Canon mais souhaitais imprimer une version modifiée par mes propres soins des notes de cours de processus cognitifs 1 (PSY1065) afin de pouvoir faire mon étude dans des conditions optimales. Toutefois, pour parvenir à imprimer les PDF, il fallait interfacer CUPS avec une imprimante Windows, à savoir l'Epson!
Ma première tentative d'ajouter l'imprimante distante fut un échec, car CUPS ne supporte pas bien ce type de traitement. Il semblait nécessaire de disposer d'une HP commerciale implantant le protocole AppSocket ou d'un puissant serveur Windows équipé de Internet Information Service (IIS) bien configuré pour gérer l'imprimante à travers Internet Printing Protocol (IPP).
Je renonçai pour le moment à configurer l'imprimante, mais jeudi, le 17 octobre 2002, le problème refaisait surface: il fallait imprimer! Je tentai pour la seconde fois d'effectuer des recherches sur le Web et je trouvai, sur le site BSDToday, un article indiquant que CUPS pouvait gérer des imprimantes Windows par le biais de SAMBA. Je consultai donc la documentation de CUPS et découvris comment la configurer avec Samba. Je tapai tout d'abord la commande qu'ils prescrivaient, soit ln -s `which smbspool` /usr/lib/cups/backend/smb, bien entendu après avoir vérifié si smbspool était bien installé.
Je passai ensuite par l'interface Web afin d'ajouter l'imprimante Epson. J'utilisai comme URI smb://buist/Epson. Toutefois, l'interface n'accepta pas le nom de méthode smb. Je dus donc créer une imprimante temporaire avec une URI fictive, à savoir file:///tmp/test.prn. En cas d'échec de la tentative, je pourrais toujours garder cette URI et utiliser la commande print de smbclient afin de réaliser l'impression manuellement.
Je modifiai ensuite le fichier /etc/cups/printers.conf. Ce fichier identifie toutes les imprimantes configurées et un fichier PPD se trouve dans un sous-répertoire pour compléter le tout. Seul le fichier printers.conf semblait nécessiter des changements, j'y modifiai l'URI puis redémarrai CUPS.
Dès lors, je pouvais taper lpr.cups -PEpson fichier et le fichier était pris en main par CUPS. Toutefois, aucune feuille ne sortait de l'imprimante distante. En consultant l'état de l'imprimante, je me rendis compte que CUPS tentait en vain de se connecter avec SAMBA.
Je tentai de modifier l'URI pour smb://192.168.0.1/Epson, puisque 192.168.0.1 constitue l'IP de la machine Buist, sans effet. Bien entendu, lors de chaque changement, il fallait redémarrer CUPS avec /etc/rc.d/init.d/cups restart. Je commençais à croire que SAMBA était resté en arrière et effectuait certaines connexions avec le protocole NetBEUI plutôt que TCP. Windows XP ne supporte plus, par défaut, le protocole NetBEUI et pour obtenir son support, il faut l'installer à part. Je ne voulais pas encombrer le système pour un système récalcitrant et des impressions plutôt occasionnelles.
Je découvris que le répertoire /etc/samba comprenait un fichier lmhosts. J'y ajoutai 192.168.0.1 buist afin d'établir la correspondance aux yeux de SAMBA. Une autre tentative n'amena aucun résultat. Je tentai avec smb://buist/Epson puis avec smb://BUIST/Epson. BUIST constitue le nom donné par la commande smbclient -L buist.
Je modifiai une nouvelle fois l'URI pour smb://BUIST GROUP/BUIST/Epson, mais cela n'améliora aucunement mon sort! Cette imprimante semblait définitivement condamnée à en pas fonctionner depuis mon Linux. Puis je tentai avec smb://eric:pwd@BUIST GROUP/BUIST/Epson et j'obtins plus de succès!
eric constitue un nom d'utilisateur valide sur la machine Buist Windows XP. pwd représente le mot de passe associé que je ne révélerai pas ici pour des raisons évidentes. Ainsi, je peux imprimer, mais en cas de problèmes d'impression, il me faut pour le moment me brancher sur la machine Buist et supprimer manuellement la tâche d'impression de la file d'attente; pas moyen de le faire à distance.
Tout cela ne donne pas une très bonne vision de Linux et j'en conviens. Ce n'est toutefois qu'une partie du système. La configuration relève parfois des tours de passe-passe, mais lorsque le système est au point, Linux constitue un système stable et capable de rassasier les informaticiens les plus curieux.