Don't Panic IT

Je suis quelqu’un qui débat. Je débat sur tout et n’importe quoi, parce qu’il m’importe de faire passer des idées. Au delà de tout débat politique que je pourrai tenir, dans d’autres lieux que ce blog consacré à l’informatique, je veux ici aborder une idée reçue :

“Linux, ça sert a rien! Rien ne tourne dessus et c’est compliqué à utiliser!”

Cette phrase, je l’entends maintes fois prononcés par des utilisateurs déçus, des néophytes écurés par la complexité apparente des systèmes linux, souvent due à l’idée véhiculé par les médias. Elle est aussi prononcé parfois par des ignorants, mais ceux là sont pardonné par leur inculture totale du sujet. Ceux là je les ignore et les méprises, car ils n’ont pas fait l’effort, et donc méritent tout, sauf mon respect.

Dont panic! Linux is simple!*

Contrairement à l’idée que les gens s’en font, GNU/Linux, et la distribution issue de Debian, Ubuntu, sont aujourd’hui tellement simple que même votre grand mère pourrait l’utiliser.

Mais il y a un hic, et c’est là que les gens gueulent, c’est la difficulté de faire démarrer des éléments prévus pour Windows sur leur système Linux.

On pourrait se réjouir de la présence de Wine, qui permet tant bien que mal de faire démarrer quelques jeux, comme World of Warcraft, LoL et d’autres, en contrepartie de quelques efforts de configuration, qui sont, tout de même, de plus en plus assistés (notamment grâce à Winetricks). Le site de WineHQ annonce quand même plus de 5350 jeux supportés dont Skyrim en qualité “Gold et Platinium”, ce qui implique une gestion assez magistrale des jeux récents.

Au delà des jeux, c’est près de 12000 applications Microsoft que Wine peut faire tourner, avec plus ou moins de réussite, certes, mais quand même, ce n’est pas rien.

Mais maintenant, il y a quelque chose de vrai. Pour faire tourner un jeu sur Linux, il faut donc installer Linux + Wine + Dépendances + Eléments de Wine nécessaire au bon fonctionnement de jeu.

Comparativement à Windows, ou l’on insère le DVD, ou on télécharge le jeu (légalement bien sur), on prie pour que ça ne plante pas, et on joue.

Mais est-ce réellement la faute des utilisateurs?

Microsoft a gangrené le marché pendant 30 ans.

Il y a quelque chose que j’aimerai clarifier ici et briser pour certains une idée reçue : Ce n’est pas parce qu’un programme tourne sous GNU/Linux, qu’il est forcement gratuit, ou libre, ou Open source, qu’il respecte obligatoirement la License GPL. Certains programmes tournent sous copyright (même si ça déplais à Stallman) et coûtes des ronds. Ubuntu accueil d’ailleurs depuis la 11.10 des applications payantes dans sa logithèque en ligne. le business est donc possible sur Linux! Peut être même plus, compte tenu de l’économie réalisé par les consommateurs en se tournant vers un système d’exploitation entièrement gratuit.

Partant du principe qu’il existe donc un monde obéissant aux lois du capital dans l’univers du libre, que coûterait aux développeurs de jeux vidéo, pour compiler, compacter et sortir leurs jeux sur Linux?

Peut être un peu de temps, un peu d’argent, mais quand même, on ne dois pas le re-coder entièrement à ce que je sache! Rallonger d’un mois la sortie d’un jeu pour qu’ils soit portable sur tout les systèmes, c’est pourtant pas bien compliqué. Notch l’a compris en sortant un jeu multi-plateforme. De plus les langages propriétaires comme le C# seraient les seuls affectés par un manque de portabilité, mais on s’en fiche, c’est du Java! Y’a qu’a le transposer et lâcher définitivement le C# qui reste quand même une erreur colossale!

En plus pour le peu de jeu qui ont fait le choix du C#, une infime partie du panel de jeux actuellement sur le marché ne serait pas affectés.

Un effort commun

Mon propos est le suivant : Microsoft Windows, avec la sortie de sa version 8, va devenir de plus en plus privative : Contrôle totale sur la machine, désinstallation à distances des outils piratés, la menace d’un contrôle total sera peut être permanente sur ces systèmes, et les gens vont peut-être, je l’espère, avoir l’intelligence de chercher une alternative. Cette volonté qui viendra, j’en suis sur, de la part d’utilisateur aguerris mais pas forcement forcenés (je pense à ceux qui sont capables en temps normal de pirater un Photoshop CS5 en appliquant des patchs sur leur fichiers hosts) qui chercherons des solutions d’échapper aux contrôles, que ce soit par liberté de piratage, ou par envie d’être libre, tout simplement.

Il est pour moi donc important que la communauté des développeurs de jeux vidéos se mettent en ordre de marche pour assurer la portabilité des produits sur les plateformes GNU/Linux.

Valve Corporation, par le biais de Steam, avait suscité l’espoir en annonçant la sortie hypothétique d’un client Steam Linux, ouvrant ainsi la voie aux studios de pouvoir faire profiter aux utilisateurs de ce système, une partie de la bibliothèque dans laquelle ont retrouve une grande quantité des jeux PC actuel.

Il faut à tout pris soutenir et encouragé des projets de ce type, par le biais de sondages, et de réclamation pour montrer que le marché est là, et qu’il attend. il faut pousser aussi les autres, comme Origin pour EAGames, et des studios comme Ubisoft ,à lancer eux aussi la même initiative, et les pousser à sortir leurs jeux sous Linux.

Oui, ce billet est plus ou moins un appel, un appel d’un développeur et d’un joueur, tournant sous GNU/Linux depuis maintenant 5 ans, et qui aimerai beaucoup se débarrasser de Windows 7 sur son PC fixe, qu’il est obligé de lancer tout les jours pour jouer sur Steam :p.

*Pas de panique, Linux, c’est Simple!

Bonjour à tous.

Aujourd’hui pas de tuto mais une petite info.

Si un jour vous installer un script depuis une machine Debian vers un Ubuntu, ou vers une autre version de Gnu/Linux ou une version plus ou moins récentes, vous pouvez, à l’execution, vous retrouver devant l’erreur “Bad Substitution”.

PAS DE PANIQUE

Cette erreur est très souvent lié aux version du shell que vous utilisez en entête de votre script.

Donc pensez à tenter de remplacer 

#!/bin/sh

Par d’autres variantes de votre Shell comme par exemple 

#!/bin/bash

Ou comme je l’ai vu sur un forum 

#!/usr/bin/ksh

J’ai fais ce post car le problème s’est posé à moi, et je n’ai trouvé que peu de réponses sur le sujet. C’est plus ou moins du bricolage, mais ça passe! Et c’est pratique quand on a un script complexe à débugger alors que l’erreur se passe là.

Sur ce bonne journée!

Bonjour à tous!

Petit billet plein de légèreté et de beauté aujourd’hui. Vous, brillants administrateurs systèmes qui tombez par hasard sur ce blog en quête de réponses improbables, n’avez jamais rêvé d’un peu de couleur et de folie pour vos environnement de développement?

Donc aujourd’hui je vais vous parler d’un petit logiciel sympatoch nommé gource.

Gource est un logiciel de visualisation de projet git/svn qui permet de voir les dossiers, les branches, les commits et les membres à partir des logs sur le projet en question. Niveau professionnel, l’intérêt est plus que limité, mais d’un point de vue visuel, qu’est ce que ça en jette ;D.

Voici par exemple ce que des petits malins ont générés à partir des dépôts git de php. On y voit les contributions et les évolutions au fur et à mesure, comme la naissance de php 4 puis 5.

Pour vous amuser à visualiser vos projets, voici donc la marche à suivre :

Etape 1 : Installer les dépendances et les librairies.

Ce logiciel fonctionne avec les librairies SDL compilées en C++ (j’ai d’ailleurs été bien surpris de voir à quel point ces librairies commençaient à devenir intéressantes, ne se contentant plus de faire du 2D SNES, je devrais plus me tenir au courant).

Pour ce faire donc, sur une machine debian (Ubuntu 11.10 dans mon cas) envoyer la commande suivante :

sudo apt-get install build-essential libsdl1.2-dev libsdl-image1.2-dev libftgl-dev libpcre3-dev libpng12-dev libjpeg62-dev

Etape 2 : Installer “Gource”.

Les versions de “gource” sont disponibles à la page suivante : http://code.google.com/p/gource/downloads/list

Etant codé en C++, ces derniers nous gratifient joyeusement d’une versions Win32 ce qui satisfera nos chers utilisateurs de Microsoft :).

Une fois les sources décompressées, il s’agis maintenant de les compiler afin d’obtenir un exécutable. Les commandes classiques suffisent :

cd /Repertoire_de_Gource
./configure
make
sudo make install

Si vous n’avez pas fait de connerie, normalement, si vous envoyez dans votre terminal :

gource -h

Vous devriez voir apparaître la liste d’aide (assez complète) pour gource et donc que votre installation sera un succès.

Etape 3 : Utiliser “Gource”.

Maintenant que gource est installé, il ne vous reste plus qu’a vous rendre dans votre dossier ou siège votre clone local de git (le dossier qui contient le .git in fact).

cd Dossier_du_Projet

Et à lancer la commande suivante, qui est la commande standard pour avoir un rendu vif et dynamique :

gource —seconds-per-day 80 —auto-skip-seconds 0.1 —file-idle-time 500 —max-files 500 —multi-sampling -1280x720 —stop-at-end —elasticity 0.1 -b 000000  —hide filenames,dirnames  —disable-progress —user-friction .2 —disable-bloom

Les arguments de commande sont suffisament clair pour faire ce que vous voulez. Par défaut la visualisation est en fenetré, mais vous pouvez le faire facilement passer en plein écran (et épater vos colègues) avec l’argument supplémentaire

“-f” ou “—fullscreen”.

Voila, grâce à Gource, vous allez pouvoir faire tomber les filles en soirée en montrant “Voila ce que c’est qu’être développeur!”.

C’est comme jouer de la guitare mais en mieux.

Etape bonus : compresser votre résultat en vidéo.

Si vous voulez faire baver le monde devant vos réalisations et pouvoir les héberger sur YoupornTube, il faut donc envoyer tout ça en enregistrement vidéo.

Pour ça je vous conseil de consulter la page ici présente : http://code.google.com/p/gource/wiki/Videos

Elle contient toutes les indications pour encoder proprement vos vidéos en mp4.

Je ne fais pas de tuto détaillé là dessus pour la simple et bonne raison que je me suis complètement vautré dans l’installation de codecs ffmpeg et qu j’ai flingué une partie des lectures vidéos sur mon linux, ce sont des choses qui arrivent u_u’…

Donc je vous souhaite bon courage et une bonne journée à tous!

Bonjour à tous.

Petit article aujourd’hui pour parler d’un souci, j’espère que ça servira d’avertissement pour certains qui tomberaient dans le même piège que moi.

Le ton est volontairement humoristique, car quand on a ce genre de couille, il vaut mieux en rire, ou du moins, essayer.

C’est assez relié avec les tutos sur les partages nfs déjà disponibles sur ce blog, donc pour ceux qui dormiraient au fond de la classe, prenez note.

Alors, comme vous avez pu le lire, j’ai récemment mis en place un système de partage assez simple mais néanmoins complexe (WTF?) au niveau de mon serveur de fichier et de mes systèmes là ou je travail en tant qu’administrateur système.

Alors comme ce matin j’ai vécu un véritable apocalypse et empêché une équipe de travaillé pendant 30 minutes, je préfère avertir les têtes brûlées qui voudrait un jour tenter de faire les mêmes conneries que moi. 

Ne faites pas comme moi, gardez toujours à l’esprit que quelque chose en développement, même si il parait très cool tout ça, N’EST PAS STABLE!

Quand j’ai formaté mon serveur à l’installation de Debian, j’ai pris la décision d’utiliser le BTRFS comme système de fichier. Pour ceux qui dormais ces 5 dernières années, le BTRFS est annoncé comme le successeur des systèmes journalisés comme la série des ext. Il est en développement depuis 2007 et considéré comme stable depuis mars 2009.
Oui mais… 

On peut se demande, pourquoi ce système si miraculeux, n’équipe donc pas toutes nos distributions linux actuelles? Lui qui annonces vers performance de +500% en compressé comparé à son camarade ext4, reste irrémédiablement dans l’ombre.

Le fait est que malgré tout le travail et les avancées faites sur son sujet, il n’en reste pas moins un système de fichier en développement, non complet et inapplicable à certaine situation.

Mon exemple est le suivant. Voici mon ancienne infrastructure, que vous connaissez bien, vous les deux ou trois qui suivez mon blog :

Comme vous le voyez, j’ai fais le choix du BTRFS et j’exporte en NFSv4 au cotés de la partition du Système linux, transportant la racine du système, sur une partition en XFS.

La première fois que j’ai tenté ce montage, j’ai été confronté à un problème assez étrange. En effet, la partition du NAS, en BTRFS, une fois monté en en NFS, provoquait un très très très gros ralentissement.
En temps normal, un hdparm -t sur la partition NAS donnait une vitesse de lecture variant entre 1 et 5 Mo/s, contrairement aux 110 Mo/s dont j’ai habitude.
Suspectant un problème inhérent au fait de dédoubler un lien nfs partant d’une même source et allant vers une même destination, je me suis donc décidé à essayer de ne tourner qu’avec une seule exportation, limitant dans le même coup les erreurs de démontages sur les postes clients, et j’ai donc donné vie au tutoriel d’hier (ou d’avant hier, je sais plus).

Bref, donc cette configuration fut modifiée et j’ai pu aboutir au bout de quelques recherches à l’ensemble suivant :

Hier soir je clos définitivement l’affaire, prépare à distance mes systèmes, et, prévoyant, met mon réveil plus tôt pour être premier au boulot, on sait jamais.

Ce matin, les 4 premiers postes démarrent sans encombre et je vais me fumer une cigarette, certes matinale mais néanmoins méritée pour célébrer ma victoire sur cette hérésie qu’est l’infrastructure de développement local standard des sociétés de développement web d’aujourd’hui.

En revenant de cette délicieuse cigarette, le 5e poste est allumé et… 

D’un coup, tout les systèmes commencent à ralentir.

Suspectant un ralentissement du réseau, je cherche d’abord dans ce sens, avant de me rendre compte que mes hdparm ne passent plus. Chaque consoles ouvertes avec lesquelles je lance un hdparm me lâchent, et me guide désespérément vers la triste réalité que me réserve le /var/log/syslog.

Pour la faire courte, toute la couche BTRFS avait sauté d’un coup à la suite de l’appel nfsv4 du 5e poste. Je me retrouve avec une énorme erreur kernel, révélée en fait par le hdparm.

Je me retrouve donc à devoir repasser sur notre vieux serveur de fichier, celui qui crash dès qu’une porte claque trop fort.

Ouaip, donc un conseil :

LE BTRFS EN NFSv4 POUR LE PARTAGE MASSIF, ON ÉVITE!

Et moi je reformate ma partition de serveur en ext4. Ça m’apprendra a faire des expériences.

Bonjour à tous!

Aaaahh, enfin un petit billet, ça faisait longtemps. En fait j’avais pas mal de boulot assez répétitif, et surtout pas intéressant en ce qui concerne le blog. Mais là, tout se clos petit à petit, donc du coups, il est temps de faire quelques tutos rapide de solutions simples et efficaces pour les problèmes que j’ai rencontré, car oui, la plupart du temps, les solutions qu’on met plusieurs semaines à trouver sont toutes connes, mais fallait trouver la bonne façon de les aborder.

Aujourd’hui on va donc parler d’un souci qui peut vous avoir été soumis, surtout si vous avez déjà suivit mes tutos sur le NFSRoot.

Voila, imaginez une situation lambda, vous avez un système bombardé en nfsroot, et vous possédez un autre serveur qui se monte dans ce système linux (en gros une architecture classique de développement avec un système et un serveur de fichier qui lui est raccordé.

Vous vous retrouvez donc avec, dans le système linux nfs, un bout de votre fstab qui ressemble plus ou moins à ça : 

nas:/nas /nas nfs4 1 0

C’est une configuration assez intéressante, simple a mettre en place, et loin d’être contestable. Au niveau de la fiabilité, elle est aussi contestable qu’une ou les systèmes serait interne aux machines, dans la mesure ou, en cas de panne du système, le serveur de fichier servirai à rien, et en cas inverse, un système sans serveur de fichier ne permettrait pas de bosser (ou peut être zoner sur Internet, et encore)

Bref, dans une logique de limitation des ressources, et pour en finir avec un serveur de fichier assez vieux et pantouflard, l’idée est venue de tout réunir au sein d’un même serveur. Le système et les données.

 

Pour ce faire, et éviter d’exporter depuis ce serveur les fichiers ET le système avec deux lignes dans le fichier d’exportation, on va faire une petite manip pour faire du deux en un.

Reprenons notre fichier d’exportation du système Ubuntu en nfsroot (voir tuto : http://dontpanicit.tumblr.com/post/11432209474/installation-dun-systeme-nfsroot-et-le-lancer-via ).

Imaginons qu’en temps normal, notre dossier de serveur de fichier soit à la racine  (monté comme cité plus haut) sous forme de :

/nas

Sa position dans le NFSR(NFSRoot), vue du serveur, serait donc ici :

/srv/ubuntu/nas

L’idée c’est donc de monter la partition qui contiens /nas (ou de monter le dossier en bind) directement dans ce dossier, et de lancer notre système, et penser à retirer de notre fstab de notre système ubuntu NFSR la ligne de montage NFS du nas.
Donc fstab du serveur :
/dev/sda42 /srv/current/nas filesystemtype defaults 1 1

Et plus de trace d’un montage du nas:/dns-nas dans le /srv/current/etc/fstab!

Si vous le faites, et que vous lancez votre système, il va démarrer, et un ls -al dans votre dossier /nas va vous montrer que … ça ne marche pas 8D.

PAS DE PANIQUE!

C’est tout a fait normal. Pour limiter les risques d’intrusion depuis le système jusqu’au serveur, GNU/Linux est justement configuré pour masquer les partitions montées ou disponibles du serveur depuis les clients. C’est une mesure de sécurité tout à fait logique de la part des concepteurs du système d’exports.

Il faut donc trouver les arguments qui vont bien pour justement by-passer cette sécurité en disant à l’exportation de se montrer nu comme un ver lors de son exploitation sur les machines clients.

C’est un lot de 3 options dans le man exportfs de Linux qu’il était important de repérer :

nohide - Première pierre angulaire de notre exportation, elle force les exportations à tout montrer. Nécessaire mais pas suffisante, elle a besoin du complément suivant.

crossmnt - Deuxième pierre, elle sert à montrer précisément les périphériques montés à la source, c’est à dire par le serveur.

Et enfin par mesure de précaution pour éviter les conflits de racine, on va poser un petit
fsid=0
Qui va quand même garantir la racine du système correctement, et rétablir un semblant de sécurité.

Donc au final notre ligne d’exportation va ressembler à ça : 
/srv/current/   192.168.0.0/24(rw,no_root_squash,async,subtree_check,nohide,crossmnt,fsid=0)

NB : Notez la nouvelle façon de noter l’IP, c’est elle la correcte :p. 

C’était vraiment bête comme idée, mais il fallait y penser.

C’est super pratique parce qu’on perd en complexité et on gagne en vitesse de traitement. Maintenant tout est empaqueté à la source, magique!


Voila c’est tout pour le tuto. Si vous avez des questions, n’hésitez pas. 
Spéciale bigup à @joellecorre qui ,lors de son bref passage parmi nous, m’a montré yEd, le logiciel que j’ai utilisé pour vous faire les jolis dessins ci dessus. Pensez à aller voir son blog, il est pas mal : Sublimigeek

 Bonne journée les gens :D.

Bonjour à tous!

Petit tuto aujourd’hui, plus précisément un complément de plus à l’utilisation d’un système nfsrooté.

Pour ceux qui auraient suivi le tuto sur l’installation du Linux en NFSroot, vous aurez peut être remarqué l’incapacité du système à démarrer des logiciels tels que Thunderbird, Skype etc…. Et bien c’est que ces système ont besoin d’une couche de cache que le NFSroot ne peux pas leur donner en natif (pour ceux qui auraient d’ailleurs lancé des débugs consoles sur ces applications, ont pu constater que leurs logs les gratifiaient d’un magique “SegFault”).

Ici on va voir comment y remédier.

Tout d’abord, il faut installer notre couche de cache, et pour cela, on va faire appel au paquet “nscd” (ou “Name Service Cache Daemon”).

Comme d’hab quand on installe une application, ont passe par apt-get :

~# sudo apt-get install nscd

Une fois l’installation terminé, on reboot tranquille, on se dit “Tout vas bien, pas d’erreur”, on clic que notre application Thunderbird et là… rien. Rien ne se lance.

PAS DE PANIQUE

Avant de me jeter des cailloux pointus à la gueule, dites vous bien que je me suis cassé le cul à plusieurs reprises (et je remercie encore “Ô mon Maitre” Yann pour me secourir dans des moments difficiles) en cherchant la source de l’erreur.
Après avoir longuement suspecter le script de démarrage de faire de la merde, j’ai ensuite compris finalement (via des echo tassés dans des fichiers) que le script n’était même pas appelé au démarrage du système.

En fait, depuis la 11.04 (voir même la 10.10 - 10.04 je crois), on ne passe plus par les runlevel de Système V pour démarrer des démons sous Linux, mais on utilise un nouveau système nommé UpStart. Ce dernier en fait prend la mains sur pas mal d’élément du démarrage, ce qui peux laisser perplexe quand on ne le sait pas.

Seulement, NSCD n’est pas fait pour démarrer par upstart, ce qui fait que ce dernier lui roule dessus au démarrage sans que NSCD puisse moufter sa sauce. Par conséquent il faut créer des scripts custom dans le répertoire de gestion d’upstart (comme on aurai pu faire avant dans les runlevels) afin de lui dire “Hey connard! T’es gentils, tu laisses les autres jouer!”.

voici donc le script a placer dans /etc/init/nscd.conf (Oui, le fichier n’existe pas, il faut le créer).

description	"name service cache daemon"

start on local-filesystems
stop on runlevel [06]

#expect fork
pre-start script
    mkdir -p /var/run/nscd
end script

exec /usr/sbin/nscd -f /etc/nscd.conf

Merci d’ailleurs à spidernik84 du forum Linuxquestions.org pour avoir trouvé ce script plus ou moins miraculeux.

Une fois ce script posé et enregistré, vous pouvez redémarrer votre linux et là, tadaaaa, Thunderbird se lance! Magique!

Reste cependant un dernier problème à résoudre : Cette solution est plus ou moins bonne car elle est faite main. Le délire c’est qu’il est possible qu’une mise a jour fasse sauter tout ça (upstart, nscd, ubuntu lui même). Si le problème ce représente, vous saurez cependant quoi faire!

NB : J’ai utilisé cette solution avec le paquet “unscd” mais techniquement tout devrait fonctionner correctement quand même avec la version nscd originale. Notez que pour “unscd” d’ailleurs, le fichier de conf est le même (et s’appelle aussi “nscd.conf”), puisque les binaires et les fichiers .conf de unscd se nomment nscd tout court. Donc le script est interchangeable.

Bonjour à tous, et bienvenu pour un nouveau tutoriel qui, je l’espère, sortira certaines personnes de l’impasse.

Dans un précédent tuto, j’avais expliqué comment installer pfSense sur un Soekris net4501.
Mon choix pour pfSense était orienté pour plusieurs raisons :
-pfSense est fiable. On l’utilisait déjà dans ma boite sur l’ancien routeur, qui était en fait un ordinateur complet au service du routeur. Même dans sa version béta, il fonctionnait déjà très bien (exception faite d’un problème lors du redémarrage en cas de coupure de courant, qui oblige à rentrer à la main la commande de mount de la partition de root).
-Disposant de deux connexion internet, on avait un besoin vital de load balancing et de la gestion de deux Gateway pour notre réseau et nos serveurs internes, et contrairement à m0n0wall, son prédécesseur, pfSense le gère mieux que bien.
-Je pensais, à tord, que pfSense était un produit léger. En fait cette vision erronée était due au fait que je n’avais pas vu le faussé ce creuser entre les v1.x et les v2.x. Depuis la v2, pfSense nécessite plus de 128MoRAM.
-Le fait aussi de disposer du même système que l’actuel, je ne me pausai donc pas la question de la portabilité de la config.

Seulement voila, comme dit plus haut, pfSense a grossi, il est devenu gourmand en performance, et demande désormais plus de 128MoRAM. Épique déception car, au moment du tuto précédent, je disposai d’un Soekris net4501 disposant de 32MoRAM, soit trois fois en dessous du seuil critique.
C’est à sa première journée de mise en prod que les crash successif et les erreur 500 sur la page de gestion de config, m’ont fait réalisé mon erreur.

Il a donc fallu rechercher d’autres solutions.
Voici un peu mon cheminement et les raisons pour lesquelles je ne les ai pas sélectionnée :

-m0n0wall (freeBSD) : Petit, léger, pratique, l’interface web est assez simple et esthétiquement agréable (contraste radicalement avec le rouge/gris de pfSense assez agressif). Il ne dispose cependant pas de gestion du Dual-WAN/Load Balancing ni d’une prise de commande en SSH, ce qui pose un réel problème de configuration profonde, obligeant l’utilisation du port série. On peut s’amuser à ajouter des modules particulier, mais c’est une plaie. J’ai vite été découragé par l’absence totale d’activité en ce qui concerne le développement de nouvelles versions, qui avant me laisser envisager de possibles updates.
-netBSD pure (netBSD) : J’ai envisagé brièvement de monter un netBSD purement et simplement, et d’y incorporer les paquets nécessaires pour permettre de faire tourner ce qui devait tourner. Le problème était que, tournant sous linux, je n’avais pas vraiment de base pour débuter. Jugé trop long et trop complexe, l’idée a été abandonnée.
-LFS Linux From Scratch (GNU/Linux) : Dans le même raisonnement que pour netBSD, l’idée était assez séduisante, étant donné ma proximité avec le système linux et excellente documentation internet. Malgré l’enthousiasme que cette idée a suscité (création d’une distribution personnalisée et m’appartenant), l’idée a cependant été abandonnée à cause de la trop grande demande en temps et l’investissement personnel nécessaire à sa bonne réalisation.
-ipCop (GNU/Linux) : Une des distribution principales de routeurs. malgré l’absence de load-balancing pré-installé, l’idée de tourner sous linux est intéressante dans le sens ou, le système m’étant familier, je pouvais envisager, mieux que sur un BSD, l’hypothèse de charger moi même les paquets nécessaires. Malheureusement, ipCop n’est pas vraiment prévu pour fonctionner en embarqué. De plus le comportement agressif et l’aide minimale obtenue sur le forum de soutien de cette distribution m’ont réellement dérangé. Enfin, ipCop, dans son incapacité à dégainer une version embarqué facile d’installation pour CF, j’ai été dans l’incapacité de faire démarrer ne serai-ce que le bootloader.
-OpenWRT (GNU/Linux) : Au bord de la crise de nerf profonde, on est tombé par hasard sur une distribution prometteuse nommé “OpenWRT”. Fonctionnant sous Linux, gérant le Load Balancing, le multi-wan, ayant un protocole SSH et une interface web, et surtout spécialisé pour l’embarqué, le choix s’est donc imposé.

Matériel requit :


- Un routeur Soekris net4501
Je suis passé à une version légèrement au dessus pour cette installation. Il dispose du même processeur que le précédent, à la différence qu’il possède 64MoRAM. Je dois normalement faire un portage vers la version 32MoRAM (cf. Tuto Soekris pfSense), si jamais je rencontre un problème, je publierai une petite note.
-Un câble série.
-Un lecteur de carte CompactFlash (CF).
-Une carte CF d’au moins 128Mo.
-Les images de OpenWRT Backfire 10.03.1-RC6, à savoir :
—OpenWRT x86 generic combined jffs2 128k (contenant la partition de boot et l’image kernel)
—OpenWRT x86 generic combined ext2 (contenant les root systèmes)
Les images sont disponibles ici : http://downloads.openwrt.org/backfire/10.03.1-rc6/x86_generic/

Pourquoi la 10.03.1-RC6 ?

Et bien au moment ou j’écris ce tuto, c’est la version la plus récente.
Ensuite, faites l’expérience et chargez vos images dans votre CF, et bootez naïvement votre routeur.

Et bien vous aurez 2 problèmes :
-un bon gros “waiting for /dev/sda2”
-Et si vous passez cette étape, vous vous retrouverez devant un système qui ne reconnaîtra pas vos interfaces réseau. Gênant pour un routeur non?

PAS DE PANIQUE

La dernière version comporte des correctifs qui permettent de passer ces quelques blocages. De plus elle est stable, ce qui rajoute son intérêt.

Étape 1 : Configuration préalable de minicom et du BIOS routeur.

Tout d’abord, on commence par lancer minicom. Il faut le configurer en 19200n8 pour pouvoir se connecter au routeur (ce n’est pas sur, les vitesses pas défaut varie, surtout si ils sont de 2nd main).

# minicom /dev/VOTRE_PÉRIPHÉRIQUE_SERIAL

si vous utilisez comme moi un cable série-USB, ce sera /dev/ttyUSB0.

Une fois dans minicom, faites Ctrl+O, puis allez dans régler le port série, puis tapez sur E pour accéder à la vitesse de transmission. Une fois dedans, régler la vitesse.

Ensuite, branchez votre cable série sur le routeur, et alimentez le.

Une fois au terme du chargement du BIOS, avant que les 5 secondes ne soit écoulé, tapez “Ctrl+P”. Vous devriez avoir un prompt “>”.
Tapez :
> set ConSpeed=38400
puis
> reboot

Pendant que le routeur redémarre, retournez dans le menu Ctrl+O -> E -> et réglez la vitesse sur 38400. Voila, votre routeur, votre minicom ET bientôt votre système seront synchronisés sur la même vitesse, à savoir 38400 bauds.

Etape 2 : Installation des images en dd sur la CF.

Une fois vos images de OpenWRT téléchargées sur votre disques, et que vous connaissez leur emplacement absolu (histoire de ne pas se tromper), et que votre carte CF est correctement introduite dans le lecteur de carte, vous allez lancer les lignes de code suivante :

# dd if=chemin/openwrt-x86-generic-combined-jffs2-128k.img of=/dev/sdb
# dd if=chemin/openwrt-x86-generic-combined-ext2.img of=/dev/sdb

ATTENTION : Comme dit dans un tuto précédent, le dd est une arme absolue. Elle écrase tout et ecrit par dessus. Par conséquent, si jamais vous tappez quelque chose dans le genre /dev/sda au lieu de /dev/sdb, c’est votre disque dur qui y passe. Et là vous n’avez AUCUNE chance de récupérer le moindre fichier. C’est puissant, et par conséquent c’est a utiliser avec précaution.

Si tout c’est bien passé, normalement deux éléments sont apparus dans /dev/ : sdb1 et sdb2. C’est là toute la magie de faire du transfert d’image comme ça, il se démerde pour faire les choses bien.

Étape 3 : Installation de la CF et lancement du routeur.

Bon, bin maintenant on peut plugger la carte dans le port CF de votre soekris, lancer minicom, et mettre le soekris sous tension.

Le BIOS se lance, il annonce le lancement de grub, et là BAM! Caractères étranges en tout genre qui s’animent.

PAS DE PANIQUE

D’après mon expérience, le Soekris n et4501 banché en série ne supporte pas grub visuellement. Sur certains appareils, les comportements varient : Ils peuvent ne pas aller plus loin que grub, ou se lancer sans l’afficher correctement.

Heureusement, dans mon cas, j’ai été dans la 2e solution.

Après quelques secondes d’attentes, vous pouvez apercevoir le chargement du noyau. A la ligne : Please press Enter to open Terminal, n’appuyez pas dessus. Il va y avoir un module (NatSemi pour les interfaces réseau du soekris) supplémentaire qui va se lancer et qui risquerai de ne pas bien afficher la so cute présentation d’OpenWRT.

Et voila, maintenant cliquez sur Entrée et dites bonjour à OpenWRT embarqué =).

Notes :

Adresse IP : Par défaut, l’IP du routeur est définie par OpenWRT comme étant la 192.168.1.1. Au cas où comme moi vous auriez la nécessité de changer, les fichiers de configuration du réseau (et tant d’autres) sont ici :

# vi /etc/config/network

Puis ensuite allez dans l’interface eth0 et changez

ipaddr 192.168.1.1 en ipaddr 192.168.***.*** <- l’adresse IP que vous voulez.

Ensuite procédez à un reboot des interfaces via cette commande :

# /etc/init.d/network restart

Et voila, maintenant l’interface web de configuration est disponible en ligne à l’adresse IP indiquée !

ENJOY YOUR OPENWRT ROUTEUR!!