Compilez votre propre noyau Linux

Kernel LogoCompiler votre propre noyau Linux est la première étape dans l’optimisation des performance de votre système. En le créant avec exactement ce dont vous avez besoin, vous diminuer votre temps de démarrage et votre utilisation mémoire. Ce sera également un bon moyen de prendre en charge des périphériques que le noyau de votre distribution ne gère pas encore. Néanmoins, il vous faudra une connaissance approfondie des capacités de votre ordinateur et des périphériques qu’il contiens. Comme exemple, je prendrais la famille de carte mère Intel DH67 avec un système Debian Squeeze de base correctement installé. Cette famille de carte utilise le nouveau chipset Sandy Bridge pour lequel la partie Ethernet n’est pris en charge que depuis la version 2.6.38 du noyau et la partie graphique la version 3.0.0. Pour pouvoir installer cette Debian Squeeze je fus donc forcé d’ajouter une carte réseau provisoire sur le seul port PCI de la carte (une carte de la famille RTL8139). Veuillez remarquer que certaine version de carte mère de cette famille ont un pont PCI-Express vers PCI non supportés (comme sur la DH67GD-B3, alors qu’il fonctionne sur une DH67BL-B3), vous pourriez donc avoir besoins d’une carte PCI-Express si vous êtes dans ce cas. Une autre possibilité pour installer le système de base et le nécessaire pour compiler votre propre noyau est de mettre votre disque dur dans un autre ordinateur avec des périphérique plus ancien et bien pris en charge. Notez que si vous procédez avec ce tutoriel sans modification vous devrez être super-utilisateur (root) en quasi-permanence. Par conséquent je recommande de vous logger en root maintenant soit avec « su » soit avec « sudo /bin/bash ». Tout ceci est complètement fonctionnel sur les distributions basés sur Debian (incluant Ubuntu).

Les seuls paquets que vous devrez installer sur un système Debian pour compiler un nouveau noyau sont build-essential et libncurses5-dev :

build-essential est un méta-paquet qui installera gcc, g++ (inutile pour le noyau), libc6-dev et make. libncurses5-dev vous permettra d’utiliser l’interface ncurses pour configurer vos options de compilation (optionel mais chaudement recommandé). Vous remarquerez que contrairement à la plupart des paquets source sous les systèmes Linux, autoconf, automake et libtool ne sont pas nécessaire pour le noyau. Si vous n’utilisez pas une Debian ils vous faudra l’outil GNU Make, le compilateur C GNU et les en-têtes de la GNU libc6 et de la bibliothèque NCurses. LA compilation peut fonctionner avec des outils non GNU mais ce sera plus risqué et requièrera une procédure différente de celle donné ici. Néanmoins, les outils BSD sont connu pour bien fonctionner. A présent il faut télécharger le code source du noyaux Linux. Le mieux est de télécharger la dernière version, à moins que vous ne soyez un paranoïaque de la stabilité et / ou de la sécurité. Si c’est votre cas, vous pourrez choisir un noyau à quatre nombres. Je m’explique : les nouvelles versions sont numérotés x.y.z alors que les révisions de sécurité ont un nombre supplémentaire x.y.z.r. Remarquez qu’il n’y a pas de gros changement dans les séries 3.0.0 du noyau. Le changement de version majeur a seulement été adopté pour fêter le 20ème anniversaire de Linux. C’est donc pour les packageurs une série 2.6. Vous trouverez les archives du code source du noyau ici : http://www.kernel.org ou sur des miroir (la liste des miroir est disponible ici : http://mirrors.kernel.org/). Pour la carte mère de mon exemple je recommande la version 3.0.4 du noyau. Les commandes seront donc :

Maintenant expliquons ceci. Nous allons dans le répertoire /usr/src ou de nombreux module externe du noyau s’attendent à trouver le code source (par ex. les pilotes propriétaire NVidia). Nous téléchargeons ensuite l’archive du code source du noyau et l’extrayons. La dernière ligne est un lien de compatibilité vers la version du noyau que nous utiliserons (ceci suppose que ce sera notre version par défaut du noyau) pour permettre la compilation de modules externes (certains paquet peuvent également avoir besoin d’accéder au code source du noyau pour se compiler). Si vous n’envisagez pas de compiler autre chose vous pouvez placer en toute sécurité les sources de votre noyau dans un répertoire personnel et ne pas être en super-utilisateur (sautez les deux premières lignes).&

Nous allons maintenant aborder le moment délicat… vous allez devoir configurer votre noyau en fonction de ce que vous avez besoin. Il existe des moyens pour obtenir des informations sur votre système : des commandes comme lspci et lsmod vous donnerons respectivement les noms des périphériques de la cartes mère et lsmod la liste des modules que le noyau actuel utilise (mais vous pourriez avoir besoin de plus). Le plus utile est lsmod mais il ne vous aidera pas si votre noyau actuel ne prend pas en charge une partie du matériel ou si une partie de ce matériel n’est pas géré par des modules. Pour cette seconde raison, je recommande de commencer ainsi :

La ligne « make mrproper » nettoiera en profondeur l’arborescence du code source et toute configuration prédéfinie. Si vous voulez conserver une ancienne configuration pour recompiler le noyau, remplacez seulement mrproper par clean. La ligne cp nous permet de récupérer la configuration réelle du noyau en cour d’utilisation. Ceci est une bonne idée pour permettre de récupérer des options de configurations spécifique à votre distribution. Toutes les lignes se terminant avec hard-infos.txt servent à créer un fichier contenant toutes les informations utiles dont vous pourriez avoir besoin sur votre matériel. Dernier point mais non des moindres la ligne make menuconfig vous montrera le menu de configuration du noyau après un court moment de compilation.

À présent pas de secret, prenez votre temps et visitez tout les menus. Vous aurez besoin d’environ deux heures de torture cérébrale (et d’un niveau correct d’anglais) pour configurer ça correctement et en profondeur. Si vous ne comprenez pas une option de configuration essayez le bouton « Help » ou faite une recherche avec votre moteur de recherche préféré. Si vous ne comprenez toujours pas, laissez la valeur présélectionné. Voici quelques conseils :

  • Dans « Processor type and feature » choisissez le processeur le plus proche de celui que vous avez. En fonction de votre architecture 64 bits ou 32 bits (ou une architecture non Intel) la liste changera en fonction de ce qu’il est possible pour vous (mais pas forcement fonctionnel). En cas de doute, choisissez l’option commençant par « Generic ».
  • Pour de meilleurs performances c’est une bonne chose de basculer tout les modules des périphérique dont vous avez besoin dans leur version intégré. Ceci dit vous perdrez en flexibilité de telle sorte que le noyau que vous obtiendrez sera spécifique à votre carte mère et aux périphériques qui lui sont associés . Si vous changez de matériel, il vous faudra un noyau générique (par ex. celui de votre distribution). [ ] signifie non compilé (désactivé), [M] compilé sous forme de module et [*] compilé comme intégré dans le noyau central (généralement appelé vmlinuz- dans le répertoire /boot. Quelque fois vous aurez <>, ou < *> au lieu de [ ], [M] ou [*] : cela signifie que cette option permettra l’accès à d’autres options soit dans un autre menu soit dans un sous-menu de cette option. Attention, n’essayez jamais de tout mettre en intégré, le noyau serait trop gros et serait incapable de démarrer. Quelque fois vous n’arriverez pas à faire passer des modules en intégré. Ceci s’explique par des problème de dépendances : vous ne pouvez pas intégrer des modules qui dépendent d’un autre module. Il vous faudra d’abord faire passer le module parent en intégré. C’est pourquoi je recommande deux passe pour faire cette configuration.
  • Pour savoir quel périphérique vous devrez activer dans le noyau le fichier hard-info.txt vous fournira une bonne aide. La partie lsmod vous donnera le nom des modules. Dans la configuration le bouton « Help » vous donnera des information sur l’option. Vous trouverez à la fin de la description une ligne commençant par ceci : « Symbol: ». Ce qui suit est soit le nom du module soit une partie du nom (il peu y avoir un préfixe commun dans certains sous-menus).
  • Je pense que c’est une bonne idée de laisser la partie USB inchangé. De cette façon tout les périphérique USB que vous pourriez brancher seront reconnu correctement et le module correspondant chargé à la volée.
  • Même si vous n’avez pas de périphériques SCSI, n’essayez pas de désactiver le sous-système SCSI car toutes les technologies de disque dur (ou lecteur CD-ROM) utilisent une émulation SCSI depuis les séries 2.6 du noyau. Autrement vous ne pourriez pas démarrer.
  • La partie « network feature » est de loin la plus complexe. Il est sure de faire passer les modules dans leurs versions intégrés mais je ne recommande pas de faire le moindre changement a moins que vous sachiez exactement ce que vous faites.
  • Si vous projetez de compiler un noyaux pour un serveur dans une zone critique en terme de sécurité ou de stabilité, vous devriez désactiver toutes fonctionnalités expérimentale. Néanmoins,certains périphériques récent pourrait être inutilisable.
  • Si vous avez la chance d’avoir une carte mère de la famille Intel DH67 vous pouvez directement télécharger mon fichier .config (75 KB) et sauter la configuration… Si vous êtes vraiment feignant vous pouvez même télécharger un version précompilé (30.2 MB). Décompressez seulement le fichier depuis votre répertoire racine et sautez le prochain paragraphe. Attention : ces deux fichiers sont pour des cartes mères de la série Intel DH67 SEULEMENT et sans matériel additionnel à l’exception d’éventuels périphériques USB. Cela ne fonctionnera pas sur tout autre carte mère.

Quand la configuration est effectué, vous pouvez lancer la compilation. Tapez simplement la commande « make » pour commencer. Ceci prendra un certain temps donc vous pourrez prendre une pause bien mérité. Si la compilation échoue (dans quelques rare cas) cela signifie que quelque chose ne va pas avec votre configuration. Une fois la compilation effectué sans erreur, il vous faudra installer le fraîchement compilé noyau correctement de la manière suivante (je suppose que vous êtes super-utilisateur et dans le répertoire source de votre noyau) :

La première ligne installera les modules dans une zone prédéfinie et correcte de la hiérarchie de fichier (ie. /lib/modules/). La seconde ligne installera le noyau lui-même mais peut changer si vous n’avez pas une architecture Intel ou AMD 64 bits. Dans ce cas, vous devrez remplacer x86_64 avec le bon répertoire correspondant à votre architecture. Les lignes suivantes copies les fichiers nécessaire au chargeur de démarrage et au noyau pour démarrer correctement. Notez que si vous avez fait une configuration correcte sans modules (excepté l’USB) la commande mkinitramfs ne sera pas nécessaire (sauf si vous avez un clavier USB). mkinitramfs crée une l’image d’un disque RAM monté par le noyau lui permettant de trouver les modules nécessaire au démarrage avant que le système de fichier racine ne soit monté.

Maintenant il ne reste plus qu’a rendre le nouveau noyau bootable. Malheureusement, la procédure et/ou les fichiers de configuration peuvent être très différents en fonction de votre distribution. Si votre distribution est basé sur Debian c’est toutefois très simple. Lancez juste :

Cette commande générera un nouveau jeu de fichiers de configuration pour Grub et réinstallera le chargeur de démarrage. Le noyau par défaut sera le plus récent (par date de modification) du répertoire /boot. Des entrée de menu seront en principe généré pour tout autre système d’exploitation installé. Même si votre noyau est complètement fonctionnel, je recommande de conserver un noyau générique provenant de votre distribution en cas de problème ou de modification de votre matériel.

Si malgré l’avertissement précédant vous avez choisi de désinstaller le noyau de votre distribution, ou si vous avez besoin d’en-tête du noyau à jour vous devriez installer les en-tête de vôtre noyau Linux de manière à pouvoir compiler d’autre choses (la plupart des paquets source en auront besoin). Soyez certain d’avoir désinstallé toutes versions précédente des en-têtes du noyau avant de continuer avec les instructions qui vont suivre. Sur Debian:

Soyez attentif au fait que la fin du nom du paquet peut changer (2.6) en fonction de la version de Debian que vous utilisez : celle-ci est pour la Squeeze seulement. Veuillez le modifier en conséquences. Pour installer les en-têtes du noyau correctement vous devez saisir les lignes suivante dans une console :

La première ligne ferra un recensement des fichiers à installer et préparera un script pour la future installation. La seconde ligne installera les fichiers nécessaire dans le sous-répertoire « dest ». La ligne « find » effacera certains fichiers inutiles et la ligne « cp » les copiera à l’endroit attendu par les paquet sources habituel.

RMLL 2011 à Strasbourg

Rencontres Mondiales du Logiciel Libre 9 au 14 juillet 2011 Strasbourg Comme l’année dernière je suis allé au RMLL et je suis revenu avec quelques histoires à partager avec la communauté. Je ne vais pas répéter ce que j’ai déjà dit l’année dernière à propos de KDE car ceci est toujours applicable. Néanmoins, la situation avec les environnements de bureau est maintenant très différente de celle de l’année dernière. La disponibilité de Gnome 3 et du nouvel environnement de bureau par défaut d’Ubuntu, Unity, change la vision qu’on les gens de KDE. Ceci entraîne une redistribution des cartes pour les utilisateurs. Un fait indéniable est le très mauvais accueil de Unity de la part des utilisateurs traditionnels de logiciels libres. Cela se traduit par une perte d’intérêt criante d’Ubuntu pour beaucoup d’entre eux et donc la recherche de nouvelles solutions. D’autre part, la réception de Gnome 3 est inégale. Si certains utilisateurs traditionnels de Gnome apprécient toujours le nouveau look et la nouvelle approche, certains autres ne l’aiment pas vraiment. Bien d’autres encore pensent que le nouveau bureau n’est pas fini, comparant parfois avec l’état inachevé qui était attribué à KDE 4.0 quand il est sorti il y a maintenant quelques années. Mais il y a aussi quelques utilisateurs de KDE (il faut avouer qu’ils sont peu nombreux) séduient par le nouveau (et quelque peu inhabituel) look and feel de Gnome 3.

À propos de KDE directement, les utilisateurs sont généralement plus satisfaits par l’environnement et la qualité de la compilation de logiciels qu’ils ne l’étaient l’année dernière, et nous avons eu assez peu de remarques négatives (sauf évidemment celles peux constructives de ceux qui ne l’utilise pas…) . Les plus négatives qui viennent encore et fréquemment, concernent l’utilisation de nouvelles fonctionnalités. Permettez-moi de développer ce point …

Je vais prendre un exemple : les « Activités ». Cette fonctionnalité est très puissante, mais une question récurrente était : « C’est quoi ? Pourquoi devrais-je l’utiliser ? ». Une fois que je fait la démonstration, ils ont rapidement compris combien cette nouvelle fonctionnalité est pratique. Mais ceci montre un vrai problème de communication : les utilisateurs ne savent pas comment utiliser une nouvelle fonction ou pire ne comprenne pas de quoi il s’agit (quand ils savent que ça existe) ! Lorsque je demandais comment résoudre ce problème, la réponse était claire : chaque fois qu’une mise à jour de l’environnement KDE est faite (en particulier KDE-base), nous devrions afficher une fenêtre « Quoi de neuf ? » avec (et ceci semblait important) des liens vers la vidéo de démonstration. Ceci pourrait être généralisé pour chaque logiciel important.

Une préoccupation plus technique est la possibilité de nettoyer les fichiers de configuration de KDE des entrées ou clés obsolètes, évitant ainsi la nécessité d’effacer le répertoire .kde de l’utilisateur de temps en temps (environ tous les deux ans ou un an avec des systèmes mis à jour fréquemment).

Le dernier (mais non des moindres) point concerne la communication de KDE en France. En parlant avec certains contributeurs français de KDE (ou des contributeurs d’autre projets qui aime KDE), le problème de mauvaise représentation de KDE en France est très important. Nous avons besoin de plus d’événements KDE donc plus de personne pour travailler sur la communication (et pas besoin de compétences techniques donc tout fan de KDE peut le faire). Le nouvel évènement Akademy-fr calqué sur le concept espagnol Akademy-es est un bon début mais nous avons besoin de perpétuer l’événement et ce n’est pas encore gagné !

De retours des RMLL 2010

Rencontres Mondiales du Logiciel Libre 6 au 11 juillet 2010Il y a un mois environ, j’étais à l’édition 2010 des RMLL se déroulant à Bordeaux. J’étais l’un des types qui représentait KDE dans le village associatif. Ce billet vous racontera ce qu’il c’est passé et mes impressions. Les RMLL sont le plus grand rassemblement concernant le logiciel libre en dehors de Paris. Pour cet évènement, KDE était représenté pour la première fois. Tout ceci s’est tenu du 6 au 9 juillet 2010 à l’université de Bordeaux à Talence et les 10 et 11 juillet sur les quais de la Garonne au centre ville de Bordeaux (près du skate park pour ceux qui connaissent).

Personne présente

Malheureusement, l’aKademy 2010 se déroulant à Tampere, en Finlande avait lieu au même moment, ce qui ne nous à pas permit d’avoir de développeurs pour les RMLL. En fait nous n’étions que des traducteurs de KDE et des passionnés. Le staff était donc :

Staff du stand KDE des RMLL

Nom Présent du Au Rôle au sein de KDE
Geoffray Levasseur Lundi 5 Juillet Dimanche 11 Juillet Traduction, beta-test et rapport de bogue
Hélène Dervillez Lundi 5 Juillet Jeudi 8 Juillet Utilisateur
Ludovic Grossard Mercredi 7 Juillet Vendredi 9 Juillet Coordinateur de traduction des documentations
Philippe Nenert Lundi 5 Juillet Jeudi 8 Juillet Utilisateur

Je souhaite remercier Jimmy Pierre et l’ensemble de personnes du stand OpenSuse qui m’ont beaucoup aidé le weekend aux moments ou j’avais besoin de quitter le stand.

Ce que les gents qui n’utilisent pas KDE pensent

Il y a trois types de personne qui n’utilise pas KDE. Ceux qui n’utilisent toujours pas de système libre, utilisant principalement Windows ou Mac-OS, ceux utilisant un autre environnement de bureau et ceux qui utilisaient autrefois KDE et qui ont changés pour un autre environnement de bureau.

Les personnes qui n’ont jamais utilisé Linux ou BSD sont toujours très impressionnées par la qualité de l’environnement et surpris par le nombre d’applications disponibles, particulièrement les utilisateurs de Windows. La plupart ne connaissaient rien à propos de KDE mais étaient intéressé par les logiciels libres. Le multi-bureaux, les plasmoïdes et les effets graphiques en 3D sont considérés bien plus impressionnant que ceux qu’ils peuvent voir dans Windows, cassant quelques mythes, du genre « Linux c’est moche »… Donc, pas mal de bons points mais le mythe « Linux c’est compliqué » est plus difficile à dissiper. Pour la démonstration des logiciels, ils sont d’accord pour reconnaitre la facilité et la puissance globale des applications mais des questions comme « je pourrais installer le logiciel XXX que j’aime » et que je réponds que non mais que l’application YYY existe et fait la même chose (le plus souvent en mieux d’ailleurs) ils sont alors effrayés du changement. Le plus souvent ils sont d’accord pour essayer (ils seraient pas la sinon) car les avantages sont visible, principalement financier, l’argument philosophique étant considéré comme un bonus. Les propositions de live CD ont eu plus de succès que celle du dual-boot même si tout le monde le voit comme une bonne idée.

Les personnes utilisant déjà Linux et/ou BSD connaissent bien mieux KDE. Il y a cependant une exception : les utilisateurs récemment convertis. Voila mon coup de gueule : j’ai un problème avec certains LUGs qui ne demande pas son avis à l’utilisateur et leur installe toujours une p****n d’Ubuntu de m****e pendant les installe-party ! C’est pourquoi beaucoup de nouveaux utilisateurs de Linux ne connaissent rien à propos des autres distributions Linux et rien à propos de KDE (ou de n’importe quel autre environnement de bureau). Ils font, ainsi, la même erreur que les vendeurs d’ordinateurs qui de la même façon ne donne pas le choix en imposant un système d’exploitation bien trop connu. Néanmoins, ces personnes sont souvent satisfaites par l’environnement de KDE pendant les démonstrations et beaucoup disent qu’ils essayeront en installant les paquets nécessaires ou même en essayant une autre distribution (OK, j’admet que mon effort de promotion était très orienté OpenSuse ou Mandriva, plutôt que Kubuntu mais pour une bonne raison : de bien meilleures intégrations de KDE). L’utilisateur expérimenté connais toujours KDE, l’a essayé, et fait son choix en fonctions de ses gout et priorité. Ce type d’utilisateur est toujours d’accord pour reconnaître la qualité de certaines de nos applications notamment K3b (presque toujours en fait), Amarok, digiKam et la suite PIM.

Les cas les plus délicats sont les personnes qui utilisait KDE 3.5 et ont cessé de l’utiliser après la sortie de KDE 4. La plupart d’entre eux ont essayé KDE 4.0 or 4.1 et furent énormément déçu par le nouveau bureau considéré à l’époque lourd et très instable et plus encore que cela, ils n’ont pas accepté la perte de certaines fonctionnalité et / ou applications. La plupart du temps ils regrettent leur ancien bureau et ne sont pas pleinement satisfait de leur environnement de bureau actuel (Gnome le plus souvent) car en attente de quelque chose de proche de KDE 3.5. En réalité, il y a un cruel manque de communication de notre part car beaucoup d’idée fausse courrent : Konqueror ne peut plus être l’outil universel car ce n’est plus le gestionnaire de fichier, je ne veux pas ou je n’ai pas besoin des effet 3D, je n’aime pas le nouveau menu/bureau, ou sont les icônes du bureau…. J’ai entendu tout ceci régulièrement. Pourquoi ne pas créer un thème KDE 3.5 qui ravira ces personnes ? C’est simple: faire de Konqueror le gestionnaire de fichier par défaut, désactiver les effets 3D, placer l’ancien menu comme menu par défaut et activer le modèle en icônes de bureau de Plasma. Je fus capable de monter un tel bureau et tous ceux qui se plaignaient de KDE 4 ont adorés. Je leur ai conseillé de choisir quelque chose comme Mandriva pour laquel les paramètres par défaut font beaucoup penser à KDE 3.5. Á propos de la perte de fonctionnalité et des problèmes de stabilité et de performances j’ai pu leur faire remarquer que ces problèmes étaient en grande partie réglés.

Utilisateurs de KDE

Inutile de précher un convaincu… Curieux de savoir ce que ces convaincus aiment ou pas, quel sont leurs applications favorites ou détestées, j’ai posé beaucoup de questions. Les résultats étaient très cohérent. Ce qu’ils aiment du bureau est la cohérence globale entre les applications KDE et le bureau, les jolies choses efficaces qu’il peuvent avoir avec Plasma et KWin (je met ça dans la même catégorie que l’opportunité d’épater les copains qui sont encore sous Windows ;)) et la très bonne qualité des applications. En parlant des applications, les plus plébicités sont K3b (je fus impressionné par sa popularité même avec des utilisateurs non-KDE), Amarok, digiKam, Gwenview et la suite PIM (praincipalement KMail).

Ce qu’ils n’aiment pas c’est la lourdeur du bureau et le manque de stabilité de KWin et Plasma (trop de crash que je n’ai pu démentir en ayant subi moi-même) [ndlr : corrigé avec KDE 4.6] , un suivit de dévellopement des Plasmoïdes trop alléatoire (principallement des exotiques disponible dans OpenSuse ou Mandriva issus de Playground). Concernant les applications qui ont besoin d’amour (et oui, je lis parfois les interviews des développeurs), la plus cité est Kopete (surtout la prise en charge audio/vidéo) et Dolphin et Konqueror (surtout leur stabilité, et la gestion très aléatoire de Flash/AJAX dans Konqueror). Certains développeurs (qui ne font même pas de Qt) m’ont dit que KDevelop 4 avait une très mauvaise intégration des systèmes de controle de révision (CVS / Mercurial / Git). Une fonctionnalité qui manque cruellement aux adeptes de KDE 3.5, est la possibilité de se connecter en tant qu’administrateur grâce à un bouton dans certain modules de configuration du centre de contrôle. Enfin certains regrette la disparition de Quanta.

Ce que je fais ces derniers temps…

News iconJe sais que j’ai été absent pendant un moment, mais c’était pour de très bonnes raisons. Je travaille beaucoup sur de gros articles et projets, et vous en aurez les résultats très bientôt. Pour les plus impatients voici la feuille de route :

  • YaPeTaVi est actuellement dans une phase de transformation importante. Je travail sur de gros changements structurels du projet qui mèneront à de très bonnes améliorations. D’abord, la page de configuration des filtres va changer totalement. Le système actuel va disparaitre au profit d’un système de liste et de fiches contextuelles. En plus, beaucoup d’autres informations seront disponible telles que les énergie de seconde et troisième ionisation, une toute nouvelle liste des découvreur avec une courte biographie, des images avec descriptions pour chaque éléments (photo en bitmap et configuration électronique en SVG). Enfin mais non des moindre, une interface plus agréable, avec un nouveau système d’aide contextuelle. Bien plus est encore à venir.
  • La partie II de l’article « Construire KDE 4 depuis trunk » est en phase de préparation. Après des essais et beaucoup d’heure de compilations, j’ai changé ma première idée qui était d’envoyer un nouvelle article sur ce blog avec des informations mises à jour. Vu les immenses possibilités et mes bonnes expériences, je travail sur un gros et complet tutoriel alternatif à celui donné sur le site officiel techbase de KDE. Malheureusement, vu que je travail essentiellement sur une Debian, le tutoriel risque d’être un peut spécifique à Debian. C’est pourquoi, cette page sera mise à jour régulièrement en fonction de vos retours et conseils.
  • Enfin vous vous rappelez probablement de mon article à propos de la création d’un routeur avec une vielle machine et un Linux. Une mise à jour est à venir avec la prise en charge de l’uPnP (universal plug and play) qui est une méthode très pratique et sure de configurer votre routeur en fonction des applications que vous utilisez. Malheureusement, ceci prend du temps puisqu’il me faut faire beaucoup de recherches pour le faire correctement.

Voici donc un programme énorme et très intéressent, donc, à très bientôt…

Créer un routeur avec Linux

RouteurVeuillez remarquez que cet article est devenu obsolète. Les instructions suivantes devraient fonctionner sur de vieux systèmes, autrement veillez à ne pas les utiliser. Un tutoriel mis à jour et plus complet sera disponible entre le 25 et le 30 mars 2011.

Créer un routeur sous Linux en recyclant un bon vieil ordinateur est un très bon moyen de créer un sous réseau sécurisé. Malheureusement, les billets contenants des explications claires de la procédure ne sont pas aussi simple à comprendre qu’ils le devrais.

Pour ce faire vous avez besoin d’un ordinateur très simple. Personnellement j’utilise un P3 600 MHz avec 327 Mo de RAM et un disque dur de 20 Go. C’est bien plus que nécessaire pour cet usage, mais cette machine est aussi un serveur HTTP et FTP. Par exemple, mon précédant routeur était un Pentium 200 avec 48 Mo de RAM et un disque dur de 500 Mo, ce qui tournais très bien sous une Debian Etch. Concernant les interfaces réseaux, vous aurez besoin d’une carte Ethernet en plus de ce qui vous est nécessaire pour l’accès Internet, qui est probablement une autre carte ethernet. Vous aurez également besoin d’un hub ethernet connecté à cette carte réseau. Si vous avez besoin du sans fil, je recommande une troisième carte réseau Ethernet (donc un second sous-réseau), ou vous n’aurez qu’un point d’accès WiFi installé. Si vous ne pouvez (ou ne voulez pas) avoir une troisième carte réseau vous pouvez toujours connecter votre point d’accès au hub mais c’est mois sécurisé.

Toute les instruction qui suivent, supposeront qu’une Debian Lenny ou Etch est installé sur la machine de routage (ce qui est un assez bon choix) avec une connexion Internet fonctionnelle. Vous n’aurez qu’à installer le système de base. Il n’est pas recommandé d’installer X et des applications graphique car la sécurité est le principal but de ce type de routeurs.

Ceci fait, vous devez passer en compte root pour tout le reste de la procédure et installer les paquets suivants :

  • dhcp3-server qui attribuera automatiquement les adresses IP des clients de votre sous-réseaux
  • dhcp3-client est utile si votre modem vous fourni une adresse IP dynamique ou si ce modem est lui-même un routeur (généralement installé par défaut)
  • iptables qui est un pare-feu et fournit la traduction d’adresse (NAT) (généralement installé par défaut)
  • iptables-persistent qui conservera les paramètres d’iptables et le restaurera en cas de redémarrage du routeur
  • nano un éditeur de texte simple (généralement installé par défaut)
  • w3m (ou n’importe quel navigateur en mode texte) pour tester la connexion internet sur le routeur
  • Tout autre serveur public utile pour vous, comme Apache, proFTPd, BIND…

D’abords je doit définir quelques termes pour être précis. Imaginez le plan suivant :

  • eth0: connecté à votre modem (zone internet) avec l’adresse 192.168.0.1
  • eth1: connecté à votre réseau Ethernet privé avec l’adresse 192.168.1.1
  • eth2: connecté à votre point d’accès WiFi (zone optionnelle WiFi) avec l’adresse 192.168.2.1

Bien sur vous devrez remplacer ces valeurs par celles de votre configuration et avec les adresses réseaus de votre choix (doit commencer par 192.168). La zone internet est automatiquement configuré par dhcp-client situé dans le script d’initialisation du système mais ce n’est pas le cas des deux autres réseaux. A moins d’avoir donné les bonnes valeurs pendant l’installation, vous devez le configurer manuellement en éditant le fichier « /etc/network/interfaces »:

À présent il faut éditer le fichier « /etc/dhcp3/dhcpd.conf » pour activer le serveur DHCP (Dynamic Host Configuration Protocol) :

Maintenant, redémarrons le serveur DHCP :

/etc/init.d/dhcp3-server restart

Vous devriez tester le serveur DHCP en reconfigurant le réseau et en pingant le serveur depuis l’une des machines client. Par exemple avec Linux:

dhclient eth0
ping 192.168.1.1

Si dhclient vous donne une bonne adresse IP et que ping ne renvoi aucune erreur de transmission de paquet, votre serveur DHCP est bien configuré. Avec Windows, vous devez utiliser le « Panneau de configuration » pour configurer les paramètres du client. Si vous utiliser un point d’accès WiFi, vous devrez le configurer en conséquence avant de lancez ces test.

A ce point le réseau local fonctionne mais vous n’aurez pas encore d’accès à internet car l’interface eth0 doit « traduire » les adresses de eth0 pour eth1 et eth2. Ça s’appelle NAT (Network Address Translation) et cela ce fait avec iptables qui est en même temps notre pare-feu. Dans une console tapez les commandes suivantes :

A présent votre accès Internet fonctionnera avec un très bon niveau de protection. Néanmoins, si vous voulez régler votre configuration d’iptables, la prochaine étape sera d’acheter un bouquin dessus… That’s all folks !

Linux et PowerMac G3

Kernel LogoCe week-end on m’a demander d’installer Linux sur un vieux PowerMac G3 par un amis vivant dans une petite ville de l’Aveyron ou la connexion internet était dix fois plus lente qu’à Toulouse, ou je vis. Ce fut, à la fois, une expérience très intéressante et très agaçante…

Après le téléchargement d’une Debian Lenny édition PowerPC (2 heures pour le CD netinstall de 200Mo…), booter et installer le système de base (4 heures) fut aussi facile que sur une machine Intel, me donnant tout l’optimisme dont j’avais besoin. Mon premier problème vint avec Xorg. Quand j’essayais de le démarrer, un bogue dans le pilote ATI (seulement dans la version PowerPC) me fqit obtenir un écran noir. Ce bogue avait déjà été relevé dans le chasseur de bogue Debian dans les Lenny beta et n’était toujours pas corrigé pour la Lenny finale (avec les dépots update et volatile activé) ! J’ai essayé de mettre à jour Xorg avec la version Squeeze… Aucun succès, bogue identique :/. Puis la version Sid et oui ça fonctionna !

Après ça, la machine était rapide et stable et KDE 3.5.9 démarrai parfaitement. Pour compiler KompoZer, aucun problème (KompoZer n’était pas disponible au format binaire pour PowerPC). Installer et configurer un serveur local LAMP utilisé pour tester un site web en PHP fut facile. À ce moment tout était bon pour moi. Mais…

A présent quels étaient mes problèmes finaux ? Arf tellement !

  1. Les écrans Machintosh n’ont pas de boutons (saleté de design Apple…) pour arranger la géométrie d’affichage et je n’ai pas trouvé d’utilitaire Xorg pour le faire… Je fus forcé d’utiliser la résolution maximale (1600×1200 sur un écran de 15 pouces…) parce que toute autre résolution aboutissais à des zones non-visible de l’affichage. Et s’il vous plais ne me dite pas qu’on peut résoudre ce problème en modifiant le fichier xorg.conf… Je sais ! Mais je refuse de perdre des heures à régler le fichier xorg.conf à l’aveuglette, puis tester, régler et tester encore et encore jusqu’a ce que j’ai quelque chose d’acceptable ! C’est si facile à faire graphiquement (comme SAX le fait, l’utilitaire de configuration Xorg d’OpenSuse). Pourquoi Xorg ne fourni pas un utilitaire aussi utile et simple ? Ma seule solution fut de changer la taille des icones et des polices dans le centre de contrôle de KDE. Pas de réelle satisfaction du resultat… évidement !
  2. J’ai essayé d’installer des produits tout en un Brothers et Canon… A premier abord je fut content car les sites web internet respectifs fournissent des pilotes Linux packagé au format Deb :)… Arf, pas de binaire Linux PPC… Oh oui il y a le code source dans ce cas, et Brothers l’a placé sous GPL ! Cool. Et m***e… En effet, il y a du code source mais certaine partis sont précompilé et indisponible sous forme de code source, générant des érreurs lors de l’édition de liens. Heureusement, il y avais aussi une imprimante HP et un vieu scanneur Epson Perfection. Merci à HP pour donner des pilotes vraiment et complètement open source.
  3. Mon ami aime parfois regarder des vidéos sur internet (i.e. YouTube). Gnash est présent pour PPC mais totalement non-fonctionnel : le navigateur web se plante à chaque fois qu’un contenu en Flash est trouvé (que ce soit avec Konqueror ou Iceweasel). Et, bien sur, pas de paquet Linux-PPC pour le plug-in Adobe… Par conséquent, nous n’avions plus qu’à oublier l’idée de voir des vidéos en ligne… 🙁
  4. Le bouton d’éjection du lecteur CD-Rom se trouve sur le clavier (Argh pu***n de design Apple!!!)… Je n’ai trouvé aucun support pour cette fonction étendue des clavier Apple. Bon point: les touche F13 à F15 sont utilisable dans la configuration des raccourci de KDE.

J’ai passé 3 jours sur cette machine (OK connexion internet était très lente…) et c’est vraiment beaucoup trop. Le support du PowerPC n’est pas aussi bon que sur plate-forme Intel, et tout les constructeur et éditeurs de paquets binaire (imprimantes, scanneurs, flash…) oublient simplement totalement les utilisateurs de PowerPC (même pour MacOS, j’ai été forcé d’utiliser de vieilles versions de ces logiciels). Le seul point positif a été la rapidité de la machine. Pour une machine de 5 ans, j’ai été surpris par les performances (750 MHz et 512 Mo de RAM), bootant en moins d’une minute (incluant KDE). Compiler KompoZer (c’est plus gros que Firefox) ne m’a pris que 30 min. Si il y avait un bon support, Linux sur PowerPC pourrais être une excellente solution.