Il y a un certain temps, j'avais parlé du concept du self-hosting. Il s'agit de posséder son propre serveur, et donc, par extension, ses données.

Bien entendu, il n'est pas nécessaire pour cela de posséder physiquement son propre serveur (encore que ce soit possible, mais ce n'est pas le sujet abordé ici.)
Nous expliquerons ici les étapes nécessaires pour arriver a avoir un serveur utilisable, du moment ou vous arrivez sur le système fraichement installé, au moment ou vous possédez un serveur avec tous les paquets nécessaires a l'utilisation que l'on veut en faire ici d'installés. Cette partie va consister a paramétrer le système (ici un debian squeeze. Il est bien sur possible de faire la même chose avec a peu près toutes les distributions Linux disponibles, tout comme avec les BSD et tous les autres systèmes UNIX, mais je vais ici me limiter a debian 6.0.x squeeze, parce que c'est une distribution simple a utiliser comme serveur, stable, et facile a configurer (puisqu'une bonne partie de la configuration est déjà faite et incluse dans le paquet), donc adaptée au but de cet article, a savoir rendre l'installation simple et compréhensible).

La première chose a faire est bien entendu d'obtenir le serveur en lui même. Cette partie de la chose ne sera pas traitée dans cet article. Il existe en effet un nombre infini d'obtenir un serveur, que ce soit en le louant chez OVH/1&1/n'importe quel autre hébergeur commercial, en participant a un système d'hébergement collaboratif (je vous laisse chercher), en achetant un serveur et en le faisant fonctionner de chez vous, en utilisant un vieux PC... Bref, les possibilités sont multiples. Dès lors que vous avez accès a un système debian serveur, peu importe sur quel matériel il fonctionne, et a priori peu importe aussi la manière dont vous y accédez, le résultat est le même (et la procédure aussi...). Dans cet article, nous parlerons de la configuration de base, du moment ou vous avez le serveur vierge dans les mains au moment ou vous installez le serveur http.

Dans cet article, lorsque est précisée le type d'IP a utiliser, il convient de mettre ce type précisément. Quand le type n'est pas précisée, libre a vous de choisir ipv4 ou ipv6.

Bref. Commençons au point ou vous avez un accès root a votre serveur, n'ayant soit aucun mot de passe, soit un choisi par l'hébergeur, et ou rien n'est configuré. Connectez vous a celui-ci (ssh root@). Commencez donc par faire un passwd, pour mettre au plus vite un mot de passe solide sur le compte root. Continuons en allant vite mettre en place le nom de domaine. Pour cela, votre registrar doit vous fournir une interface vous permettant d'éditer l'entrée DNS pour votre nom de domaine.

Cette entrée doit donc pour l'instant ressembler a ca :

    <votre nom de domaine>  NS 1 
                            IN MX 1 
                            IN A        <IPv4 de votre serveur>
                            IN AAAA     <IPv6 de votre serveur>

Cela vous permet de rediriger tout le trafic se référant a votre nom de domaine vers votre ip (le fonctionnement exact du DNS est assez compliqué a expliquer, donc on va dire que c'est de la magie pour l'instant, ca sera peut être le sujet d'un autre article), et d'indiquer que les mails @votre-nom-de-domai.ne doivent aussi être redirigés vers votre serveur, ce qui est un bon début. Faisons un petit point sécurité ici : pour accéder a votre serveur, il vous suffit actuellement de taper le mot de passe root.

root est un utilisateur assez répandu, et il est assez simple de bruteforcer le mot de passe. (Relativement assez simple, en fonction du nombre de caractères, ça prend plus ou moins de temps, et si vous avez suffisamment de caractères, ça peut prendre un temps assez conséquent. Cela dit, il vaut mieux être prudent...) Ainsi, nous allons arrêter d'utiliser root et nous allons commencer a utiliser des couples clés publiques/privées pour nous connecter au serveur.
Cela se fait en deux temps : tout d'abord, créer un nouvel utilisateur, grâce auquel nous administrerons le serveur a l'avenir; puis configurer OpenSSH pour que celui ci n'accepte que les connections par clés et plus celles sur root.

Commençons par ajouter un utilisateur. Si vous êtes sous debian, cela se fait avec adduser, qui est interactif (vous ne devriez pas avoir de problème avec, puisqu'il crée tout les dossiers et fichiers nécessaires, et vous pose toutes les questions utiles pour vous aider.) sinon, vous devrez utiliser useradd, qui est (en plus d'être très chiant a distinguer de l'autre, bien plus chiant a utiliser. (adduser est en fait un simple script permettant l'utilisation d'useradd plus facilement.)

Avec adduser, vous pouvez soit utiliser le mode interactif en tapant juste adduser <username>, soit utiliser le mode non-interactif en faisant un adduser --group <username>

Avec useradd, vous devrez utiliser la commande suivante : useradd -m -N -g <username>. Cette commande ajoutera un utilisateur, créera son dossier principal dans /home/, et l'ajoutera au groupe du même nom que lui (ce qui est en général nécessaire pour des questions de vie privée).

Il convient maintenant d'ajouter cet utilisateur aux groupes qu'il sera amené a administrer: usermod <username> -a -G www-data postfix users staff sudo wheel, puis de changer son mot de passe passwd. Enfin, ajoutons le aux utilisateurs autorisés a utiliser sudo: echo "%sudo ALL=(ALL) ALL" >> /etc/sudoers
Enfin, changeons d'utilisateur : su. A ce point, vous avec un utilisateur complètement fonctionnel et utilisable pour toutes les taches d'administration. Si vous devez encore utiliser root, c'est que quelque chose ne va pas.

Vous êtes donc loggés sur le système en tant qu'utilisateur normal. Nous allons maintenant passer a la phase 2 du plan : désactiver le login ssh root et le login ssh par mot de passe.
Tout d'abord, qu'est-ce qu'un login par clé ssh? Il s'agit en fait d'un système assez semblable a celui vous permettant de chiffrer vos mail : vous avec une clé publique et une clé privée sur le client, et la clé publique est aussi sur le serveur. Lorsque vous vous connectez, openssh vérifie que vous possédez la clé privée qui correspond a la clé publique stockée sur le serveur (pour votre utilisateur, bien entendu). Il est également possible d'utiliser plusieurs clés publique pour chaque
utilisateur.

Bref, maintenant que nous avons la théorie, passons a la pratique : tout d'abord, il nous faut générer un couple de clés publique/privée sur le client. Openssh fait ça via la commande ssh-keygen -t rsa (le -t rsa précise a ssh que nous voulons un chiffrement rsa, qui est suffisamment solide pour cette utilisation.) Entrez les informations que ssh-keygen vous demande. Trois fichiers devraient maintenant se trouver dans votre dossier .ssh/ : id_rsa, id_rsa.pub, et known_hosts.
known_hosts liste les serveurs auxquels vous vous êtes connectés déjà une fois (pour éviter les attaques MITM, mais bref). Non, ce qui nous intéresse ici c'est id_rsa et id_rsa.pub . id_rsa contient votre clé privée, sauvegardez la sur une clé USB ou notez la sur un bout de papier, si vous la perdez, vous ne pourrez plus vous connecter au serveur. (planquez la clé usb/le bout de papier...) id_rsa.pub, quand a lui, contient votre clé publique. Copiez la sur le serveur, avec un scp ~/.ssh/id_rsa.pub <username>@<votre nom de domaine>:~/ , ou en la copiant a la main, si ça vous amuse.

Vous avez maintenant un fichier id_rsa.pub dans votre dossier personnel sur le serveur, il faut le mettre a un endroit ou openssh le reconnaitra. Il est donc nécessaire de créer le dossier .ssh (mkdir .ssh), puis de déplacer ce fichier a la bonne place (mv ~/id_rsa.pub ~/.ssh/authorized_keys). Testez si ça fonctionne : ouvez un autre terminal, et
connectez vous a votre serveur (ssh <username>@<votre nom de domaine>), et il ne devrait pas vous demander de mot de passe.Si il vous en demande un, NE PASSEZ PAS A LA SUITE. Quelque chose a foiré, donc vérifiez que vous avez suivi correctement les instruction ci-dessus.

Continuons. Il ne nous reste plus qu'a installer le serveur web, et a le configurer:

sudo apt-get install \
apache2 apache2.2-common apache2-doc apache2-mpm-prefork \
apache2-utils libexpat1 ssl-cert libapache2-mod-php5 \
php5 php5-common php5-gd php5-cgi libapache2-mod-fcgid \
apache2-suexec php-pear php-auth php5-mcrypt mcrypt \
php5-imagick imagemagick libapache2-mod-suphp libruby \
libapache2-mod-ruby

(faisons large, on aura besoin de l'excédent plus tard...), puis activons les
mods apache en faisant a2enmod suexec rewrite ssl actions include dav_fs dav auth_digest, et faisons en sorte que ces activations soient prises en compte par apache via un sudo service apache2 restart

Le serveur fonctionne, maintenant, il est necessaire de lui expliquer comment fonctionner sur notre nom de domaine et ou trouver les fichiers a envoyer.

Pour cela, nous allons faire un simple ln -s /etc/apache2/sites-{available,enabled}/default, car apache est assez sympa pour nous filer un fichier de configuration par défaut. Il nous faut encore l'éditer, en changeant l'adresse mail au début du document par la votre, et en changeant AllowOverride none en AllowOverride All, et enfin redémarrer apache pour qu'il prenne en compte les modifications, par un sudo service apache2 restart

Et maintenant, il vous reste a apprendre le html, parce que ca y est, votre serveur est fonctionnel! Voila voila. Dans la prochaine partie, on verra l'installation du serveur mail (c'est suffisamment complexe pour prendre un article seul...)

This is subject to debate, and as most of the actors in this field are not French-speaker, there is an English version of this text here

Bon, voila. J'ai passé le cap. Je suis sous GNU/Linux depuis un certain temps, maintenant, et depuis un certain temps je remarque des changements malvenus. Bien entendu, au début, je n'avais pas les connaissances nécessaires pour comprendre ne serait-ce que ces modifications existaient. Et puis certaines sont arrivées avant que je n'ai même idée que quelque chose dans mon système d'exploitation avait cette fonction la. Par exemple, udev, ou policykit/consolekit/. A l'époque, je n'avais aucune idée de la façon dont les disques étaient montés sur mon système. Le premier système non-Windows que j'ai utilisé fut Ubuntu 9.10 Karmic Koala, et il était encore trop tôt pour que je cherche a démonter le système pour comprendre comment il fonctionnait en profondeur. Cependant, avec le temps, les connaissances s'accumulant et mon niveau de compréhension du système s'améliorant, j'ai commencé a remarquer que certain bouts de l'OS ne collaient pas exactement avec les autres. Bien sur, je ne saurais dire si cette réalisation s'est faite a cause de la recrudescence de ces bouts d'OS, ou bien juste a cause de ma compréhension plus poussée. Toujours est-il que ces petits bouts d'OS ne s’adaptant pas au reste du système se faisaient de plus en plus visible. Et puis, un jour, j'en ai eu marre de voir unity sur ma machine, et j'ai choisi de passer a Archlinux. C'était avant le passage a systemd. Ce système me convenait bien. Si je n'installais pas Gnome, ce que je ne comptais pas faire, il ne me forçait pas a installer un *kit quelconque, ni dbus. Oui, udev était toujours la, mais c'était le moins envahissant de ceux la.

Mais Archlinux est passé a systemd. Attention hein, je ne critique ici ni systemd, ni udev, ni même les kit, et surtout pas Archlinux. Les premiers sont probablement très efficaces dans leur domaine, et le second n'a pas vraiment eu le choix, rapport a la philosophie de la distribution d'avoir au plus vite les dernières versions de tout. Cependant, systemd, tout comme udev et les kits (bien que ce ne soient pas les seuls a faire ça...) ont un problème très précis, qui n'importe pas a tout le monde, mais qui est très gênant pour ceux a qui il importe, et ce problème est que ces systèmes ne respectent absolument pas la philosophie UNIX. La philosophie UNIX, pour rappel, se résume en ces 9 principes :

1. Ce qui est petit est beau
2. Faites en sorte que chaque programme fasse une chose, bien.
3. Faites un prototype aussi vite que possible
4. Choisissez la portabilité plutôt que l'efficacité
5. Stockez les données dans des fichiers textes.
6. Utilisez ce qui existe déjà a votre avantage. [1]
7. Utilisez des scripts shells pour faciliter la portabilité et la réutilisation.
8. Évitez les UI qui "capturent" l'utilisateur.
9. Faites de chaque programme un filtre.

Alors bien entendu, un système d'exploitation est fait pour évoluer, et on pourrait penser qu'UNIX a fait son temps. Cependant, ce n'est pas exactement la façon dont l'informatique fonctionne. Effectivement, les standards, les systèmes d'exploitation, les logiciels, tout doit évoluer - ou mourir - et UNIX ne fait pas exception a la règle. Mais ce n'est pas d'UNIX que nous parlons ici. C'est de la philosophie UNIX. Et celle-ci n'a pas fait son temps, elle a fait ses preuves. La philosophie UNIX, en plus d'être efficace sur le papier, a aussi 44 ans de tests derrière elle, et fonctionne aussi bien qu'au premier jour.
La philosophie UNIX est aussi et surtout une garantie d'utilisabilité et de simplicité pour les administrateurs systèmes, pour les développeurs, bref pour tous ceux qui font de l'informatique sérieusement (je ne dis pas que les autres métiers de l'informatique ne sont pas sérieux, je prend juste ceux-ci comme exemples parce que ce sont ceux qui sont les plus proches du système).

Tous OS se doit d'avoir un système standardisé pour faire communiquer les programmes entre eux. UNIX a un système de pipes, des sortes de fichiers spéciaux permettant d'échanger des informations. C'est efficace, ça respecte le "tout est fichier", c'est standard, c'est simple a comprendre, bref, ça fonctionne parfaitement. Dbus vient remplacer ça, avec une interface qui n'est explicitement pas faite pour être utilisée a la ligne de commande mais a l'aide d'APIs, et un programme monolithique qui effectue sa tache d'une façon complètement obscure pour l'utilisateur. Alors bien sur, il l'effectue d'une façon efficace, cette tache. Oui, ça va plus vite qu'avant. Oui, c'est plus "rangé", ça fait moins "fouillis". Mais c'est moins efficace. C'est beaucoup moins utilisable pour l'utilisateur final. C'est horriblement chiant pour les sysadmins, parce qu'ils ne peuvent plus lire facilement les échanges entre programmes. C'est peu pratique, en fin de compte. Et ça ne respecte pas du tout la philosophie UNIX.
Systemd prend le même parti de créer une interface unifiée, accessible via des appels a des APIs uniquement, complètement obscure, extrêmement abstraite, bien entendu monolithique, et très peu ouverte a la modification par l'utilisateur final. Alors oui, il parait que ça augmente la vitesse de boot. Eh bien, au risque d'en choquer quelques uns, je préfère avoir un système qui boote légèrement plus lentement et que je puisse modifier facilement, et qui soit ouvert, compréhensible et distribué. C'est presque comme si les projets freedesktop.org avaient pour but de remplacer la base UNIX de linux en créant un système concurrent, bâtard, bâti sur le kernel Linux mais n'employant plus les systèmes basiques d'UNIX.

Le problème est qu'il est facilement visible que la direction prise par la communauté Linux n'est pas celle du retour sur les systèmes UNIX ni celle du développement de solutions respectant la philosophie UNIX, mais remises au gout du jour (?), mais est bien d'accepter et de pousser les changements apportés par les projets freedesktop.org directement dans le cœur du système lui même. Ainsi, Fedora (très près de Red Hat, dont font partie de nombreux développeurs de ces projets), a déjà adopté tous ces changements (archlinux aussi, mais pour d'autres raisons...), et on peut compter sur le fait que les autres distributions l'adopteront un jour ou l'autre.

Bon, maintenant que nous avons, si ce n'est démontré la nocivité de ces systèmes, tout du moins exprimé les raisons qui font qu'ils me déplaisent, on pourrait penser qu'il suffit de passer a une distribution n'incluant pas systemd, voire a une distribution n'incluant pas du tout de contenus freedesktop.org, et de vivre avec le fait de ne pas être sur archlinux. Cependant, avec un peu de réflexion, on voit que si des distributions comme archlinux et Fedora ont adopté systemd (et qu'OpenSUSE est en train de l’intégrer), il est probable que cela devienne un standard au fil des années, et que seuls survivent systemd et upstart, le gestionnaire de démarrage d'ubuntu, qui ne changera probablement pas (je les vois mal revenir en arrière sur ce point.) Toujours est-il que l'init héritée du System V semble condamnée a mourir sous Linux. Il pourrait être judicieux de passer sous debian squeeze, qui ne recevra probablement jamais la mise a jour, ou a wheezy, qui ne la recevra probablement que dans 2/3 ans. Cependant, cette période est toujours trop courte, et met sur mon système d'exploitation une date d'expiration, chose qui ne me plait que moyennement. Non, la solution est de passer sous un système autre, qui ait son propre système d'init (ou qui ne risque pas de passer sous systemd). Dans ce cas, deux options principales s'ouvrent a moi: OpenSolaris et *BSD. Minix n'est pas vraiment un choix, vu le peu de programmes qu'il permet de faire fonctionner et le fait qu'il ne soit disponible que sur i386, ce qui n'est pas vraiment avantageux au vu de mon système en x86_64. Haiku n'est pas un choix non plus, puisque le but est de rester dans une optique UNIX.

OpenSolaris est un système d'exploitation tout a fait valable. Je n'ai en théorie aucun problème sur cet OS, sauf que certains choix de design ne correspondent pas du tout a l'idée que j'ai d'un OS. En effet, OpenSolaris ressemble assez a Debian dans sa vision du fonctionnement de ses outils, avec des paquets modifiés pour les rendre plus simples a utiliser (fichiers de configuration fournis par défaut, par exemple, et autres patchs "release-only"), et une tendance a faire des scripts et des outils installés par défaut pour tout et n'importe quoi. Bref, cela n'est pas le sujet. Il convient aussi de voir qu'avec la récente acquisition de Sun par Oracle, il est possible que le projet OpenSolaris n'ait pas de très beaux jours devant lui (la page d’accueil du projet affiche d'ailleurs un ÉNORME logo Oracle, du meilleur gout.)

Il reste donc *BSD. Pourquoi choisir FreeBSD plutôt qu'OpenBSD, NetBSD ou DragonFlyBSD (pour ne citer que les plus connus) ? Et bien c'est simple : pour aucune raison particulière. OpenBSD et NetBSD ont pour réputation d'être orientées sécurité, et d'après ce que j'ai pu en voir DFBSD ressemble aussi au système de l'assistance a l'user a outrance décris plus haut. Mais la vérité est que je n'ai pas fait suffisamment de recherches et que FreeBSD ne va me voir arriver que par hasard, parce qu'entre toutes les BSD ca me semble la plus sympa et la plus agréable a utiliser, plus le fait que le système de ports me convient bien (j'aime pouvoir configurer mes logiciels de façon assez profonde.)

Voila, c'est mon avis sur ce "problème" actuel du monde de Linux. Bien entendu, je continuerai a utiliser Linux, et je ne peux qu’espérer que les systèmes tels que systemd ou dbus ne disparaissent, ou tout du moins n'apparaissent jamais chez certaines distributions, créant de ce fait un choix pour les utilisateurs.
[1]: Je n'ai pas trouvé de traduction satisfaisante a "software leveraging", mais l'idée est la...*

Bon.
J'ai annoncé il y a environ 20 jours que j'avais pour projet de faire une Piratebox basée sur un Raspberry Pi, astucieusement nommée PiRatBox. Il se trouve qu'après de nombreux essais, un problème récurrent apparait: le Raspberry Pi n'est pas capable de fournir assez de courant par défaut pour faire fonctionner a la fois un disque dur et une antenne WiFi.
Alors, autant il me semble évident qu'avec une alimentation provenant d'un port USB a 2A (max), je n'avais pas énormément de chances d'avoir 2A sur chacun des ports host du Raspi, autant avoir moins de 250 mA sur chacun de ces ports me semble un tout petit peu exagéré en terme de rentabilité.

De même, le fait de ne pas pouvoir désactiver le port Ethernet (ne me servant a rien) (vous savez, celui qui est monté en USB...), qui consomme énormément, est assez louche. Il devrait toujours être possible de désactiver une device USB, me semble-t-il, au niveau logiciel. La, bien qu'il soit surement possible de la désactiver au niveau du kernel, il n'est pas simplement possible de la "débrancher". Ce qui est bien chiant, étant donné le besoin évident de puissance électrique dans lequel on se retrouve.

Bon, je dois avouer n'avoir pas testé de lancer les différents services composant le système des piratebox sous arch, pour la simple et bonne raison qu'arch utilise systemd et qu'il n'existe pas de wrapper systemd pour les daemons piratebox, et que j'ai la flemme d'en faire, parce que systemd est une horreur a utiliser avec les scripts init. Donc non, j'utiliserai debian. Le problème d'utiliser debian dans ce cas précis est que apt/dpkg a une gestion des dépendances dans un sens mais pas dans l'autre, en ce sens que si on installe un package "haut", c'est a dire dépendant de plusieurs autres packages, apt/dpkg se charge efficacement d'installer toutes les dépendances nécessaires, tandis que si on désinstalle un package "bas", c'est a dire sur lequel de nombreux autres packages dépendent, apt/dpkg ne désinstalle pas ces packages "hauts", ce qui pose un vrai problème quand on se retrouve sur un Raspberry Pi, puisqu'il n'y a pas de moyen "facile" de choisir ce qui sera installé sur le système avant l'installation proprement dite (puisque le moyen "universel" d'installation sur Raspberry Pi est le dd vers la SD qui sert de disque système.)

Il y a énormément d'autres critiques que l'ont pourrait faire concernant le Raspberry Pi. Son système de démarrage a s'arracher les cheveux, par exemple. En effet, plutôt que de faire comme tout pc normalement constitué ou la partie calcul démarre, lance le bootloader, cherche le kernel de l'OS qui lui même se lance, initialise le hardware, etc..., a un système bâtard du au fait que la puce au centre de la carte est a la base une puce graphique a laquelle on a greffé un cœur de calcul (probablement au fond d'une cour d'immeuble, dans les quartiers pauvres de Bratislava, vu la propreté de la greffe...), et le moyen le plus efficace qu'aient trouvé les personnes ayant implémenté cette atrocité de gérer le boot est donc de faire démarrer le cœur graphique en premier, ce dernier exécute un code propriétaire pour démarrer le cœur de calcul, qui a son tour lance le bootloader qui cherche le kernel etc...

Ce qui non seulement complique énormément le boot, non seulement ajoute du code propriétaire a un projet se disant libre, mais en plus n'est visiblement pas fait pour être utilisé de cette manière. Le hack, oui, mais uniquement quand c'est bien réalisé, sinon je dis non.

Enfin, le projet que j'avais est toujours en cours de réalisation. Je le terminerai dès que j'aurai récupéré les outils nécessaires pour monter mon alimentation personnalisée pour le Raspberry Pi. Et une fois que cela sera fait, ce Raspi restera une Piratebox pour le reste de sa vie. Les problèmes qu'il m'a posé, qu'il n'aurait pas du me poser, m'ont trop agacé pour que j'aie envie de le sortir et de jouer avec une fois sa mission remplie.

Dommage.

Juste une petite note pour annoncer le prochain article, consacré a la fabrication d'une PirateBox basée sur un Raspberry Pi. Voila, a bientôt sur le blog!

Les clients mails ont une particularité en commun : ils sont tous très mauvais. Cela pour nombre de raisons, mais la principale reste que leurs interfaces/raccourcis claviers ne sont pas efficaces pour une utilisation a la UNIX
Cependant, un d'entre eux se démarque par sa moins-mauvais-itude, c'est le relativement bien connu Outlook Express 2003 Mutt!
Mutt est un client mail en ligne de commande, qui, comme le dit sa page d’accueil, "just sucks less". Dans les faits, mutt est assez chiant a configurer mais particulièrement pratique a utiliser après.

La configuration de mutt se fait dans le fichier .muttrc ou dans /etc/Muttrc, et il est courant d'utiliser offlineimap en conjonction avec celui ci, de façon a accéder aux mails même sans accès internet (mutt dispose d'un système d'accès IMAP/POP et SMTP, mais ne crée pas de cache, ce qui empêche la consultation des emails sans connexion internet.) La configuration d'offlineimap se fait dans ~/.offlineimaprc ou dans rien d'autre en fait, c'est une config par user. Offlineimap est un petit logiciel en python qui synchronise un dossier en Maildir avec un serveur IMAP, ce qui tombe bien puisque justement mutt accepte les dossiers au format Maildir. (De plus, cela va tout a fait dans le sens de la libération des données en cela que vous possédez vos mails en local.)
Bref, passons aux choses serieuses : le code. Déjà, installez offlineimap et ce script fait par moi, qui vous permet d'installer mutt avec le patch sidebar, qui crée un listing des dossiers sur la partie gauche.
Ensuite, voyons pour la partie configuration :
Ma configuration d'offlineimap :

## Config file for offlineimap
## Originally located in ~/.offlineimaprc
## This should not be edited without creating a copy before
## Created by Wxcafe (Clément Hertling)
## Published under CC-BY-SA

[general]
# List of accounts to be synced, separated by a comma.
accounts = main

[Account main]
# Identifier for the local repository; e.g. the maildir to be synced via IMAP.
localrepository = main-local
# Identifier for the remote repository; i.e. the actual IMAP, usually non-local.
remoterepository = main-remote
# Status cache. Default is plain, which eventually becomes huge and slow.
status_backend = sqlite              # le type de cache. (plain ou sqlite)

[Repository main-local]
# Currently, offlineimap only supports maildir and IMAP for local repositories.
type = Maildir                        # le type de stockage (Maildir ou IMAP)
# Where should the mail be placed?
localfolders = ~/Emails/                # le dossier dans lequel vous
                                        # voulez que vos emails apparaissent

[Repository main-remote]
# Remote repos can be IMAP or Gmail, the latter being a preconfigured IMAP.
type = IMAP
remotehost = //placeholderhost//        # le serveur de votre messagerie
remoteuser = //placeholderusername//    # votre nom d'utilisateur
remotepass = //placeholderpassword//    # votre mot de passe
cert_fingerprint = //placeholdercert//  # le certificat du serveur (IMAPS only)

Ça devrait être assez simple a lire, j'ai tout bien commenté :3
Puis ma config mutt :

## Mutt MUA configuration file
## This file should not be edited without creating a copy
## File Created and edited by Wxcafe (Clément Hertling)
## Published under CC-BY-SA

# General config for reading (fetched via offlineimap)

set mbox_type = Maildir
# type de boite mail (voir dans offlineimap, mailbox par defaut)

set folder = ~/Email/
# dossier root mailbox/imap

set spoolfile = +INBOX
# dossier d'inbox

set mbox = +'All Mail'
# dossier ou archiver les emails

set copy = yes
# yes pour copier les messages dans les differents dossier, no pour...
# enfin voila quoi.

set header_cache = /.hcache/
# dossier ou sont stockés les headers (pour le cache)

set record = +Sent
# dossier dans lequel sont stockés les messages envoyés

set postponed = +Drafts
# dossier dans lequel sont stockés les brouillons

mailboxes = +INBOX +Drafts +Sent +Trash  +All\ Mail 
# liste des dossiers qui vont apparaitre dans la colonne de gauche

# General config for sending (using Mutt's native support)

set smtp_pass = 'password_placeholder'
# votre mot de passe

set smtp_url = "smtp://username@whatev.org:465/"
# l'url ou envoyer les emails

set send_charset = "utf-8"
# UTF8, NE PAS CHANGER

set signature = ".sign"
# vous pouvez mettre votre signature dans .sign

set sig_on_top = yes
# il est d'usge de mettre no ici. Cependant, je trouve ca plus lisible 
# comme ca.

set ssl_verify_host = no
# mettez yes ici si votre serveur a un certificat configuré correctement

set hostname = "wxcafe.net"
# mettez l'adresse de votre serveur ici

# Misc settings

auto_view text/html
# la façon de voir les emails par défaut.

set date_format = "%y-%m-%d %T"
# format de date d'envoi/de reception.

set index_format = "%2C | %Z [%D] %-30.30F (%-4.4c) %s"
# format de l'index (la présentation de l'interface)
# voir http://www.mutt.org/doc/manual/manual-6.html#index_format

set sort_alias = alias
set reverse_alias = yes 
set alias_file = "$HOME/.mutt/aliases"
# liste des alias noms/email. a créer et remplir vous même.
# format : "alias short_name long_email_adress"
source $alias_file

set beep = no
# ne pas biper. CE SON ME TUE T.T

set tilde = yes
set sleep_time = 0
# ?

set sidebar_visible = yes
set sidebar_width = 15
# parametres de la barre coté gauche

set realname = "Clément Hertling (Wxcafé)"
set from = "wxcafe@wxcafe.net"
set use_from = yes
set certificate_file = "$HOME/.mutt/cacert"
# parametres d'envoi. mettez vos propres infos a la place des miennes...

set edit_headers = yes
# vous permet de vois les headers des mails. j'aime, donc je laisse.

# Macros

# le titre dit tout. index veut dire que la macro est active dans les menus,
# pager qu'elle l'est dans la visionneuse, les deux qu'elle l'est dans les 
# deux
# \C represente la touche Control

bind index,pager \Cp sidebar-prev
# Control+p -> remonter d'un dossier dans la sidebar

bind index,pager \Cn sidebar-next
# Control+n -> descendre d'un dossier dans la sidebar

bind index,pager \Co sidebar-open
# Control+o -> ouvrir le dossier selectionné dans la sidebar

macro index,pager d "=Trash" "Trash"
# d supprime le message en cours

bind pager   previous-line
# permet de monter d'une ligne avec la touche up, au lieu de changer de message.

bind pager   next-line
# permet de descendre d'une ligne avec la touche down, au lieu de changer de 
# message

bind pager j next-line
bind pager k previous-line
# raccourcis vim

# PGP signing commands

set pgp_decode_command="gpg %?p?--passphrase-fd 0? --no-verbose --batch --output - %f"
set pgp_verify_command="gpg --no-verbose --batch --output - --verify %s %f"
set pgp_decrypt_command="gpg --passphrase-fd 0 --no-verbose --batch --output - %f"
set pgp_sign_command="gpg --no-verbose --batch --output - --passphrase-fd 0 --armor --detach-sign --textmode %?a?-u %a? %f"
set pgp_clearsign_command="gpg --no-verbose --batch --output - --passphrase-fd 0 --armor --textmode --clearsign %?a?-u %a? %f"
set pgp_encrypt_only_command="pgpewrap gpg --batch --quiet --no-verbose --output - --encrypt --textmode --armor --always-trust --encrypt-to 0x******** -- -r %r -- %f"
set pgp_encrypt_sign_command="pgpewrap gpg --passphrase-fd 0 --batch --quiet --no-verbose --textmode --output - --encrypt --sign %?a?-u %a? --armor --always-trust --encrypt-to 0x******** -- -r %r -- %f"
set pgp_import_command="gpg --no-verbose --import -v %f"
set pgp_export_command="gpg --no-verbose --export --armor %r"
set pgp_verify_key_command="gpg --no-verbose --batch --fingerprint --check-sigs %r"
set pgp_list_pubring_command="gpg --no-verbose --batch --with-colons --list-keys %r" 
set pgp_list_secring_command="gpg --no-verbose --batch --with-colons --list-secret-keys %r" 
set pgp_autosign=yes
set pgp_sign_as=0x********
# remplacez 0x******** par votre identifiant PGP!!!!!

set pgp_replyencrypt=no
set pgp_timeout=7200
set pgp_good_sign="^gpg: Good signature from"

# si vous ne comptez pas utiliser PGP, commentez toute cette section, depuis
# PGP signing options

# Palette for use with the Linux console.  Black background.

# Schéma de couleur Rouge et Noir. Commentez si vous voulez le 
# défaut noir et blanc.
# d'autres schémas sont trouvables sur google et autre.

color hdrdefault red black
color quoted brightblack black
color signature brightblack black
color attachment red black
color message brightwhite black
color error brightred black
color indicator black red
color status white black
color tree white black
color normal white black
color markers red black
color search white black
color tilde brightmagenta black
color index red black ~F
color index red black "~N|~O"

Voila, pour plus d'informations vous pouvez aller voir le manuel de mutt @ http://www.mutt.org/doc/manual/
J'espère que cette configuration "toute faite" vous aidera a commencer a utiliser mutt. Il est tout de fois important de se souvenir qu'utiliser une configuration toute faire n'aide pas a comprendre un programme ou un système, et que cette façon de faire devrait être réservée a l'introduction ou a des situations ou il est absolument nécessaire d'avoir rapidement une configuration fonctionnelle (c'est a dire, dans le cas d'un client email, euh... jamais?). Je vous invite donc a relire les annotations dont sont parsemés les fichiers de configuration en question, et surtout a lire le manuel, a chercher sur Bing Google Yahoo Seeks, et globalement a tenter de comprendre les configurations en question et a les améliorer!

Aujourd'hui, et depuis 1901 (j'ai révisé mon histoire récemment), il existe une loi dite de séparation des églises et de l'état, qui consiste a faire en sorte que l'état n'ait rien a voir avec les differentes églises, pour de sombres histoires d'indépendance et de laïcité. (principes qui sont aujourd'hui en voie de disparition, mais ce n'est pas le propos qui nous occupe ici). Cela dit, cette bonne idée politique, si elle a évité a ses auteurs de nombreux tracas, et leur a surement permis de conserver une tête en état de fonctionnement bien reliée a leur colonne vertébrale, ne vous interesse que moyennement, et vous voudriez retourner répondre a vos mails sur Gmail et micro-blogguer (quel mot horrible...) sur twitter?

Ça tombe bien, vous abordez justement le sujet véritable de cet article (non, mon blog n'est pas devenu un histoblog, désolé aux déçus...), a savoir la centralisation qui se met progressivement en place sur internet depuis quelques années : Twitter, Google, Facebook, Micro$oft, Apple, tous ces acteurs du web (et pas que, pour certains...) ont commencé a prendre pour manie de centraliser vos données : pour prendre un exemple simple, si vous utilisez Gmail (qui depuis quelque temps, lit aussi vos mails pour accorder la publicité, dites adieu a votre vie privée), vous avez un compte Google Talk, probablement aussi un Google+.

L'outil le plus pratique aujourd'hui pour aggreger des flux RSS est Google Reader, et vous l'utilisez aussi probablement. Votre téléphone est un android? Ah, un Nexus? Vous avez donc toutes les applications google installées, et Chrome mobile comme navigateur par défaut, qui est synchronisé avec la version qui tourne sur votre PC (via les serveurs de Google, bien sur). Depuis peu, les recherches sur le moteur de recherche sont elles aussi ajoutées a votre profil, enregistrées a jamais par Google (qui n'est pas touchée, en tant que société américaine, par la "loi des 10 ans" francaise.). Vous commencez a voir le truc? Non, ne jetez pas ce telephone, enfin! (je refuse de rembourser tout smartphone ayant été perdu a cause de cet article) J'ai pris ici comme exemple Google, parce que c'est celui qui propose le plus de services, mais Apple avec iCloud, iTunes et son iPhone fait pareil, tout comme M$ avec WP8 et Skydrive.

Twitter et Facebook n'ont de rôle dans ce sujet qu'en ce que vous leur fournissez des informations dont ils s'empressent de devenir seuls propriétaires (cf les Conditions d'Utilisation de ces deux services), puis de les revendre a des annonceurs faisant de la publicité ciblée. Le problème est simple a apprehender, vous ne voulez pas que l'un de ces services connaisse trop de choses sur vous (et ils recoupent très bien les informations venant de sources differentes), car il est évident qu'ils les vendent a des entreprises peu scrupuleuses quand a leurs engagements de confidentialité, quand a leurs securité aussi; mais surtout parce que depuis le 11 Septembre 2001 et le Patriot Act, toute entreprise américaine doitfournir toutes ses informations au gouvernement américain sans aucune intervention d'un juge, ou de quelque institution de controle que ce soit.

Ce qui est, comme vous pouvez le comprendre, relativement problématique. (pour ceux qui a ce point se disent "je n'ai rien a cacher, donc je m'en fous si le gouvernement américain sait tout de moi", je vous conseille d'aller lire cet article de Jean Marc Manach, plein de bon sens...) Pour éviter cela, vous avez plusieurs possibilités: utiliser des services concurrents pour tout (Facebook Mail, Skydrive, Twitter et Google Reader par exemple), tout en vous souvenant que comme ces entreprises sont toutes américaines, le gouvenrnement américain détient tout de même vos informations, et que ca lui prendra juste un peu plus de temps.

Vous pouvez aussi n'utiliser que des entreprises francaises, mais cela ne regle que le problème du Patriot Act, et pas celui de la revente de vos données. Et puis essayez de trouver un service équivalent a Google Reader et fourni par une entreprise française, on en reparlera. Non, la véritable alternative, c'est d'héberger vos services vous même, d'avoir votre propre serveur sur lequel vous possedez le plus de services possibles, et d'utiliser des concurents ou des services libres au maximum pour les autres, ceux qui ne sont pas distribuables (par exemple, les cartes sont difficiles a mettre en commun, or plusieurs alternatives existent: Google Maps, <troll>Apple Maps</troll>, Bing Maps, OpenStreetMaps, etc...). Beaucoup de ces services sont cependant très facilement décentralisables, surement parce qu'ils ont a la base étés conçus comme des services décentralisés. Ainsi les emails, le web, le chat (via XMPP) par exemple sont basés sur un système décentralisé.

De plus, votre serveur peut vous servir a beaucoup d'autres des choses que vous feriez habituellement sur votre ordinateur personnel: conserver une présence sur IRC, compiler du code, faire du rendu vidéo, etc... En bref, un serveur peut vous servir a effectuer toutes les opérations que vous effectuez sur votre ordinateur sans les inconvénients de la consommation éléctrique ni du bruit, mais vous permet aussi de ne dépendre aucunement d'une entreprise américaine, et cependant de disposer de tous les services utiles offerts par ces dernières.

Un serveur peut de plus vous permettre de controller parfaitement tous ces services, sans aucune limitation d'aucune sorte, voire de vous créer une page web. Bien entendu, il est bien plus utile d'avoir un serveur si vous avez aussi un nom de domaine. Heureusement, ils sont peu chers et souvent fournis avec le serveur.

Dans de prochains articles, je vous expliquerai comment louer puis configurer votre serveur pour qu'il serve de serveur mail (IMAP/SMTP), web, base de données, et proxy. Cela dit, comme c'est un serveur sous linux, vous pouvez l'utiliser pour a peu près n'importe quoi.
Voila, a bientôt!

PGP (pour pretty good privacy) est un système de chiffrement asymétrique (pour plus d'information sur le chiffrement asymétrique, voir ici) utilisant en général les algorithmes RSA et/ou DSA, et pouvant servir a chiffrer tout fichier, mais aussi a signer des emails. Le système de signature consiste a s'identifier en tant que la personne que l'on est, en certifiant de son identité, et repose sur un système dit de Web of Trust.

Ce concept de Web of Trust est simple: si je valide le code vous identifiant (votre clé), en certifiant que vous êtes qui vous êtes et que je vous connais, et que d'autres personnes m'ont déjà personnellement validé, les autres utilisateurs seront enclins a croire que vous êtes en effet la personne que vous prétendez être. Bien entendu, les utilisateurs validant trop de clés rapportées comme fausses voient la valeur de leurs signatures baissée, et toutes les clés signées par ces utilisateurs voient leur crédibilité baisser.
Inversement, les "bons utilisateurs" voient la valeur de leurs signatures augmentée, ce qui augmente la crédibilité des clés qu'ils ont signées.

Ceci dit, un email peut être a la fois signé et chiffré, de façon a être sûr, non seulement que l’expéditeur de l'email est bien celui qu'il dit être, mais aussi que l'email n'a pas été modifié entre l'envoi et la réception (en effet, avec un chiffrement de type RSA/DSA, une modification du corps de l'email rend ce dernier illisible, la clé publique ne  correspondant plus a la phrase de passe du message), ce qui offre bien évidemment des avantages non négligeables dans un environnement ou la protection des échanges est importante (soit a peu près partout sur internet, si vous tenez a votre vie privée. Pensez a quitter Gmail aussi, par exemple).

Il est cependant a noter que les clés publiques sont généralement situées sur un serveur de clés publiques, tel pgp.mit.edu ou encore subkeys.pgp.net (certaines personnes préfèrent garder leur clés hors des serveurs de clés publiques, craignant une compromission de ces serveurs. Dans le cas d'utilisateurs normaux (c'est a dire n'échangeant pas de secrets classés secret-défense par email), la protection offerte par les serveurs de clé publiques est suffisante)

L'une des implémentations les plus connues et utilisées de PGP est sans conteste GPG (GNU Privacy Guard) , qui comme son nom l'indique fait partie du projet GNU, et qui (<troll> de façon surprenante pour un programme GNU</troll>) est extrêmement efficace et claire.

Après ces explications techniques, voici venue le moment intéressant/utile, a savoir l'application. Le chiffrement et la signature de mails doivent cependant attendre un petit peu, étant donné qu'il vous faut d'abord créer votre clé et la placer sur un serveur de clés publiques, de façon à ce que votre destinataire puisse vous identifier lorsqu'il recevra le mail, mais aussi a configurer votre client mail pour utiliser gpg (je baserai les explications de cet article sur Thunderbird, mais des explications efficaces sont trouvables facilement sur les interwebs).

Tout d'abord, générons une clé GPG :

 gpg --gen-key

GPG va vous demander les méthodes de chiffrement que vous voulez utiliser, le plus sur est de laisser la valeur par défaut. La question suivante est de savoir quelle taille votre clé doit faire, il est préférable de choisir la taille la plus importante possible (4096). GPG veut ensuite savoir quand votre clé doit expirer. La méthode simple est bien évidemment de ne jamais la faire expirer, il est cependant plus intéressant dans une logique de sécurité de régler cette durée a six mois/un an.

Des informations personnelles vous sont ensuite demandées, concernant votre nom (mettez le vrai, tel qu'il apparaît sur votre carte d'identité, si vous souhaitez utiliser votre véritable identité), votre adresse mail (mettez la plus utilisée, vous pourrez en rajouter plus tard), et un mot de passe pour la clé (utilisez un mot de passe sécurisé!! Il est conseillé d'utiliser au moins 8 caractères, dont majuscules, minuscules, caractères spéciaux et nombres (vous pouvez utiliser la commande makepasswd, qui génère automatiquement un mot de passe)

GPG va maintenant prendre un peu de temps pour générer le couple clé publique/clé privée, vous devriez profiter de ce temps pour effectuer des opérations autres sur votre ordinateur : taper des textes, lancer des films, écouter de la musique... De façon à augmenter les chances d'obtenir un nombre bien aléatoire (le générateur d'aléatoire se base sur la RAM pour obtenir des bits au hasard)

Une fois cela fini, vous obtenez un couple clé publique/clé privée, que vous ne pouvez pas visualiser entièrement pour l'instant. Il est cependant possible (et recommandé) de les exporter pour les sauvegarder via une commande:

gpg --armor --export --output=pubkey.gpg

pour la clé publique, et

gpg --armor --export-secret-keys --output=seckey.gpg

pour la clé privée. Il est possible et même souhaitable de copier ces clés sur une clé USB, une carte SD, ou un autre support de stockage résistant, de façon a avoir une solution de sauvegarde, au cas ou vous perdiez ces clés sur ce PC.

Cela fait, listons les informations sur votre clé publique :

$ gpg --list-keys --fingerprint
pub     4096R/27D81AC8 2012-11-17
    Key fingerprint = 6345 A91A FF89 97E0 13D0 96A9 9E2A 1917 27D8 1AC8
uid             Clément Hertling (Wxcafe) 
uid             [jpeg image of size 14692]
sub     4096R/9ED7F77F 2012-11-17

La partie pub indique que c'est une clé publique, 4096R indique que c'est une clé RSA sur 4096 bits. La partie 27D81AC8 est l'identifiant de la clé publique, Key fingerprint = 6345 A91A FF89 97E0 13D0 96A9 9E2A 1917 27D8 1AC8 est appelé fingerprint de la clé. Les champs uid sont des manières d'identifier la clé et la personne associée a celle-ci, et enfin le champ sub est indicateur d'une subkey, système uniquement pris en charge par GPG et non inclus dans les premières versions de PGP, donc non-implémentées dans nombre de clients pgp.
Passons maintenant a la mise en place de cette clé publique sur un serveur de clés : nous utiliserons ici le serveur pgp.mit.edu.

gpg --keyserver pgp.mit.edu --send-keys *ID de la clé a uploader*

Maintenant que votre clé publique a été uploadée, vous pouvez l'utiliser pour signer et chiffrer vos emails!
Installons donc l'extension Enigmail pour Thunderbird, permettant de chiffrer/signer vos emails de façon transparente. Il conviendra de paramétrer cette extension, via le menu OpenPGP dans Thunderbird, puis Setup Wizard (l'option entre Help et About OpenPGP). Normalement, Enigmail détecte votre installation de gpg automatiquement, si cependant ce n'était pas le cas, vous pouvez utiliser la clé exportée tout a l'heure (pubkey.gpg) en l'important (import key from file).

Selon les options que vous avez utilisées, vos emails seront automatiquement signés et/ou chiffrés a l'envoi. Gardez cependant a l'esprit que si tout le monde peut lire les mails signés, il n'en est pas de même pour les mails chiffrés, pour lesquels il est nécessaire de posséder la clé publique du correspondant en question, et de posséder soi même une clé privée, donc d'utiliser OpenPGP aussi.
Concernant les signatures de clés, elles fonctionnent de manière très simple :
Vous devez télécharger la clé de votre correspondant, via un

 gpg --keyserver pgp.mit.edu --search-keys *ID de la clé de votre correspondant*

(a noter que cette commande fonctionne aussi en cherchant une adresse email ou un nom. Cependant, en cherchant via l'identifiant de la clé, vous êtes sur de trouver votre correspondant. Globalement, l'email est lui aussi assez sûr en terme de recherche de clés, tandis que le nom donne rarement un résultat). L'étape suivante est de vérifier que votre correspondant est bien la personne qui est spécifiée sur sa clé. Pour cela, il convient d'avoir déjà vu physiquement cette personne et si possible d'avoir vu une pièce d'identité lui appartenant, et d'avoir une confirmation de cette personne que la clé que vous voyez lui appartient bien.
Ceci fait, vous pouvez signer la clé via un

 gpg --sign *ID de la clé a signer*

puis la renvoyer au serveur via

 gpg --keyserver pgp.mit.edu --send-key *ID de la clé a signer*

Voila, la clé de votre correspondant est signée!

Ce tutoriel sur PGP/GPG est terminé, et votre sécurité est améliorée grâce a cette superbe invention qu'est la cryptographie!

Après avoir lu cet article paru sur écrans.fr, et au vu des nombreuses réflexions que j'ai eu sur ce sujet au cours des années, je commence a me demander si la réponse logique ne serait pas d'enseigner les bases de l'informatique (bases d’électronique, de programmation et de logique formelle) dès le collège.

En effet, l'exemple qui me revient toujours est celui des technoprêtres de warhammer 40 000, dans un univers ou la technologie est ritualisée et incomprise même des plus savants, qui se contentent de reproduire ce qui existe, et parfois par chance de retrouver un schéma explicatif lisible par une machine, et qu'ils ne comprennent pas eux mêmes, ou toute technologie est ointe d'onguents sacrés, entourée d'encens avant d'être péniblement actionnée par des assistants ne comprenant rien a cette technologie (ayant lu Hackers - Heroes of the Computer Revolution de Steven Levy, c'est l'ambiance que l'on retrouve quand l'auteur décrit l'ambiance près des machines IBM au MIT, au début de l'ouvrage), et il me semble que de plus en plus la société se rapproche de cela.

Cette culture de l’ingénierie, qui existait beaucoup lors des débuts de l'informatique (telle que décrite par exemple par Steve Wozniak dans son livre iWoz) disparait pour laisser place a une culture de la consommation et de l'utilisation de contenus existants, et même a une certaine peur de la compréhension de la technologie. Ceux qui s'y intéressent sont considérés comme marginaux (combien de hackers créent des outils sur lesquels seront construits tous les systèmes du siècle a venir, tels des Dennis Ritchie en puissance? Combien d'entre eux ne sont pas intégrés a la société dite "normale"?), et on peut souvent observer les réactions de peur que lancent les actions des hackers, ne serait-ce que dans les journaux (combien de journaux 'mainstream' ont-ils parlés des hackers en bien, c'est a dire tels qu'ils sont réellement, depuis les années 80?) ou a la télévision.

Ainsi, la culture et la connaissance de ces appareils que sont les ordinateurs, qui aujourd'hui se trouvent du fond de nos poches a dans l'espace en passant par l’intérieur des pacemakers jusqu’à être une composante indispensable de la société, se perdent et rendent ainsi la compréhension de ces appareils impossible (j'ai eu la désagréable surprise récemment de voir un camarade de classe me poser ingénument la question "Ah, mais en fait, quand tu installes Linux, ça change le fond d'écran et les icônes?". Au-delà du niveau, la misère de cette question est que cette personne n'avait probablement aucune idée de la façon dont fonctionnait son ordinateur, a part pour le fond d'écran en question et pour les fameuses icônes.) pour le grand public, et cet évolution crée de fait une sorte d'oligarchie de techno-comprenants, seuls capables de manier et de créer la technologie.

C'est pour cela qu'il me semble intéressant, important, peut être même requis, d'inclure au programme du collège puis du lycée des cours d’électronique et d'informatique tels que décrits plus haut, de façon a ce que les élèves comprennent le monde qui les entoure. Car c'est la le but du cycle scolaire secondaire, me semble-t-il, et non pas de former des futurs travailleurs. Sinon, pourquoi y aurait-il des cours de musique, d'arts plastiques, ou encore de philosophie? Si le but du cycle secondaire est bien d'ouvrir l'esprit des élèves sur le monde et sur ce qui les entoure, alors les cours sur l'informatique s'imposent comme une évidence, puisque ceux-ci nous entourent aujourd'hui bien plus que quoi que soit d'autre...

Ces cours seraient susceptibles de s’insérer en un mélange entre des cours de technologie (qui aujourd'hui sont bien plus orientés physique et machines-outils qu'informatique ou électronique, alors que la technologie d'aujourd'hui et vraisemblablement de demain aussi est l'informatique) et de physique, pour le côté électronique, et de façon a donner enfin aux cours de physique un intérêt quelconque, sortir au delà de la théorie et de l'abstraction complète que sont actuellement ces cours et passer un peu dans la réalisation, avec des arduinos par exemple.

Vous aussi, intéressez vous a cela, de façon a ce que les jeunes ne finissent pas par ne rien comprendre a ce qui est aujourd'hui l'une des composante les plus importantes du monde tel qu'il est programmé.

Archlinux est réputée être une distribution Linux très complexe a installer et a maintenir.

Je vais tenter ici de vous convaincre que ce n'est pas le cas, et qu'elle peut se monter très intéressante et très instructive a installer tout autant qu'a utiliser.

Il convient tout d'abord de rappeler a quels principes obéit Arch:

1. Le KISS : Keep It Simple and Stupid, Archlinux tente de faire des programmes simples et utilisables par tous. Avec comme base de simplicité les utilisateurs de LFS... Mais il n'empêche qu'avec un peu de bonne volonté, la configuration n'est pas si compliquée!

2. La philosophie UNIX : chaque programme est prévu pour ne remplir qu'une seule tâche. Bien entendu, cela ne concerne que les programmes conçus pour s’insérer dans la philosophie UNIX, et les installations de dépendances avec le gestionnaire de paquet d'Arch fonctionnent superbement bien.

De plus, posons les bases d'Arch : le gestionnaire de paquets s'appelle pacman, et les commandes de base sont :

• recherche d'un paquet :

  pacman -Ss paquet
  

• installation d'un paquet :

  sudo pacman -S paquet
  

• désinstallation d'un paquet :

  sudo pacman -R paquet
  

• mise a jour de tous les paquets installés :

  sudo pacman -Syu paquet
  

Archlinux est une distribution dite "rolling release", ce qui signifie qu'il n'y a pas de version a proprement dites, et que les paquets se mettent a jour en permanence, sans jamais changer la "version" d'Arch. Il n'y a d'ailleurs qu'une seule version de l'installeur sur le site, puisqu'une version plus ancienne n'aurait aucun sens.

Arch n'offre pas d'interface graphique par défaut : après avoir installé le système, vous n'aurez qu'une invite de commande. Heureusement, je vais ici vous guider a travers l'installation d'une interface graphique (mate, le fork de gnome 2)

L'installation d'Arch se fait par le réseau, veillez a avoir une connection WiFi ou filaire a proximité avant de suivre ce guide.

Ce guide utilise SystemV, alors qu'Arch va prochainement passer sous systemd. N'ayant pas encore eu le temps d’expérimenter assez avec ce dernier, je ferais un tutoriel pour passer votre Arch a systemd bientôt.

Bon, passons a l'explication de l'installation proprement dite :

Tout d'abord, téléchargeons l'iso d'arch la plus récente :

wget http://mir.archlinux.fr/iso/2012.09.07/archlinux-2012.09.07-dual.iso

Ensuite, gravons cette image sur un disque USB :

dd if=archlinux-2012.09.07-dual.iso of=/dev/sdX

Après reboot de la machine sur l'iso en question et choix de l'architecture, nous sommes accueillis par un shell root.

La première chose a faire est de paramétrer le clavier :

loadkeys fr

Puis nous pouvons passer a l'installation proprement dite. Partitionnement :

cfdisk # cfdisk est suffisamment clair pour ne pas nécessiter d'explications

formatage des partitions :

mkfs.ext4 /dev/sda1 # partition root

pacman -Syu btrfs-progs && mkfs.btrfs /dev/sda2 # partition home

mkswap /dev/sda3 && swapon /dev/sda3 # partition de swap

Montons les partitions nouvellement créées, puis installons le système :

mount /dev/sda1 /mnt

mkdir /mnt/home && mount /dev/sda2 /mnt/home

dhclient eth0 # si vous utilisez une connection filaire, sinon voire http://wiki.archlinux.fr/Wifi#Configuration

pacstrap /mnt base base-devel

genfstab -p /mnt > /mnt/etc/fstab

Allons prendre un café le temps que ça charge, puis installons les quelques paquets nécessaires a notre installation et au premier démarrage:

pacstrap /mnt syslinux btrfs-progs wireless_tools dhclient

Maintenant, passons sur notre install toute fraîche d'Arch :

arch-chroot /mnt bash

configurons les bases :

echo HOSTNAME > /etc/hostname

ln -s /usr/share/zoneinfo/Europe/Paris /etc/localtime

date MMJJhhmmAAAA

hwclock --systohc

vim /etc/locale.gen # Décommentez les lignes correspondant au français : fr_FR.UTF-8 et fr_FR.ISO-8859-1

echo  'LANG="fr_FR.UTF-8"' > /etc/locale.conf

locale-gen

mkinitcpio -p linux

Enfin, vérifions que syslinux est correctement configuré :

vim /boot/syslinux/syslinux.cfg # il devrait y avoir "append root=/dev/sda1"

Si tout est correct, installons syslinux, et paramétrons un mot de passe root :

syslinux-install_update /dev/sda -mia

passwd root

Et voila, l'installation est terminée! Plus qu'a quitter la session et a redémarrer l'ordinateur!

 exit
umount /mnt/home 
umount /mnt
reboot

Fini!

Prenons une petite pause. La partie suivante de ce tutoriel consister en un paramétrage des principaux services nécessaires a l'utilisation d'un OS, disons, moyen :

• Installation de MATE, le gestionnaire de bureau (voir http://mate-desktop.org/)

• Installation de sudo et de networkmanager pour faire fonctionner les composants essentiels du système sans avoir a tout activer a la main a chaque démarrage

• Installation de SLiM comme gestionnaire de login graphique, pour présenter une interface plus accueillante que la console, et configuration de celui-ci

• Installation des principaux logiciels utiles non inclus dans mate ni base (yaourt, chromium, thunderbird, etc...).

Ce guide est bien sur optionnel, si vous souhaitez utiliser Arch avec un gestionnaire de bureau autre que mate, ou sans, vous pouvez vous arrêter ici.

Bon, reprenons.

Nous sommes donc sur une demande de mot de passe. Entrez donc le mot de passe paramétré plus haut pour le root, puis retapez la commande utilisée plus tôt pour vous connecter a internet.

Il convient d'ajouter le dépôt de MATE pour installer ce dernier, puis d'effectuer l'action en question :

vim /etc/pacman.conf

Ici, ajoutez les lignes suivantes :

[mate]
Server = http://repo.mate-desktop.org/archlinux/$arch

Installons maintenant les paquets :

pacman -Syu mate mate-extras dbus dbus-core alsa networkmanager sudo

Ajoutons un compte utilisateur pour utiliser les composants du système sans tout crasher a chaque fois :

useradd -g users -G wheel,audio,optical,lp,scanner,log,power,floppy,storage,games,video -m -s /bin/bash *votrenom*
passwd *votrenom*
su *votrenom*

Il faut maintenant éditer le fichier \~/.xinitrc pour préciser a X.org ce que l'on veut utiliser :

echo "exec ck-launch-session mate-session" > ~/.xinitrc

Profitons en pour ajouter les démons système au lancement :

vim /etc/rc.conf

Ajoutez donc dbus, alsa. hwclock et networkmanager dans la section DAEMONS (entre les parenthèses, après crond normalement)

DAEMONS=(syslog-ng network crond dbus alsa hwclock networkmanager)

Pour éviter un reboot, il est ici possible de faire un

su

Puis un

 /etc/rc.d/dbus start && /etc/rc.d/alsa start && /etc/rc.d/networkmanager start

Sinon, il est possible de juste redémarrer.
Une fois cela fait, profitez de ce moment pour vous autoriser vous même a utiliser sudo. Loggez vous en root, et :

 vim /etc/sudoers

Décommentez la ligne qui commence par # %wheel ALL=(ALL)
Sauvegardez le fichier, puis, après un su *votrenom*, tentez de faire un sudo ls /
Normalement, vous devriez avoir un listing du dossier /
Bon, maintenant, pourquoi ne pas tenter de lancer MATE?
C'est simple comme bonjour :

 startx

Et PAF! Voila un MATE desktop flambant neuf a configurer!
Avant de faire ça, retournez sur un TTY (CTRL+ALT+Fx), loggez vous, puis installez SLiM (sudo pacman -Syu slim).
Configurons le:

echo "exec dbus-launch mate-session" > ~/.xinitrc && vim /etc/slim.conf

Éditez la ligne "sessions xfce4,icewm-session,wmaker,blackbox" de facon a ce qu'elle ressemble a "sessions mate-session"
Puis ajoutez slim dans /etc/rc.conf, dans la section DAEMONS.
Normalement, tout devrait fonctionner!
Ah oui, et pour installer thunderbird, firefox, chromium, etc...

sudo pacman -Syu chromium thunderbird xchat firefox rhythmbox pidgin transmission-gtk vlc

Voila! Et comme dirait @Spartition, c'est sale, mais qu'est-ce que c'est bon!
A plus~

Un système de fichiers. Vous en avez surement déjà entendu parlé si vous avec déjà installé Linux, ou formaté une clé USB. Dans ces cas, vous connaissez surement NTFS, EXT4, ou encore FAT32.

Ces différents noms désignent en effet des systèmes de fichiers. Mais qu'est-ce qu'un système de fichiers?

Pour comprendre cela, il faut déjà savoir ce qu'est exactement un fichier. Un fichier est un ensemble de blocs (les blocs sont l'unité la plus petite traitable par le matériel, ils font généralement 1 ou 4 Kio (kibioctet), en fonction du système de fichier utilisé.), qui est donc composé de bits, interprétés différemment en fonction du type de fichier. Cependant, seul, le fichier n'est pas accessible, puisqu'il n'est pas indexé, c'est a dire que l'OS ne sait pas qu'il est présent, ou il commence ni où il s'arrête (je schématise un peu, mais c'est l'idée).

Ainsi, le système de fichier donne un cadre et un standard à l'arborescence des fichiers. Par exemple, le système de fichier ext4 utilise des blocs de 1 Kio, et de ce fait, toutes les partitions de disque dur formatées en ext4 peuvent prendre comme unité de base 1 Kio et mesurer la taille des fichiers en blocs de cette façon. Les systèmes de fichiers nécessitent l'inclusion de drivers dans le noyau pour pouvoir être pris en compte.

Le noyau linux inclut par défaut les drivers pour ext2/3/4, btrfs, reiserfs, ntfs, fat16/32 et hfsx, ce qui permet de monter a peu près tout type de partition récente.

Il convient de bien faire la différence entre le système de fichier et l'arborescence des fichiers. Si l'arborescence des fichiers est en fait une entité virtuelle englobant la racine / et tous les fichiers et dossiers contenus dedans, le système de fichier permet a votre système GNU/Linux de distinguer les différents fichiers composants cette arborescence.

Détaillons maintenant les types de fichiers les plus répandus:

• FAT16/32 : Les systèmes de fichier FAT (pour File Allocation Table, soit la définition d'un système de fichier), remplissent leur rôle le plus simplement possible. Ne permettant (historiquement) que des noms de 8 caractères (plus extension de trois caractères), ni chiffrement, ni système de distinction d'utilisateurs (DOS étant un système mono-utilisateur), Il fut décliné par microsoft en FAT16 et en FAT32, utlisants respectivement des blocs de 16 et 32 Kio.

• NTFS :. Le NTFS (pour New Technology File System, rapport a Windows NT) est un système de fichier qui est apparu avec Windows XP, et qui était une mise a jour nécessaire du FAT32 vieillissant. NTFS ajoute a FAT différentes capacités dont le chiffrement, les liens symboliques, la compression et les quotas pour les volumes, permettant de limiter la taille maximum occupée dans une partition.

• ReFS : ReFS est le système de fichiers introduit dans Windows Server 2012. Ne différant pas énormément de NTFS, je le mentionne principalement parce qu'il est prévu qu'il soit le défaut pour Windows 8. Il apporte principalement la redondance, c'est a dire que chaque fichier possède une somme de contrôle en 64 bits stockée dans un fichier séparé pour éviter les corruption de disque.

• Ext2/3/4 : les systèmes ext (extended) sont les systèmes de fichiers les plus utilisés sous linux pour le grand public. (Je traiterai ici d'ext4, puisque c'est le plus récent.) Il dispose de toutes les fonctions que l'on peut attendre d'un système de fichiers moderne, ni plus ni moins. Ainsi, ext4 est un système de fichiers journalisé, acceptant les capacités jusqu’à 1 Exioctet, et utilise l'allocation dite "par extent", ce qui signifie que la création d'un fichier réserve automatiquement les zones contiguës de façon a réduire la fragmentation.

• ReiserFS : ce système de fichiers, créé par le (légèrement mégalo) programmeur Hans Reiser, est a retenir pour avoir été le premier système de fichiers journalisé, et accepte un nombre de fichiers de l'ordre des 4 milliards. Le but de ce système est de créer un système polyvalent, a la fois système de fichiers et base de donnée (de part sa grande capacité en terme de nombre de fichiers et de l'utilisation d'un journal.)

• Btrfs : ce système est l'évolution logique d'ext4, et inclut lui aussi l'allocation par extent, mais possède de plus un système de sous-volumes, qui permet d’accéder a plusieurs arborescences de fichiers montées en même temps (système pratique et utile pour faire des snapshots de systèmes.). Il permet aussi de redimensionner a chaud la taille des partitions, en les agrandissant ou en les rétrécissant, est compatible avec LVM, a un système de checking intégré (btrfsck), et utilise un algorithme de compression appelé LZ4, qui accélère les accès aux fichiers compressés d'environ 30% par rapport a LZO, le système utilisé dans ext4.

• HFS+ : le système de fichier présent sur tous les macs a des capacités relativement standards, et ressemble énormément a l'ext3. Il supporte cependant les liens directs vers les dossiers, fonction rare sur les systèmes de fichiers actuels. Il est possible qu'il évolue a nouveau dans les années a venir

• ZFS : Ce système de fichier, venu de Solaris mais utilisable par Linux et *BSD, est, tel Btrfs, a la fois un système de fichier et un remplaçant/compatible avec LVM, C'est un système de fichiers conçu principalement pour les serveurs, et il intègre ainsi un système de redondance des données pour éviter les corruptions, un mode RAID-Z (apparenté au RAID5), des checks d’intégrité en continu, des snapshots, etc...

Comme on a pu le voir, les systèmes de fichiers disponibles sont légions. Cependant, le plus adapté a Linux et a une utilisation grand public aujourd'hui est probablement Btrfs. Malheureusement, ce dernier n'est pas aujourd'hui proposé par défaut sur les distributions les plus utilisées, au profit de l'ext4, qui commence a accuser son âge...

Les systèmes de fichiers, s'ils peuvent ne pas sembler primordiaux au fonctionnement du système, sont en fait de première importance, et ce choix ne devrait pas être laissé au hasard, et être mis a jour régulièrement (pour éviter les failles de sécurité...)

Bon courage, et bon choix pour votre prochain système.