Wxcafé

OpenSMTPd comme serveur mail sous debian

2014-11-07T13:04:00+01:00

J'avais dit il y a un certain temps que j'allais écrire un tutoriel expliquant comment gérer ses mails soi-même. Il se trouve que j'ai récemment décidé de changer le serveur qui héberge (entre autres) ce blog, et que ce dernier héberge aussi mes emails. J'ai donc totalement changé d'infrastructure quand a la gestion de mon système de mails.

Ainsi, j'ai décidé de passer de Postfix a OpenSMTPd, changement que je voulais effectuer depuis un certain temps. OpenSMTPd est un projet originaire d'OpenBSD qui a pour but de fournir un serveur SMTP fiable, simple, rapide, et surtout sécurisé (les même buts que ceux qu'a le projet OpenBSD, globalement).

Pour rappel, le système d'emails fonctionne d'une façon très simple : votre MUA (Mail User Agent, ou client email) contacte le MTA (Mail Transport Agent, ou serveur SMTP) de votre fournisseur email, qui contacte le MTA du fournisseur du destinataire, qui lui même contacte le MDA (Mail Delivery Agent) qui délivre le mail au destinataire.

Si vous avez bien suivi, vous pouvez voir que je n'ai pas parlé de récupération ni de lecture des mails. C'est pour une raison simple, qui est que ces taches sont remplies par d'autres services encore (IMAP/POP pour la récupération depuis le serveur, des yeux pour la lecture).

Or ce qui nous intéresse ici, ce n'est pas simplement d'envoyer et de recevoir des emails mais bien aussi de pouvoir les récupérer et les lire, et c'est pour ça que ce tutoriel ne parlera pas que d'OpenSMTPd mais aussi de Dovecot qui fait office de serveur IMAP et amavis/spamassassin pour filtrer les mails entrants et sortants. Le schéma suivant explique la façon dont les mails sont gérés sur le système

            ╭────────────────╮                    ╭──────────╮
            │╭──────────────>│────> to filter ───>│─╮        │
  mail in   ││               │                    │ │ amavis │
───────────>│╯ OpenSMTPd  ╭──│<─── from filter<───│<╯        │
            │             │  │                    ╰──────────╯
  mail out  │             │  │                    ╭──────────╮
<───────────│<────────────┴─>│─────> to MDA ─────>│─────────>│──> to user's
            │                │                    │ dovecot  │     mailbox
            ╰────────────────╯                    ╰──────────╯

Normalement, ceci devrait être a peu près clair. Pour expliquer vite fait, les emails entrants (venant des utilisateurs mais aussi d'autres correspondants) sont transmis a OpenSMTPd, qui envoie tout a amavis, qui vérifie a la fois les spams et les malwares pour les mails venants de l'exterieur, et qui signe avec DKIM pour les mails venants de nos utilisateurs, puis qui rentransmet les mails filtrés/signés a OpenSMTPd, qui a ce moment-ci trie en fonction de la destination : les mails gérés par le domaine vont via dovecot dans les boites mail des destinataires locaux, les mails exterieurs vont directement vers le MTA du serveur distant.

Voyons comment mettre cela en place. Tout d'abord, il faut décider de la façon dont les différents services vont communiquer.

Déjà, amavis étant configuré par défaut pour écouter (en SMTP) sur le port 10024 et répondre sur le port 10025 quand il s'agit de filtrer et écouter sur le port 10026 et répondre sur le port 10027 quand il s'agit de signer, nous allons profiter de cette configuration et donc lui parler en SMTP sur ces ports.

Quand a Dovecot, nous allons lui transmettre les emails en LMTP (Local Mail Transfer Protocol), non pas sur un port mais via un socket (dans ce cas précis, /var/run/dovecot/lmtp).

Ainsi, pour reprendre le schéma présenté plus haut :

            ╭───────────────╮                    ╭───────────╮
            │╭─────────────>│──> SMTP (10026) ──>│─╮         │
  SMTP in   ││              │                    │ │ amavis  │
────────> 25│╯ OpenSMTPd ╭──│<── SMTP (10027) <──│<╯ (sign)  │
            │            │  │                    ╰───────────╯
  SMTP out  │            │  │
25 <────────│<───────────╯  │
            ╰───────────────╯

Pour les mails sortants; et

            ╭───────────────╮                    ╭────────────╮
            │╭─────────────>│──> SMTP (10024) ──>│─╮          │
  SMTP in   ││              │                    │ │ amavis   │
────────> 25│╯ OpenSMTPd ╭──│<── SMTP (10025) <──│<╯(filter)  │
            │            │  │                    ╰────────────╯
            │            │  │                    ╭────────────╮
            │            ╰─>│──> LMTP (socket) ─>│───────────>│──> to user's
            │               │                    │  dovecot   │     mailbox
            ╰───────────────╯                    ╰────────────╯

Pour les mails entrants.

Maintenant que la théorie est claire, mettons en place tout cela. Je me baserai ici sur le fait que vous utilisiez une plateforme Debian ou OpenBSD. Pour d'autres plateformes, la configuration devrait être sensiblement la même

(Vous aurez besoin de certificats SSL pour ce guide, même self-signés. Si vous ne savez pas comment en créer, vous pouvez aller voir ce post)

Tout d'abord, commençons par installer les programmes nécessaires :

sudo apt-get install opensmtpd dovecot dovecot-pigeonhole amavisd-new dovecot-managesieved
sudo pkg_add dovecot dovecot-pigeonhole amavisd-new

Continuons en configurant OpenSMTPd tel que nous avons vu plus haut :

/etc/smtpd.conf

# This is the smtpd server system-wide configuration file.
# See smtpd.conf(5) for more information.

## Certs
pki exem.pl certificate "/etc/certs/exem.pl.crt"
pki exem.pl key         "/etc/certs/exem.pl.key"

## Ports to listen on, and how to listen on them
listen on eth0 port 25 tls pki exem.pl hostname exem.pl auth-optional
listen on eth0 port 465 tls-require pki exem.pl hostname exem.pl auth mask-source
listen on eth0 port 587 tls-require pki exem.pl hostname exem.pl auth mask-source

## Aliases
table aliases file:/etc/aliases

# coming from amavisd, checked for spam/malware
listen on lo port 10025 tag Filtered
# coming from amavisd, signed with DKIM
listen on lo port 10027 tag Signed

## Receiving
# if the (incoming) mail has been through amavisd, then we can deliver it
accept tagged Filtered for any alias <aliases> deliver to lmtp "/var/run/dovecot/lmtp"
# we directly tranfer incoming mail to amavisd to be checked 
accept from any for domain "exem.pl" relay via "smtp://localhost:10024"
# we have to put these lines in this order to avoid infinite loops

## Sending
# if the (outgoint) mail has been through amavisd, then we can deliver it
accept tagged Signed for any relay
# we tranfer the outgoing mail to amavisd to be signed
accept for any relay via "smtp://localhost:10026"
# same, we have to put these lines in this order or infinite loops...

Expliquons un peu ce fichier de configuration :

Tout d'abord, le paragraphe nommé "Certs" contient les déclaration d'emplacement des certificats SSL.
Ensuite, le paragraphe contenant les ports externes sur lesquels nous écoutons : port 25 avec TLS optionel et ports 465 et 587 avec TLS obligatoire
Les alias sont définis juste après
Le paragraphe suivant contient les ports locaux sur lesquels nous écoutons : 10025 (port de sortie du filtre de amavis) dont on taggue les mails sortants comme "Filtered" et 10027 (port de sortie des mails signés par amavis) dont on taggue les mails sortants comme "Signed"
Nous avons ensuite le paragraphe qui traite les mails rentrants. Si le mail traité est taggué comme Filtered, alors il a été vérifié par amavis, et on peut donc le transmettre au destinataire. Sinon, c'est qu'il n'a pas encore été vérifié par amavis, donc on lui transmet pour analyse (sur le port 10024 donc). Il est important de mettre les déclarations dans ce sens, car la première règle qui matche l'état du paquet est appliquée. Ici, la deuxième ligne matchant tous les mails arrivant et la première seulement ceux filtrés, inverser leur sens voudrait dire que les mails seraient toujours renvoyés a amavis
Enfin, le dernier paragraphe traite les mails sortants. De la même façon que pour le paragraphe précédent, si le mail sortant est déjà taggué comme Signed on le transmet au MTA du destinataire, sinon il n'a pas encore été signé par DKIM par amavis et on le transmet donc a amavis pour qu'il le signe. Le problème de l'ordre des lignes se pose encore, pour la même raison qu'au dessus.

Nous allons maintenant configurer dovecot. Comme nous l'avons vu, dovecot doit écouter en LMTP via la socket /var/run/dovecot/lmtp et transmettre les emails a la boite email de l'utilisateur. Il serait aussi interessant qu'il nous permette de récuperer les mails. Pour cette configuration, on ne mettra en place que du IMAPS. Cependant, si vous voulez mettre en place du POP3[s], différents guides sont trouvables facilement sur internet.

/etc/dovecot/dovecot.conf

## Dovecot configuration file

# basic config
info_log_path = /var/log/dovecot-info.log
log_path = /var/log/dovecot.log
log_timestamp = "%Y-%m-%d %H:%M:%S "
mail_location = maildir:%h/mail

# authentication
passdb {
    driver = pam
}
userdb {
    driver = passwd
}

# the protocols we use
protocols = imap lmtp sieve

# ssl config
ssl_cert = </etc/certs/exem.pl.cert
ssl_key = </etc/certs/exem.pl.key
ssl_cipher_list = HIGH+kEDH:HIGH+kEECDH:HIGH:!PSK:!SRP:!3DES:!aNULL
ssl = yes

## configuring services 
# disables imap login without SSL (yes dovecot is dumb that way)
service imap-login {
    inet_listener imap {
        port=0 
    }
}

service lmtp {
    unix_listener lmtp {
        mode = 0666
    }
}

## configuring protocols
# the dovecot lda, we set it to use sieve
protocol lda {
    mail_plugins = $mail_plugins sieve
}

protocol lmtp {
    postmaster_address =  whoever@exem.pl
    mail_plugins = $mail_plugins sieve
}

plugin {
    sieve = ~/.dovecot.sieve
    sieve_dir = ~/sieve
}

ATTENTION: Sous OpenBSD, remplacez

passdb {
    driver = pam
}

par

passdb {
    driver = bsdauth
}

pour identifier les utilisateurs système

Ici aussi, voyons comment ce fichier est structuré :

Tout d'abord, les configurations de base : ou iront les logs, comment formater leur datation, et l'endroit ou seront stockés les mails des utilisateurs.
Nous configurons ensuite la gestion de l'authentification des utilisateurs. Ici nous identifions les utilisateurs avec le fichier /etc/passwd et leurs mots de passe avec PAM (ou BSDAuth)
Nous configurons ensuite les protocoles que nous servons. Ici, nous voulons de l'IMAPS, du LMTP local et Sieve (qui sert pour trier les messages).
Nous configurons le SSL
Le section suivante contient la configuration des services. Nous avons en premier lieu le service IMAP, dont la configuration sert uniquement a désactiver IMAP. En effet, dovecot ne permet d'activer IMAPS qu'en activant IMAP avec. Comme nous ne voulons pas d'IMAP sans SSL, nous le désactivons. La configuration de lmtp sert a attribuer des permissions plus correctes au fifo qu'il utilise
Nous configurons maintenant les protocoles, pour faire fonctionner Sieve
enfin, nous configurons le plugin sieve en lui indiquant quel fichier et quel dossier utiliser pour sa configuration.

Enfin, il nous reste a configurer amavis. Comme expliqué, amavis va nous servir a deux choses : signer les emails sortants, et filtrer les emails entrants. Il doit donc écouter sur les port 10026 pour les signatures et 10024 pour le filtrage, et répondre respectivement sur les ports 10027 et 10025 (le tout, en SMTP. Comme toutes les transactions se font sur le loopback, il n'y a aucun risque a utiliser des protocoles non chiffrés. Pour OpenBSD, pensez a copier la configuration par défaut depuis /usr/local/share/examples/amavisd-new/amavisd.conf et ajoutez les modifications nécessaires a la fin du fichier.

/etc/amavis/conf.d/99-local.conf (debian) /etc/amavis.conf (OpenBSD)

use strict;

$enable_dkim_verification = 1;
$enable_dkim_signing = 1;
dkim_key("exem.pl", "main", "/etc/certs/dkim.key" );

@dkim_signature_options_bysender_maps = (
    { '.' =>
        { ttl => 21*24*3600, c => 'relaxed/simple' }
    }
);

$inet_socket_port = [10024, 10026];
$policy_bank{'MYNETS'} = {
        originating => 1,
        os_fingerprint_method => undef,
};

$interface_policy{'10026'} = 'ORIGINATING';

$policy_bank{'ORIGINATING'} = {
        originating => 1,
        allow_disclaimers => 1,
        virus_admin_maps => ["root\@$mydomain"],
        spam_admin_maps => ["root\@$mydomain"],
        warnbadhsender => 1,
        forward_method => 'smtp:localhost:10027',
        smtpd_discard_ehlo_keywords => ['8BITMIME'],
        bypass_banned_checks_maps => [1],
        terminate_dsn_on_notify_success => 0,
};

#------------ Do not modify anything below this line -------------
1;  # ensure a defined return

A nouveau, expliquons ce fichier : - le premier paragraphe définit que nous voulons qu'amavis signe les emails sortants, vérifie la signature DKIM des emails rentrants, et l'endroit ou se trouve la clé privée servant a signer les emails. - le second définit les options DKIM que nous souhaitons utiliser comme défaut. Je vous invite a consulter la RFC 4871 - nous définissons ensuite les ports sur lesquels nous allons écouter, puis les paramètres que nous utiliserons pour les emails venant de nos utilisateurs : ils seront traités comme "originating" et nous ne vérifierons pas l'OS duquel ils viennent. - nous savons que les emails venants du port 10026 sont sortants, nous les traitons donc comme tel - le paragraphe suivant décrit le traitement que nous faisons subir aux emails sortants : tout d'abord, nous réaffirmons qu'ils viennent bien de notre serveur. Nous autorisons les disclaimers (voire encore une fois la RFC 4871. Nous déclarons l'adresse a prévenir en cas de spam/virus venants de notre système, et que nous voulons être prévenus. Nous déclarons ou envoyer les mails une fois signés et filtrés, puis qu'il est nécessaire de convertir les emails au format 7 bits avant de les envoyer au MTA, que nous autorisons tous les types et noms de fichiers, et les notifications de succès d'envoi. Et voila!

Vous avez pu remarquer qu'a aucun moment nous ne configurions ni la signature des emails sortants ni le filtrage des emails entrants. Ces paramètres sont en fait inclus par défaut dans amavis.

Il nous reste cependant quelques opérations a faire, encore. Tout d'abord, il nous faut générer notre clé DKIM. Pour cela, il existe différentes méthodes, j'ai personnellement utilisé opendkim (un tutorial) mais de nombreuses autre méthodes existent. Il nous reste encore a configurer spamassassin :

#rewrite_header Subject *****SPAM*****
# report_safe 1
required_score 2.0
# use_bayes 1
# bayes_auto_learn 1
# bayes_ignore_header X-Bogosity
# bayes_ignore_header X-Spam-Flag
# bayes_ignore_header X-Spam-Status
ifplugin Mail::SpamAssassin::Plugin::Shortcircuit
# shortcircuit USER_IN_WHITELIST       on
# shortcircuit USER_IN_DEF_WHITELIST   on
# shortcircuit USER_IN_ALL_SPAM_TO     on
# shortcircuit SUBJECT_IN_WHITELIST    on
# shortcircuit USER_IN_BLACKLIST       on
# shortcircuit USER_IN_BLACKLIST_TO    on
# shortcircuit SUBJECT_IN_BLACKLIST    on
shortcircuit ALL_TRUSTED             off
# shortcircuit BAYES_99                spam
# shortcircuit BAYES_00                ham

endif # Mail::SpamAssassin::Plugin::Shortcircuit

Comme vous pouvez le voir, les modifications se résument globalement a baisser le required_score pour ma part.

Pour finir, activez les services nécessaires : opensmtpd, dovecot, amavisd, et spamassassin, et tout devrait fonctionner parfaitement

Bon courage pour votre hosting de mail ensuite...

Installer FreeBSD sur un serveur Online avec MfsBSD

2014-08-28T12:16:00+02:00

J'ai récemment eu l'occasion de louer un serveur chez Online.net (filiale de Illiad) Voulant depuis pas mal de temps gérer un serveur sous FreeBSD (et tester bhyve) et n'ayant pour différentes raisons pas eu l'occasion de le faire sur mon serveur auto-hebergé ni sur ce serveur ci, j'ai commencé a chercher comment le faire sur ce serveur.

Étant donné que Online ne propose pas directement d'image FreeBSD sur ses serveurs, il m'a fallu chercher un peu plus loin. Il se trouve que ce post sur les forums d'online explique une procédure, mais celle-ci ne fonctionnait pas pour mon serveur en particulier.

J'ai donc cherché un peu sur internet, puis demandé sur irc (#freebsd-fr@freenode), ou l'on m'a dirigé vers mfsbsd, un projet d'installeur alternatif, minimaliste et simplifié pour FreeBSD.

Pour installer FreeBSD sur votre serveur, donc, il vous faudra accéder a une console KVM (dans mon cas personnel, iLO). Cela doit être faisable depuis le panel Online. Une fois cela fait, lancez une console, puis téléchargez l'image mfsbsd. Dans la console iLO, choisissez de booter sur une image CD/DVD, puis choisissez l'image mfsbsd. Ensuite, rebootez le serveur. Choisissez de booter sur l'image CD/DVD (F11 puis 1). Une fois ceci fait, un FreeBSD a l'air tout a fait classique va démarrer. Une fois ceci fait, la partie importante arrive: mfsbsd contient un script d'installation root-on-zfs, nommé logiquement zfsinstall, qui va se charger de tout le travail pour nous.

Utilisez donc ce script ainsi :

# tout d'abord, wipons le MBR :
dd < /dev/zero > /dev/da0 count=1
# maintenant, installons le système
zfsinstall -g da0 -u ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/10.0-RELEASE/ -s 2G -p root -c

Avec -g da0 votre disque dur principal, -s 2G la quantité de swap désirée, -p root le nom du zpool, et -c pour activer la compression. D'autres options sont disponibles, je vous invite a faire un zfsinstall -h si mon setup ne vous convient pas.

Une fois ceci fait, faites un chroot dans /mnt (ou doit se trouver le nouveau système) et éditez /etc/rc.conf :

zfs_load="YES"
sshd_load="YES
hostname="whatever"
ifconfig_igb0="DHCP"

Remplacez whatever par votre hostname, et igb0 par le nom de votre interface physique connectée a internet. Quittez le chroot, rebootez, et voila, vous avez maintenant un système FreeBSD tout propre installé sur zfs a découvrir et utiliser!

Voila, c'est la fin de ce tutoriel. (Cela dit, bon courage pour tester bhyve, vu que l'IPv6 chez online est... peu crédible, disons)

Bon sinon sur d'autres sujets, j'ai mis en place des bots twitter wxcafe_ebooks, petitefanfare, capet_ebooks, zengisse, et kim_ebooks. Ils sont tous basés sur ce code, qui vient de @m1sp (github.com/twitter_ebooks). Donc voila.

A plus

SSL ou la sécurité sur l'internet

2014-05-30T08:25:00+02:00

Disclaimer: Ce billet est écrit après le visionnage de la conférence de Moxie Marlinspike suivante: More Tricks for Defeating SSL, présentée a la DefCon 17 (en 2011), et la lecture du billet suivant: A Critique of Lavabit, ce qui peut avoir l'effet de rendre légèrement parano. Si vous considérez que c'est le cas ici, veuillez ne pas tenir compte de ce billet (et vous pouvez dès a présent dire coucou aux différentes personnes qui écoutent votre connection)

Si vous venez ici souvent (vous devriez), et que vous utilisez SSL pour vous connecter a ce site (vous devriez, vraiment, dans ce cas), vous avez peut être remarqué quelque chose récemment : il se trouve que le certificat qui permet de desservir ce site a changé.

Cela fait suite aux évènements évoqués dans le Disclaimer, mais aussi a des doigts sortis d'un endroit particulier du corps de l'admin/auteur de ce "blog", qui a pris enfin les 5 minutes nécessaires a la compréhension superficielle du fonctionnement de SSL, et les 10 nécessaires a la mise en place d'un système fonctionnel utilisant cette compréhension récemment acquise.

Bref, le certificat a changé. Mais de quelle façon, vous demandez vous peut être (ou pas, mais bon, je vais expliquer de toute façon). Et bien c'est très simple : il existait auparavant un certificat pour wxcafe.net, un pour paste.wxcafe.net, un pour mail.wxcafe.net, etc... Bref, un certificat différent pour chaque sous-domaine.

Il s'avère que c'est a la fois très peu pratique a utiliser (les utilisateurs doivent ajouter chaque certificat a leur navigateur séparément, chaque changement de sous-domaine conduit a un message d'erreur, etc) et pas plus sécurisé que d'avoir un seul certificat wildcard. J'ai donc généré un certificat pour *.wxcafe.net hier, et il sera dorénavant utilisé pour tous les sous-domaine de wxcafe.net; et un certificat pour wxcafe.net, qui ne matche pas *.wxcafe.net, et qui sera donc utilisé... bah pour wxcafe.net.

Il serait préférable de faire des redirections automatiques des adresses http vers les adresses https, cependant, étant donné que le certificat est self-signed, il me semble préférable que l'arrivée sur le site ne commence pas par une page firefox disant "Something's Wrong!", et ces redirections ne seront donc pas mises en place.

De plus, après la lecture de l'article de blog sur Lavabit dont le lien est plus haut, il semble intéressant (et assez important) de faire en sorte que le serveur utilise en priorité (et si possible, uniquement) des ciphers supportant PFS, soit EDH et EECDH (Ephemeral Diffie-Helmann et la version Elliptic Curves de ce même algorithme). Cela permet de faire en sorte que toutes les communications avec ce serveur soient future-proof, c'est a dire que, même si quelqu'un récupérait la clé privée, elle ne serait pas utile pour déchiffrer les communications passées.

Bon, maintenant que les explications basiques sont faites, voyons l'implémentation :
Pour générer la clé, tout d'abord, il convient d'utiliser les commandes suivantes:

sudo openssl genrsa -out example.key 4096
# nous utilisons ici une clé de 4096 bits, la taille est laissée a votre appréciation
sudo openssl req -new -key example.key -out example.csr
# OpenSSL va ici vous demander de nombreuses informations, "Common Name" devant contenir le FQDN
sudo openssl X509 -req -days 1095 -in example.csr -signkey example.key -out example.crt
# enfin, nous générons la clé, d'une durée de vie de 3 ans

Bien entendu, si vous voulez utiliser une clé wildcard, il vous faut préciser *.example.com comme common name. Une fois la clé générée, il faut dire aux différents services de l'utiliser, et de n'utiliser que des ciphers PFS. La méthode dépend donc du service. Je vais lister ici les methodes pour quelques services que j'utilise :

apache :

# /etc/apache2/mods_enabled/ssl.conf
# [...]
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
  EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \
  EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"
# [...]
# /etc/apache2/sites-enabled/default-ssl
# [...]
SSLEngine on
SSLCertificateFile /etc/certs/example.com.crt
SSLCertificateKeyFile /etc/certs/example.com.key
# [...]

nginx :

# /etc/nginx/nginx.conf 
# [...]
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
  EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \
  EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";
# [...]
# /etc/nginx/sites-enabled/default-ssl
# [...]
ssl on;
ssl_certificate /etc/certs/example.com.crt
ssl_certificate_key /etc/certs/example.com.key
# [...]

prosody (jabber) :

# tout d'abord, lancez la commande suivante :
sudo openssl dhparam -out /etc/prosody/certs/dh-2048.pem 2048
# ensuite, pour chaque VirtualHost dans /etc/prosody/prosody.conf :
ssl = {
  dhparam = "/etc/prosody/certs/dh-2048.pem";
  key = "/etc/certs/example.com.key";
  certificate = "/etc/certs/example.com.crt";
}
# la cipher suite de prosody utilise par défaut EDH et EECDH

postfix (email) :

# /etc/postfix/main.cf
# [...]
smtpd_tls_cert_file = /etc/certs/example.com.crt
smtpd_tls_key_file = /etc/certs/example.com.key
tls_preempt_cipherlist = yes
smtpd_tls_eecdh_grade = strong
smtdp_tls_mandatory_ciphers = high
smtpd_tls_mandatory_exclude_ciphers = aNULL, eNULL, MD5, LOW, 3DES, EXP, PSK, SRP, DSS
smtpd_tls_security_level = encrypt
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_use_tls = yes
# [...]

dovecot (imap) :

# /etc/dovecot/dovecot.conf 
# [...]
ssl_cert = </etc/certs/example.com.crt
ssl_key = </etc/certs/example.com.key
ssl_cipher_list = HIGH+kEDH:HIGH+kEECDH:HIGH:!PSK:!SRP:!3DES:!aNULL

Voila. Pour d'autres protocoles/services, je vous invite a RTFM^W vous reporter au manuel approprié.

Cela étant dit, je conseille a tout le monde d'aller voir la conférence dans le disclaimer, et tant qu'a faire la conférence du même hacker SSL and the future of Authenticity qui parle de son implémentation d'une technologie "remplaçant" le système de CAs qui existe actuellement.

Mise en place d'un serveur DNS

2014-02-24T02:49:00+01:00

Le DNS (Domain Name System) est le service permettant la résolution des noms de domaines en différentes informations : adresses IPv4, adresses IPv6, certificats DNSSEC ou IPsec, localisation géographique, ou encore texte. En général, le DNS est utilisé pour résoudre des noms de domaines en adresses IP, et ainsi pour simplifier la vie de tous les utilisateurs (je doute que tout le monde retienne de se connecter a http://173.194.45.66, ou a http://199.16.156.70. Voire même a http://5.39.76.46).

Cependant, le DNS est un système qui date de 1984, et les exigences de l'époque en termes d'expérience utilisateur n'étaient pas forcément aussi importantes que de nos jours. La configuration des serveurs DNS peut ainsi être assez contre intuitive. Cela étant dit, comprendre le fonctionnement de DNS et contrôler ses enregistrements est important.

Tout d'abord, une petite explication théorique. Le DNS fonctionne de la même façon que le système de fichiers : en arborescence. Cependant, là ou la racine du FS est /, celle de DNS est ., et là ou il convient d'écrire, par exemple, /usr/ et ou la progression se fait de gauche a droite pour le FS, pour DNS le . n'est pas obligatoire et la progression se fait de droite a gauche. Par exemple, le tld(top level domain, domaine de haut niveau) com, et le domaine google.com appartient a com, on écrit donc google.com sans écrire le point a la fin de façon courante.

Le reverse DNS est une variante du DNS "classique" permettant de résoudre les adresses IP en nom de domaine. Ainsi, 5.39.46.76 a pour domaine wxcafe.net. Cependant, le reverse DNS n'a, par définition, pas de TLD sur lequel se diriger quand on lui adresse une query. Les "adresses" que l'on query en reverse DNS sont donc constituées de l'adresse IP, dans le sens contraire a l'ordre habituel, et du faux domaine .in-addr.arpa Par exemple, pour connaitre le reverse de 5.39.46.76, il faudra faire dig PTR 76.46.39.5.in-addr.arpa. La réponse sera, évidemment, wxcafe.net

Voyons maintenant comment mettre en place son propre serveur DNS. Tout d'abord, quelques informations. DNS fonctionne sur le port 53 en UDP, et la commande utilisée pour faire des tests DNS est dig. Le DNS fonctionne avec des "enregistrements", records en anglais. Par exemple, un record A indique une adresse IP, un record NS indique un Serveur de nom, etc. dig se base sur ces records : par défaut, il ira chercher le(s) record(s) A correspondant(s) au nom de domaine que vous donnez en argument, mais en précisant un autre type de record, vous pouvez obtenir n'importe quelle information : par exemple, dig NS wxcafe.net devrait vous renvoyer

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> NS wxcafe.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13846
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;wxcafe.net.            IN  NS

;; ANSWER SECTION:
wxcafe.net.     3600    IN  NS  ns.wxcafe.net.
wxcafe.net.     3600    IN  NS  ns.home.wxcafe.net.

;; Query time: 60 msec
;; SERVER: 10.0.42.1#53(10.0.42.1)
;; WHEN: Tue Dec 10 13:31:18 2013
;; MSG SIZE  rcvd: 67

Comme vous pouvez le voir, les serveurs DNS principaux pour wxcafe.net sont ns.wxcafe.net et ns.home.wxcafe.net, qui sont respectivement des alias pour wxcafe.net et home.wxcafe.net. Ainsi, chacun fait autorité pour lui même, et le problème évident est que le résolveur ne peut résoudre la query si il est renvoyé encore et encore vers le même serveur. Il convient donc de définir dans le même fichier de configuration l'adresse de ces deux serveurs. Ainsi, le résolveur, au bout de son deuxième loop, se rendra compte qu'il est en train de faire une boucle infinie et demandera l'adresse au serveur auquel il est connecté. La première indication de direction se fait grâce au serveur du TLD.

La configuration de bind est assez simple dans le principe, le plus complexe étant en fait d'écrire les fichiers de zone. La configuration de bind sous debian se fait dans le dossier /etc/bind/. Il existe 4 fichiers de configuration principaux : named.conf, named.conf.default-zones, named.conf.local et named.conf.options. named.conf contient les options par défaut de bind, named.conf.default-zones les déclarations des zones par défaut (auxquelles il vaut mieux ne pas toucher), named.conf.local contient les déclarations de vos zones, et named.conf.options contient les options que vous rajoutez pour changer le comportement de bind.

Pour commencer, il convient de préciser que nous allons parler ici du cas dans lequel se trouve wxcafe.net: deux domaines dont nous voulons faire l'autorité, deux serveurs DNS, et un service de résolution récursive limitée a quelques IPs (notamment mon accès chez moi).

Examinons tout d'abord les fichiers de configuration de named. named.conf.local contient les définitions des zones forward et reverse. Sur wxcafe.net, les zones wxcafe.net et 76.46.39.5.in-addr.arpa sont gérées en master, et les zones home.wxcafe.net et 103.177.67.80.in-addr.arpa sont gérées en slave. Nous n'examinerons ici que les déclarations de zones sur ce serveur, et pas sur home., car elles sont sensiblement les mêmes. La différence principale étant que l'un héberge en slave les masters de l'autre. Le fichier named.conf.local sur wxcafe.net contient donc

zone "wxcafe.net" {
    type master;
    file "/etc/bind/master/wxcafe.net";
    allow-transfer {
        80.67.177.103;
    };
};

zone "home.wxcafe.net" {
    type slave;
    file "/etc/bind/slave/home.wxcafe.net";
    masters {
        80.67.177.103;
    };
};

zone "46.76.39.5.in-addr.arpa" {
    type master;
    file "/etc/bind/master/46.76.39.5.in-addr.arpa";
    allow-transfer {
        80.67.177.103;
    };
};

zone "103.177.67.80.in-addr.arpa" {
    type slave;
    file "/etc/bind/slave/103.177.67.80.in-addr.arpa";
    masters {
        80.67.177.103;
    };
};

Cela devrait être relativement clair. Globalement, les zones master ont un fichier dans /etc/bind/master/, et les slaves un fichier dans /etc/bind/slave/, les masters autorisent le transfert vers home.wxcafe.net tandis que les slaves déclarent home.wxcafe.net comme master, et le reste est assez parlant.

Voyons maintenant le fichier de zone concernant wxcafe.net, soit /etc/bind/master/wxcafe.net :

$TTL 3600    ; 1 hour
@               IN SOA ns.wxcafe.net. wxcafe.wxcafe.net. (
                        2014011001  ; serial
                        3h          ; refresh  
                        1h          ; retry
                        168h        ; expire
                        300         ; negative response ttl
                        )

; Name servers
                IN  NS      ns.wxcafe.net.
                IN  NS      ns.home.wxcafe.net.

; Mail exchangers
                IN  MX  10  wxcafe.net.
                IN  SPF "v=spf1 ip4:5.39.76.46 a -all"

; Main A/AAAA records
                IN  A       5.39.76.46
ns              IN  A       5.39.76.46

; Aliases
data            IN  CNAME   wxcafe.net.
;        [...]
www             IN  CNAME   wxcafe.net.


; home.wxcafe.net. definition
$ORIGIN home.wxcafe.net.
@               IN  NS      ns.home.wxcafe.net.
                IN  NS      ns.wxcafe.net.
ns              IN  A       80.67.177.103
                IN  A       80.67.177.103

Alors. Expliquons ligne par ligne.
Tout d'abord, le TTL (time to live) est un paramètre définissant le temps pendant lequel les serveurs récursif (qui font un cache des données) doivent cacher ce fichier de zone.
Le @ est un raccourci pour exprimer le nom de domaine courant. Ici, donc, wxcafe.net.
Maintenant, nous arrivons a un record important : SOA (Start of Authority). Ce record prend de nombreux arguments, dans l'ordre :
- Le nameserver autoritaire pour le nom de domaine en question,
- L'adresse email du responsable de cette zone, avec le premier point remplacé par un @,

puis entre parenthèses :
- Le numéro de série ("version" du fichier de zone, ici au format YYYYMMDDNN)
- La période de refresh, période entre chaque mise a jour du nameserver authoritaire secondaire,
- La période de retry, le temps entre chaque essai de mise a jour si le nameserveur authoritaire primaire est indisponible,
- La période d'expire, le temps qu'attendra le serveur autoritaire secondaire avant de supprimer les informations de son cache si le primaire reste indisponible, et enfin
- La période de TTL négatif, le temps qu'attendra le serveur secondaire avant de ne plus offrir les informations de cette zone si le serveur primaire est injoignable.

Bon, tout ceci est peut-être un peu confus, mais ce n'est pas le record le plus important a lire (pour les humains en tout cas). Continuons :

NS (nameserver) permet de désigner les différents nameservers faisant autorité pour ce domaine.

MX permet d'indiquer ou il convient d'envoyer les emails pour ce domaine. SPF est un record d'authentification pour les emails. Les records A désignent l'association entre un nom de domaine et une adresse IPv4. Les records AAAA font de même pour les IPv6, mais malheureusement ce site n'est pas encore en IPv6.

Les CNAME (canonical name) sont en quelque sorte des alias, ils permettent de mettre en place des domaines exactement semblables a d'autre (ce qui permet par exemple de filtrer ensuite avec les Virtual Hosts d'Apache, pour le web)

Enfin, la partie qui suit commence avec une déclaration $ORIGIN, ce qui permet de changer la valeur du @ et des noms de domaine non complets (qui ne se terminent pas avec un .). Ainsi, la partie suivant définit les nameservers et l'adresse IP principale de home.wxcafe.net et de ns.home.wxcafe.net. Comme on l'a vu, étant donné que ce nom de domaine est géré par un autre serveur DNS, cela permet de rediriger les requêtes nous parvenant et demandant un domaine se trouvant sous home.wxcafe.net.

Les autres fichiers de zone sont sensiblement similaires, avec les quelques différences n'étant en fin de compte que des différences de valeurs (dues au fait que, eh bah, c'est pas les mêmes domaines...).

Voila donc une courte explication de ce qu'est le DNS. Bien entendu, tout n'est pas expliqué ici, je ne suis passé que sur ce qui est en place au niveau de wxcafe.net, et encore, rapidement. Si vous voulez en savoir plus, vous pouvez aller vous renseigner directement a la source : le RFC 1034 et le RFC 1035. Dans un autre style (bien plus avancé) le blog de Stéphane Bortzmeyer est interessant aussi.

NAT

2014-02-17T05:02:00+01:00

NAT (Network Address Translation) in a word?
It's complicated. Very. Don't do it, you'd damage your brain.

Bon, sinon, prochain article serieux vite, bisous.

Plan9 from whichever space

2013-09-09T11:17:00+02:00

Plan 9 from Outer Space est un film de série Z, produit en 1959 par Edward D. Wood. Il est assez connu comme étant l'un des pires films jamais sortis. Rempli d'erreur de montage, d'effets spéciaux au rabais, et ayant même connu la mort d'un acteur, il a ainsi atteint le statut de film culte grâce a sa médiocrité.

Plan 9 from Bell Labs est un OS venant de Bell Labs (comme son nom l'indique), et qui a été pensé comme le successeur d'Unix. Il est conçu comme une poursuite des concepts unixiens jusqu'à leur but naturel. Ainsi, c'est Plan9 qui a introduit le concept d'UnionFS, le protocole 9P qui permet d'acceder a des ressources appartenant a d'autres ordinateurs a distance, un support de l'unicode par défaut et sur tout le système (a l'inverse d'Unix, qui fonctionne a la base en ASCII), un support de ProcFS amélioré, une interface graphique par défaut, et d'autres améliorations sur les thèmes de base que propose Unix.

Cependant, Plan9 n'a jamais été véritablement utilisé pour quoi que ce soit d'autre que la recherche en systèmes, et c'est dommage, parce que Plan9 a quelque chose de très intéressant à proposer. En effet, en ces jours d'intérêt grandissant pour le klaoude et la délocalisation a la fois du processing et des données, et bien que Plan9 ait été créé bien avant que le terme "cloud computing" n'apparaisse pour la première fois, il semble que ce système ait été conçu pour apporter cette délocalisation tant rêvée.

En effet, même si l'on considère que les nouveautés qu'il apporte par rapport a Unix ne sont pas extraordinaires en soit (alors qu'elles sont déjà conséquentes), lorsqu'on les prend ensemble, elles font de Plan9 le système d'exploitation ultime en terme de partage de ressources et de données. Ainsi, le fait que 9P permette de considérer toutes les ressources d'un système distant comme n'étant qu'une poignée de fichiers permet de le monter comme n'importe quel système de fichier. Le fait que chaque utilisateur puisse accéder a plusieurs namespaces de façon transparente (et donc de démarrer, arrêter et gérer des processus sur chacun de ces namespaces) et que chaque namespace puisse interagir avec les autres, même s'ils sont hétérogènes (c'est a dire provenant de machines différentes), permet d'utiliser les ressources d'une machine distante comme si elle était présente localement. Le mécanisme d'UnionFS permet de rendre tout ça utilisable, en montant plusieurs systèmes de fichiers sur le même point de montage, en même temps, et de pouvoir ainsi accéder aux fichiers de plusieurs machines a la fois (ce qui permet une délocalisation des données bien plus poussée que Dropbox ou Google Drive, et ce en kernelspace).

Le réseau fait donc partie intégrante de Plan9, et il devient plus difficile de parler d'ordinateur lorsque le concept même du système est d'être composé de clusters eux mêmes composés de machines hétérogènes. Le système de fichier virtuel /net fourni par le kernel de Plan9 permet d'implémenter très facilement différents concepts réseaux : en montant le /net d'un ordinateur du réseau local sur celui servant de gateway vers l'internet, on crée un NAT vers cet ordinateur du réseau local. En montant le /net d'un ordinateur distant sur un ordinateur local via le protocole 9P sécurisé, on crée un VPN : les connections locales se font en utilisant l'accès de l'ordinateur distant, et les connections entre les deux sont chiffrées.

Bref, bien avant les clusters de Raspberry Pi qui utilisent une api python pour partager leur "puissance" de calcul en userspace, des superordinateurs pour lesquels le noyau Linux s'est doté du support de jusqu'à 4096 CPUs, des OS tels JoliOS qui promettent une integration du klaoude alors qu'ils ne sont en fait que des navigateurs web a peine améliorés et des services de stockage en ligne qui promettent un accès universel a toutes nos données alors qu'ils ne proposent que de les garder a disposition par le web, Plan9 promettait une technologie de partage des ressources système et de données, une intégration du réseau dans le système particulièrement poussée, un environnement graphique supporté par le basesystem et non greffé par dessus comme l'a été X11, et de nombreuses autres améliorations sur Unix.

Malheureusement, il n'a jamais été adopté de façon véritablement significative, et ce pour une raison très Unixiènne : "worse is better". En effet, le parc de machines Unix déjà installées était suffisamment performant et fonctionnel pour que des solutions soient développées au dessus du système pour remplir les mêmes fonctions que remplit Plan9 via son kernel, tels le nouveau ProcFS de Linux, FUSE, etc...

Sed Basics

2013-08-18T22:57:00+02:00

sed est un outil Unix très largement utilisé et très pratique pour manipuler le texte (ce qui se montre relativement indispensable dans un environnement Unix, puisque ce système est assez porté sur le texte). Cependant, il assez peu connu en détail, et la plupart du temps une seule fonction est utilisée : le remplacement de texte.
Or sed a bien plus de possibilités que ça, comme nous allons le voir.

Tout d'abord, rappelons les bases : sed est un programme Unix de base, mais aussi un langage de manipulation de texte dérivé de ed, l'éditeur original. ed est un éditeur de ligne, conçu a l'époque ou les ordinateurs n'étaient pas personnels et étaient utilisés avec des téléscripteurs, c'est a dire des machines dépourvues d'écrans et ne permettant donc pas l'utilisation d'éditeurs dits "visuels", tels que vim, emacs, et globalement tous les éditeurs ayant un curseur et affichant plusieurs lignes. sed est donc une évolution de ed, le s signifiant stream, sed est un éditeur de flux, prenant donc avantage du concept Unixien de flux de données (voir Flux standards) pour éditer plus d'une ligne a la fois. En pratique, sed est principalement utilisé sur des fichiers.

sed a quelques options pratique, notamment -s qui permet d'empêcher l'affichage systématique des lignes traitées, ou bien -i (pour GNU sed) qui permet de rediriger l'output dans le fichier d'input. Cela dit, l'intérêt unique du programme est son langage de manipulation de texte.

ed, et donc sed, utilise un langage basé sur les séparations (en général des /). Ainsi, la commande de base dans sed est

/[regex]/

qui permet de ne sélectionner que les lignes qui matchent [regex] (et donc de n'exécuter les commandes qui suivent que sur ces lignes.)

La commande sed la plus utilisée est bien entendu le s, qui s'utilise de la façon suivante :

s/[old text]/[new text]/[options]

qui se propose donc de remplacer (substitute) [old text] (qui peut être une regex) par [new text] (qui doit être un texte fixe, avec quelques exceptions), en appliquant [options], la plus connue des options étant g, qui permet d'appliquer la commande affectée a toutes les occurrences du texte matché sur la/les lignes concernée-s.
Les exceptions a la "fixité" de [new text] sont particulièrement intéressantes. En effet, sed utilise un langage de regex plutôt standard, excepté le fait qu'il permet jusqu'à 9 "holding spaces", qui sont délimités par $ et $, et qui sont représentées dans le texte de remplacement par \1 à \9.

Par exemple, la commande

sed 's/\(hello world\) world/\1/'

sur le texte "hello world world" renverrait comme résultat

hello world

De la même façon, le symbole & dans le texte de remplacement représente le texte original. Ainsi, la commande

sed 's/hello world/& world/'

sur le texte "hello world" renverrait comme résultat

hello world world

Une autre commande utile est p, qui sert a afficher le texte présent dans l'espace courant :

/[regex]/p

sed stocke en effet la ligne sur laquelle il travaille dans un espace mémoire dédié, que j'appelle l'espace courant (pattern space en anglais). La commande p affiche (print) ce qui ce trouve dans cet espace. La /[regex]/ réduit le pattern space de façon a ce qu'il ne contienne que les lignes matchant, et le p affiche donc ce dernier.

Un autre exemple de commande sont c, i et a, qui s'utilisent ainsi :

c \
[text]

De la même façon, pour le i :

i \
[text]

Et de même pour a.

Ces trois commandes s'utilisent de la même façon pour la bonne raison qu'elles sont très proches. i sert a insérer du texte avant le pattern space. a sert a insérer du texte après le pattern space, et enfin c sert a remplacer tout le pattern space. Les trois utilisent [text] comme remplacement ou insert. Attention, les insertions se font sur la ligne précédant ou suivant le pattern space, et non sur la ligne en question.

Enfin, dernière commande ne fonctionnant que ligne par ligne, d : /[regex]/d d (delete) supprime les contenus du pattern space.

sed est un outil puissant, mais complexe. Dans un prochain article, je parlerai des commandes multilignes et des labels.

Le chiffrement de partitions avec dm-crypt et device-mapper

2013-07-10T03:18:00+02:00

Le chiffrement en tant que concept informatique est traditionnellement associé au chiffrement de fichiers, c'est a dire au fait de passer d'un fichier en clair a un fichier chiffré dit cyphertext. Cependant, il ne se limite pas a ça, et peut aussi servir a garantir l'intégrité d'un système d'exploitation, ou bien la confidentialité d'un support de stockage, par exemple. Nous allons ici voir comment mettre en place un système de ce type sous GNU/Linux. Cet article n'a pas pour but de vous apprendre a mettre en place un système basé sur une procédure de boot sécurisée, mais plutôt d'expliquer les concepts qui entrent en jeu dans l'utilisation du sous-système du noyau Linux dm_crypt et de présenter un rapide tutoriel concernant la création d'un support chiffré sur lequel garder vos informations confidentielles (par exemple, votre clé GPG)

dm-crypt est un sous-système de device-mapper, qui est lui-même un sous-système du noyau Linux, et s'appuie sur LUKS, un standard de chiffrement de disques. Comme son nom l'indique, device-mapper est un système qui a pour but de mapper des block devices. Pour être plus clair, le kernel considère comme "block device" tout fichier spécial (en gros, les fichiers disques dans /dev/, les systèmes de fichiers type LVM, les RAID logiciels, et, dans le cas qui nous intéresse, les systèmes de fichier chiffrés). Son mode de fonctionnement est simple : a partir d'un "fichier de périphérique" (trad. Wikipédia), il en "crée" un nouveau, virtuel, ayant des propriétés différentes. Par exemple, un disque partitionné via LVM apparaîtra comme un seul disque dans /dev, et device-mapper est requis pour pouvoir en voir les partitions (qui apparaîtront donc dans /dev/mapper)

Ainsi, dans le cas qui nous intéresse ici, device-mapper prend un système de fichier chiffré, crée un périphérique virtuel non chiffré dans /dev/mapper, et déchiffre a la volée tous les accès disques a ce périphérique non chiffré en les traduisant sur le système de fichier chiffré, le tout de manière tout a fait transparente pour les applications utilisant le disque en question. Cela induit bien entendu une baisse de performance relativement significative dans le cas d'un chiffrement du système de fichier root, mais quasiment insignifiante dans le cas de chiffrement de partitions de données.

D'ailleurs, certain-e-s se demandent peut-être comment le système peut démarrer si le système de fichier root est chiffré. Dans ce cas précis, la procédure de boot doit s'appuyer sur une image initrd (l'initrd est un système de fichier minimal qui sert uniquement a initialiser le système. Les kernels de base de la plupart des distributions GNU/Linux en utilisent un dans tous les cas, pour des raisons de compatibilité) et sur une partition de boot qui elle n'est pas chiffrée. Ainsi, le bootloader de niveau 2 (grub, syslinux,...) charge en mémoire le kernel depuis la partition de boot, puis ce dernier décompresse et charge l'initrd en RAM, celui-ci a son tour lance un script permettant de charger les modules nécessaires a la suite du boot (que ce soit pour un boot sans disque root local, ou bien comme ici avec un système chiffré), puis le système de fichier "cible" est remonté sur la racine, et l'initrd est démonté est la RAM qu'il occupait est libérée, puis la procédure de boot normale reprend depuis le système de fichier maintenant monté sur la racine.

La méthode la plus évidente pour contourner le chiffrement du disque est alors de remplacer le fichier compressé initrd dans /boot, qui n'est pas chiffrée, par un autre modifié, copiant par exemple la phrase de passe permettant de déchiffrer la partition cible. Plusieurs méthodes permettent de se prémunir contre ce genre d'attaques : l'une des plus simple est de faire un checksum du fichier initrd utilisé et reconnu comme sûr, et de vérifier lors du vrai boot que l'initrd présente toujours le même checksum. Cela dit, cette méthode a l'inconvénient d'intervenir après les faits, et de nécessiter au moins un accès a un fichier initrd reconnu comme sûr.
Une autre approche consisterait a placer le système de fichier /boot sur un périphérique dédié, protégé en écriture de façon matérielle (par exemple, une carte SD) ou, de façon encore plus efficace, sur un périphérique chiffré et protégé en écriture de façon matérielle. Ainsi, il n'est pas possible pour un attaquant de modifier ce système de fichier, et l'initrd est alors toujours de confiance. Cependant, cela a pour conséquence de rendre la mise a jour de l'initrd et du noyau beaucoup plus difficile qu'elle ne le serait sans.

Pour en revenir aux systèmes de fichiers chiffrés, leur gestion est faite par un programme dédié, cryptsetup. Ce dernier était en charge de cryptoloop, l'ancien sous-système de chiffrement du kernel Linux (déprécié depuis), et est maintenant responsable de l'utilisation userspace de dm-crypt, qui pour sa part est entièrement kernel-space. Cryptsetup permet ainsi le chiffrement, la manipulation (montage/démontage/...) et la gestion de clé des systèmes de fichier LUKS. Cryptsetup est cependant conçu pour être utilisé en tant que root, et les utilisateurs qui veulent monter de systèmes de fichiers chiffrés devront ainsi obligatoirement être capables de le faire en tant que root.

Voyons comment il faudrait procéder pour créer une image disque chiffrée de 1Go :
Tout d'abord, il nous faut créer le fichier qui contiendra l'image. Pour cela, dans une situation réelle ou l'on cherche a chiffrer un disque, il convient d'utiliser /dev/urandom comme source, pour éviter la détection du système de fichier chiffré sur le disque. Ici, par exemple, nous allons faire :

dd bs=1000 count=1000000 if=/dev/urandom of=image.img

Maintenant que notre image est créée, nous pouvons la chiffrer :

sudo cryptsetup luksFormat image.img

cryptsetup va alors nous demander si nous sommes absolument surs de vouloir formater ce disque (nous allons donc valider en tapant YES), puis une passphrase. Il convient ici de choisir une passphrase particulièrement sûre, puisque toute personne ayant accès a la passphrase aura aussi accès au disque et donc a vos secrets.
Une fois cela fait, nous allons mapper cette image :

sudo cryptsetup luksOpen image.img crypto

cryptsetup nous redemande la passphrase, charge pendant quelques secondes, puis nous redonne le prompt. Que s'est-il passé? En cherchant un peu, nous voyons qu'il n'y a pas de nouveau disque dans /dev. C'est tout a fait normal. En effet, cryptsetup (et par lui, device-mapper et dm-crypt) ne monte pas les systèmes de fichiers chiffrés, il les mappe, et ça n'a rien a voir. On remarque qu'est apparu dans /dev/mapper le fichier crypto. Ce fichier est le disque virtuel qui correspond a notre image. Il se comporte comme toute partition, et peut donc être monté, formaté, etc (il ne peut cependant pas être partitionné. Il se comporte en effet comme une partition, et non comme un véritable disque.) Bon, ceci fait, notre disque virtuel n'est pas formaté. Il nous reviens donc de le faire, pour pouvoir l'utiliser.

sudo mkfs.ext4 /dev/mapper/crypto

Maintenant que notre disque est formaté, il peut être monté :

sudo mount /dev/mapper/crypto /mnt

Et voila, nous avons un système de fichier fonctionnel et chiffré! Si vous voulez vérifier, un mount | grep crypto devrait vous donner le résultat suivant :

/dev/mapper/crypto on /mnt type ext4 (rw,relatime,data=ordered)

Vous pouvez maintenant commencer a stocker tous vos secrets sur ce fichier, ils sont (en fonction de votre passphrase) en sécurité.

Pour résumer :

Pour monter vos partitions :

sudo cryptsetup luksOpen <fichier chiffré> <nom de disque virtuel>
sudo mount /dev/mapper/<nom de disque virtuel> <emplacement>

Pour démonter vos partitions :

sudo umount <emplacement>
sudo cryptsetup luksClose <nom de disque virtuel>

Pour simplifier la vie de tous, j'ai créé deux petits scripts vous permettant de créer et de monter/démonter vos images/disques chiffré-e-s en une seule commande. Ils se trouvent sur github.

Par ailleurs, si vous comptez transferer votre image disque sur un véritable disque (ou clé usb, ou autre), il est préférable de créer une partition de taille appropriée et de faire un dd if=votre_image of=/dev/votre_partition pour ce faire.

Redesign du blog, etc

2013-06-12T19:14:00+02:00

Comme vous avez pu le remarquer, ce blog a "un peu" changé récemment.

Du coup, expliquons. J'ai récemment monté serverporn, et ai par la même occasion découvert pelican. J'ai tout de suite accroché a ce générateur de site statique en python, du fait de son efficacité, de sa facilité d'utilisation et de sa grande customisation. En gros, pelican est un logiciel qui prend des fichiers markdown ou reStructuredText, les passe a la moulinette d'un "thème" constitué de templates pour les fichiers html et l'organisation du projet et d'une partie "statique" contenant le css, et les autres fichiers nécessaires au projet, et en fait des pages html.

Globalement, un thème est constitué ainsi :

thème
├── static
│   ├─ css
│   │  └─ [css files]
│   ├─ img
│   │  └─ [image files]
│   └─ js
│      └─ [javascript files]
└── template
    ├─ base.html
    ├─ index.html
    ├─ page.html
    ├─ [...]
    └─ article.html

Sachant que les fichiers .html sont en réalité des fichiers suivant la syntaxe django, et utilisent des variables particulières telles {{ article.content }}, par exemple. La syntaxe complète est très bien documentée dans la doc de pelican.

L'un des grands avantages de pelican est aussi la facilité qu'il offre quand a la mise a jour du blog.
En effet, il offre un système de Makefiles permettant, grâce a de nombreuses cibles de compilation, de régénérer le site entier, de ne générer que les fichiers modifiés depuis la dernière génération, de générer uniquement les fichiers n'existant pas la dernière fois, etc... La gestion du projet en devient donc très simple, puisque après avoir écrit un article, il suffit de faire un make html pour mettre a jour le blog.

De plus, le système de wordpress commençait a ne plus me convenir, du fait du manque de customisation, du fait que ça soit du PHP (beurk), etc. La, avec pelican, je contrôle bien plus ce qui est mis sur le serveur (puisque c'est moi qui ait modifié les templates et le css), c'est lisible (puisque c'est du python, par opposition au PHP...), et c'est plus "efficace". Le markdown est très pratique, je peux utiliser mon éditeur de texte de prédilection pour faire les articles, je n'ai pas besoin d'un accès continu au net, bref, c'est plus efficace.

En ce qui concerne les points négatifs :

Perte des commentaires: Je vous propose de vous référer a l'article de Gordontesos ici quand a mon avis sur ce sujet.
Perte du bouton flattr: Il va bientôt être remis, c'est juste un manque de temps de ma part, mais vu que toutes les pages passent par les mêmes templates, c'est assez facile a faire.
Perte du spam: Pourquoi c'est dans les points négatifs, ca?
Temps d'adaptation et d'appréhension du système: Oui, pendant encore un certain temps, il y aura des glitchs plus ou moins réguliers sur le blog, c'est parce que j'apprend a me servir de ce système et que j'apprend du css et du html. Ca arrive, ca passera, mais dans tous les cas ca me permet d'apprendre plein de choses, donc je mets plutôt ca dans la catëgorie positive.

Voila, c'est mon retour d'expérience sur pelican. A plus.

Comment Saurik a rooté les Google Glass

2013-05-06T06:24:00+02:00

Comme vous avez pu le lire dans les médias, Saurik (Jay Freeman, connu pour avoir développé Cydia, un "app store" alternatif pour les iTrucs), après avoir reçu une paire de Google glass de la part de Google (de façon assez évidente...), a trouvé intéressant d'obtenir un accès root sur celles-ci, ce qu'il a accompli très rapidement. Des démentis de la part de Google et de certains autres sites sont vite arrivés, disant que les lunettes possédaient un bootloader débloqué et que de fait, le root était facile a obtenir : il suffisait de débloquer le bootloader, d'extraire l'OS, de le rooter hors-fonctionnement, puis de le réinstaller, rooté, sur les lunettes.

Le fait est que de débloquer le bootloader laisse une trace permanente sur les lunettes, et que Saurik n'a pas utilisé cette technique pour rooter sa paire. Voyons comment il a fait :

Je tiens tout d'abord a préciser que toutes les informations qui vont suivre sont extraites de cet article, et plus précisément de la partie "How does this exploit work". Je tente d'apporter ma maigre contribution a cette explication.

Donc, d'après les témoignages des quelques utilisateurs de Glass dans le monde, il semblerait que ces dernières fonctionnent avec un système d'exploitation Android, avec une nouvelle interface, mais avec les mêmes outils internes: un kernel Linux, des outils userland GNU et une machine virtuelle Java Dalvik pour les applications.

Saurik a donc cherché un exploit connu pour cette version d'android, et l'a appliqué a son problème. L'exploit en question est relativement simple. Depuis la version 4.0 d'android, le système permet la sauvegarde des données des différentes applications, une a une, via ADB (Android Debug Bridge, un protocole USB permettant l'accès a de nombreuses fonctions avancées des machines fonctionnant sous android, dont, entre autre, un shell, un accès au logs de debugging, etc... Cette fonctionnalité est bien entendu désactivable.) Ce backup est très simple : il crée un fichier .tgz contenant le dossier de configuration de l'application. Lors de la restauration, le système supprime la configuration existante, puis la remplace par celle dans l'archive gzip.

Le problème de sécurité vient du fait que les applications android voient leurs données stockées dans /data/data/identifiant/, et que /data/ a pour permissions drwxrwx--x 27 system system, ce qui signifie que seul system et les membres du groupe system peuvent lire dessus. Or, le fichier /data/local.prop définit de nombreux paramètres au démarrage, et notamment un qui permet au système de déterminer s'il fonctionne dans une VM ou sur un véritable appareil. S'il fonctionne sur une machine virtuelle, il donne les droits root a tout utilisateur se connectant via ADB, ce qui est ce que l'on cherche pour l'instant. Le fait que /data/ appartienne a system veut dire que le programme de restauration doit être setuid pour accéder aux données a l’intérieur qui appartiennent a root (soit toutes les applications système d'android, dont l'application paramètres, et, dans ce cas précis, l'application de log système présente sur les google glass de test. Ainsi, nous avons un processus tournant en tant que root, qui va écrire sur une partition qui nous intéresse des données que nous possédons.

Cependant, un problème reste : le système de restauration d'Android vérifie les données avant de restaurer, et ne restaure pas les symlinks, ce qui nous empêche d'avoir accès directement a /data/local.prop, le fichier qu'on cherche a modifier. Cela dit, il nous reste une possiblité. Plaçons un dossier world-writable dans le fichier de backup, et nous pourrons écrire dedans pendant quelques secondes, le temps que la restauration se termine et que le système remette les permissions en place. Ainsi, nous pouvons créer le fichier /data/local/com.google.glass.logging/whatev/x, lien vers /data/local.prop, et nous avons un toujours un processus tournant en tant que root qui est en train d'écrire dans ce dossier.

Donc, nous allons lancer deux processus en même temps :

Le premier tentera en boucle de créer le symlink. Il sera consitué de la commande suivante, depuis un shell sur les lunettes :
```
while ! ln -s /data/local.prop /data/data/com.google.glass.logging/whatev/x 2>/dev/null
do :
done
```
Le deuxième sera le processus de restauration de notre exploit. Celui ci, pour une plus grande chance de réussite, devra être suffisamment lourd : au moins \~50Mo. Il devra contenir whatev/bigfile et whatev/x, pour qu'il crée whatev, prenne du temps a copier bigfile, puis écrive dans x après que le symlink soit effectif. La commande sera, depuis l'ordinateur host :
```
adb restore exploit.ab
```
Ces commandes vont fonctionner de concert pour nous donner un accès root :
- Le processus de restauration va créer le dossier whatev, qui sera world-readable. Il va commencer a copier le fichier bigfile.
- Le processus de symlink va créer le lien /data/data/com.google.glass.logging/whatev/x, pointant vers /data/local.prop, puis rendre l'âme proprement.
- Le processus de restauration, ayant enfin fini de copier whatev/bigfile, copiera les contenus que nous voulons dans whatev/x, qui est lié a /data/local.prop. Comme le processus est setuid root, il ne se rendra compte de rien, et écrira tout dans /data/local.prop.

And voilà! On a écrit ce que l'on veut dans /data/local.prop, ce qui nous permet de faire croire a android qu'il tourne dans une machine virtuelle (ce que l'on veut, c'est en fait "ro.kernel.qemu=1", qui indique au noyau qu'il tourne dans qemu, un système de VM).

Il nous reste a rebooter, depuis l'ordinateur host :

adb reboot

Puis nous remontons la partitions système en lecture/écriture (r/w), depuis le host :

adb shell "mount -o remount,rw /system"

Nous copions le binaire su vers l'appareil :

adb push su /system/xbin

Nous donnons les bonnes permissions a ce binaire, afin de pouvoir l’exécuter plus tard :

adb shell "chmod 6755 /system/xbin/su"

Ensuite, nous supprimons le fichier /data/local.prop, pour pouvoir redémarrer normalement :

adb shell "rm /data/local.prop"

Enfin, nous redemarrons a nouveau :

adb reboot

Et voila, une paire de google glass rootée!

Il est bon de préciser que cette manipulation n'est possible que parce que les lunettes tournent sous une ancienne version d'android, et que ce bug a été fixé depuis.

Il serait aussi interessant de couvrir les problèmes de vie privée qu'engendrent les Google Glass, et ce sera fait dans un autre billet.

A bientôt!

Monter son propre serveur, partie 1: le serveur et l'apache.

2013-03-18T09:51:00+01:00

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...)

Pourquoi je vais quitter linux pour passer a FreeBSD.

2013-02-04T17:41:00+01:00

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 :

Ce qui est petit est beau
Faites en sorte que chaque programme fasse une chose, bien.
Faites un prototype aussi vite que possible
Choisissez la portabilité plutôt que l'efficacité
Stockez les données dans des fichiers textes.
Utilisez ce qui existe déjà a votre avantage. [1]
Utilisez des scripts shells pour faciliter la portabilité et la réutilisation.
Évitez les UI qui "capturent" l'utilisateur.
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...*

Update et pensées a propos du Raspberry Pi

2013-01-27T01:55:00+01:00

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.

Update

2013-01-05T18:32:00+01:00

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!

Mutt ou le client email le meilleur moins mauvais

2013-01-02T02:12:00+01:00

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!

La séparation des églises et de l'état, une idée qu'elle est bonne?

2012-12-13T03:08:00+01:00

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!

La cryptographie avec PGP et principalement GnuPG

2012-11-19T00:36:00+01:00

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!

L'informatique a l'école

2012-10-15T20:34:00+02:00

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 made simple

2012-10-05T14:48:00+02:00

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:

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!
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~

Les systèmes de fichiers

2012-09-25T10:28:00+02:00

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.

Le Quenya - Épisode ø

2012-09-18T19:07:00+02:00

Le Quenya est, pour ceux qui ne connaissent pas (comme moi jusqu’à il y a peu...), le nom que donnait Tolkien au dialecte principal parlé par les Elfes dans les différentes œuvres de l'auteur, dont Le Seigneur des Anneaux, le Hobbit, ou encore le Silmarillion. Il faut se rendre compte avant de commencer cet article que l'une des œuvres les plus impressionnantes de Tolkien, si ce n'est la plus grande, est l'impressionnant travail linguistique passé sur les différentes langues présentes dans son œuvre littéraire : L'elfique, qui est donc le quenya, la langue des nains, qui est appelé le khazalide, etc.

En effet, a contrario des "langues" développées dans d'autres œuvres littéraires telles Eragon ou Harry Potter, où l'auteur-e se contente de lier un mot de français (ou d'anglais) a un mot de sa "langue", les langues de l'oeuvre de Tolkien sont des langues complètes. Elles possèdent des racines logiques, des systèmes de grammaire et de conjugaison propres, une logique inhérente dans la prononciation ou l'orthographe, et ainsi de suite.

Un véritable rêve de linguiste donc, puisque ces langues sont pratiquement entièrement documentées par Tolkien lui même (voir l'appendice E du SdA, particulièrement instructif a ce sujet.)

J'ai donc décidé d'apprendre le Quenya récemment, et je vais donc poster ici des résumés des cours que je suis ( disponibles ici , une traduction en français est disponible la en pdf ), et des infos ici toutes les deux semaines.

Si ce sujet vous intéresse, le compte twitter @Quenya101 poste régulièrement des informations sur le sujet, et pour plus d'infos sur le sujet, vous pouvez en trouver par ici.

Et en tant que première leçon, vous pouvez apprendre que ce mot que vous avez prononcé comme le Kenya tout le long de cet article se prononce en fait [Kwenïa], ou bien Qwenya!

Update a propos du blog

2012-09-18T16:57:00+02:00

Bonsoir! Un petit post pour faire un peu le point sur ce blog.
Comme vous avez pu le remarquer, j'ai un peu de mal a tenir les délais que je m'étais fixés pour ce blog (un post tous les 8 jours), et après y avoir un tantinet réfléchi, ceci est du a deux points principaux :

Tout d'abord, le manque d'inspiration, tout simplement. C'est assez compliqué de trouver des sujets intéressants liés a l'informatique, et qui méritent un article. Je vous invite d'ailleurs a me suggérer des sujets via les commentaires ou twitter (@Wxcafe)
Ensuite, le délai de 8 jours est trop court pour me permettre de faire les recherches nécessaires, tout en manageant mes cours et mon temps libre.

A cause de cela, j'ai pris la décision de changer le rythme de parution des articles a un *minimum* d'un post tous les 10 jours. Bien entendu, si j'ai de l'inspiration en trop, plus de posts sont envisageables.

Voila. A part ca, je tiens a vous remercier de me lire (c'est assez étonnant de voir ca...), et je précise que je vais ajouter une page About Me, qui bien entendu rassemblera des informations sur moi, ma vie, mon oeuvre :P

Ceci dit, je vais bosser un peu sur le prochain article.

A plus tard!

Introduction a bash en tant que language de programmation.

2012-09-08T18:15:00+02:00

L’interpréteur de commandes bash (Bourne Again SHell) est possiblement le shell le plus connu, notamment grâce a son intégration en tant que shell par défaut dans les distributions Linux les plus répandues (Debian - Ubuntu, Fedora, OpenSUSE, Mandriva - Mageia, etc...).

Cependant, il n'est souvent connu qu'en tant qu’interpréteur de commande. Alors qu'en réalité, le bash est un langage de programmation (presque) complet! Ainsi, il intègre les structures de contrôle habituelles ( pour mémoire, les structures de contrôle comprennent les conditions (les ifs), les boucles (les while), et les choix (les case), entre autres.), et est donc ce que l'on pourrait appeler un langage de script, interprété, de la même façon que python, a la difference près qu'il contient un prompt (un système d'entrée de commande interactif) bien plus complet et développé que python.

Cependant, les programmes en bash ne sont executables que dans un environnement de type UNIX, et donc pas sous Windows (cygwin (cygwin.com) propose ceci dit un système permettant d'utiliser bash sous windows. Il faut malgré tout convenir que cet environnement est bien plus compliqué a manipuler, et globalement ne permet pas d'acceder a des portages de qualité satisfaisante.)

Ainsi, il est possible de créer des fichiers .sh, contenant des instructions bash mises a la suite (de la même façon qu'un script BATCH Windows .bat), et faisant appel autant aux commandes internes de bash, aussi bien que les commandes externes mises en place par les programmes installés sur le système, exactement comme dans une invite de commande. Ainsi, pour appeller firefox, la commande 'firefox' lancera le petit panda roux directement dans la boite magique, tandis qu'un if [condition] suivi d'un then (quelque chose) lancera le fameux quelque chose suscité si la condition est vérifiée. Un peu comme en C, quoi.

De cette façon, et avec quelques informations et connaissances, il est facile de comprendre le fonctionnement de la programmation en bash. Quelques exemples commentés:

#!/bin/bash 
# La ligne du dessus est très importante, c'est elle qui dit a bash quel doit être 
# l'interpreteur des commandes écrites dans ce script. Ici, on dit a bash d'interpréter 
# lui même les commandes comprises dans ce script. On aurait tout de fois pu lui faire 
# executer du python, par exemple, en mettant #!/usr/bin/python a la place.
echo "this is a test of bash as a simple script manager" # echo est une commande d'affichage de message.
echo "what's your name, user?" 
read your_name # la commande read permet de demander a l'utilisateur de donner une 
# information, stockée dans la variable en paramètre. 
echo $your_name "is your name" # echo permet aussi d'afficher la valeur de variables. 
# Ici, on renvoie la variable remplie précédemment, suivie d'un message. 
exit # cet appel a exit n'est pas obligatoire, mais donne un aspect plus 
# propre au code. Il ne quittera pas la session de terminal, cependant.

Voila. Ce script bash ne sert pas a grand chose, mais il a le mérite d'être clair quand aux capacités et a la simplicité du bash en tant que language de programmation. Alors en effet, nous n'avons ici absolument pas utilisé les capacités de bash en lui même, et n'avons fait que le renvoyer a des programmes externes (sauf read, il est vrai). Voyons maintenant la syntaxe de bash quand il s'agit d'utiliser les structures de contrôle:

#!/bin/bash 
echo "welcome to this second bash program. would you please kindly enter the name of the machine you're running this on?" 
read host_name 
if [ $host_name == $HOSTNAME ] ## voici la syntaxe du if. Attention a bien penser a mettre les espaces avant la première variable, et après la seconde. La variable $HOSTNAME ici utilisée est une variable présente par défaut sur le système. 
then echo "you told the truth!" 
fi ## le fi est la commande fermant le if, tout comme le EndIf en basic. C'est un peu vieillot, mais important en bash. 
if [ $host_name != $HOSTNAME ] ## l'opérateur != est l'inverse de ==, il vérifie donc si les deux variables ne sont pas les mêmes. 
then echo "you lied!" 
fi 
exit

Voila un petit programme permettant d'apprendre la syntaxe du if en bash. comme vous pouvez le voir, le language est plutôt lite, et la structure if n'est pas très difficile a prendre en main.

Passons maintenant au while:

#!/bin/bash
echo "what is your name?"
read name
while [ 1 < 10 ]    ## le while se présente sous la forme while (truc); do (machin); done. Les [] sont en fait des programmes differents, inclus dans bash.
do echo "i love" $name
done
exit

Ce petit programme permet d'observer les bases de while (qui est la boucle de base en bash).

Le troisième opérateur de bash est case. Voyons:

#!/bin/bash
echo "please enter a number between one and five"
read number
case $number in 
1)
echo "the choosen number was one"
;;
2)
echo "the choosen number was two"
;;
3)
echo "the choosen number was three"
;;
4)
echo "the choosen number was four"
;;
5)
echo "the choosen number was five"
;;
*)
echo "this number is not correct"
;; 
esac
exit

case est un opérateur plus complexe a utiliser a bon escient, et sert a faire des ifs multiples sans avoir a taper des dizaines de lignes de code.
(pour ceux qui auraient du mal avec cet opérateur, il faut comprendre que le code vérifie chacune des conditions : le 1) est validé si la valeur de \$number est 1, le 2) est validé si cette valeur est 2, etc.. le *) désigne toutes les valeurs, et est donc validé si aucune autre valeur n'a précédemment acceptée.

Quelques notions manquent ici:
- les nombres aléatoires sont générés par un appel a la variable \$RANDOM, qui renvoie un nombre aléatoire entre 0 et 32767 (un entier a 16 bits donc). il est possible de faire des invocations a des nombres aléatoires plus grands, mais les méthodes permettant de faire cela sont plus complexes, et je ne les aborderai donc pas ici.
- comme vous avez pu le constater, les variables sont désignées en tant que telles par l'utilisation d'un symbole \$ au début de leur nom. Ainsi, echo number renverra "number", tandis que echo \$number renverra le résultat de la variable \$number.
être utilisées dans un programme bash.
- comme vous avez pu le constater, les commandes doivent tenir en théorie en une ligne. Cependant, le caractère \ permet de retourner a la ligne en faisant considérer a bash qu'il s'agit de la même ligne.

Globalement, il faut admettre que bash n'a pas vocation a être un langage de programmation extrêmement développé. Sans framework graphique, avec peu de manières d'utiliser de grandes variables, ou encore une gestion de la mémoire risible, bash n'a rien d'un langage de développement professionnel.
Cependant, le simple fait qu'il soit considéré comme un langage de programmation a part entière font de lui un langage de script d'une puissance incontestable, et sa simplicité et sa grande popularité font de lui un langage de choix pour apprendre la programmation simplement et sans trop se prendre la tête.

J'espère que cet article aura été utile a certain-e-s, et je vous souhaite bonne chance dans votre découverte de la programmation (n'allez pas voir ceux qui font de l'orienté objet, c'est des méchants :3)

Les différentes couches d'un système d'exploitation

2012-09-06T23:29:00+02:00

Étant utilisateur plus ou moins fidèle de GNU/Linux depuis quelques années (plus ou moins, parce que j'ai toujours un Windows en dual boot, principalement pour les jeux (possiblement plus pour longtemps, avec l'arrivée de Steam pour Linux... ) ), je commence a connaître plus ou moins bien mon système. Or il y a plusieurs choses a savoir sur les systèmes d'exploitation, et celle dont je vais parler aujourd'hui, c'est le système de couches.

Un système d'exploitation (de type UNIX, \<troll>enfin un vrai système quoi. \</troll>) incorpore plusieurs systèmes de couches.

Ainsi, Linux (le noyau) a commencé en étant un kernel monolithique, c'est a dire que tous les composants sont intégrés au kernel. Ce qui signifie que rien ne peut être ajouté au noyau sans recompiler celui ci. Or, quand on sait que le noyau comprend entre autres les drivers du matériel et des systèmes de fichier, cela peut poser des problèmes quand a la taille du kernel et a la licence libre de ce dernier.

Depuis un certain temps, le kernel linux est devenu un kernel modulaire, ce qui signifie que des modules peuvent être chargé a tout moment en cours d’exécution, ce qui permet l'utilisation de nouveaux systèmes de fichiers a chaud, ou l'insertion de matériel et l'installation de drivers sans interrompre l’exécution du système (Windows utilise un système de fausse installation de drivers pour le matériel externe, et un système de pré-installation des drivers pour les périphériques dits "plug and play")

Après le noyau intervient le système. Or, au tous premiers instants du boot, les systèmes GNU/Linux utilisent un système permettant de limiter l'utilisation de ressources systèmes si elles ne sont pas nécessaires, et incorpore ainsi un système dit de "runlevels"

Ainsi, au runlevel 0, le système s'éteint après avoir booté. Ainsi, ce runlevel permet de tester le bon démarrage du système sans avoir a effectuer de manipulation pour le ré-éteindre

Le runlevel 1 est appelé mode single user, et c'est un nom plutôt adapté étant donné que ce runlevel donne accès a un système en étant automatiquement loggé en tant que root, avec tous les autres utilisateurs désactivés, de même que tous les systèmes de réseaux

Le runlevel 2 est appelé mode multi user, et vous mets en face d'un système classique. en ligne de commande, mais avec tous les systèmes de réseau désactivés.

Le runlevel 3 est le même que le 2, mais avec les systèmes de réseaux activés.

Le runlevel 4 n'est pas officiellement défini, et est censé être activable en fonction des besoins de l'utilisateur. Sur la plupart des distributions grand public, ce runlevel est lié au...

Runlevel 5! Multi-user, networking, with working GUI! c'est le système tel que vous le connaissez, avec l'interface graphique et le système de login graphique.

Le runlevel 6, enfin, est le bien nommé "reboot", qui reboot la machine quand il devient le runlevel courant.

(Il est a noter que Debian, et donc toutes les distribs qui en sont dérivées, ne font pas de distinction entre les differents runlevels du 2 au 5. Ainsi, Ubuntu fonctionne par défaut au runlevel 2, avec un login et une interface graphique, et un mode réseau fonctionnel, bref avec des fonctionnalités qui ne sont normalement disponibles que sous le runlevel 5.)

Il est possible de changer de runlevel grâce a la commande runlevel (oui, c'est évident...)

Les systèmes Linux utilisent aussi un système dit de SandBox , qui en informatique est un système permettant d'isoler les processus les uns des autres. Ainsi, la pile réseau, qui est le système auquel les différents processus envoient les différents paquets qui doivent sortir de la machine , et qui redistribue ces paquets, est isolée du reste du système, en cela qu'aucun des autres processus ne peuvent modifier cette pile hors du runlevel 1 ou 2.

De la même façon, le navigateur chrom/ium fait fonctionner tous les onglets, ainsi que toutes les extensions, dans des processus différents. Certaines distributions linux implémentent un système de cette sorte pour toutes les applications, ou seulement pour certaines. ainsi Chakra Linux a un système d'installation d'applications dans des disques virtuels, ce qui permet une sécurité totale du processus.

Voila, j'espère vous en avoir appris un peu sur le fonctionnement des différentes couches de linux, et j'espère que cet article vous poussera a tester un peu votre système et a vous amuser avec les différents runlevels

La programmation expliquée simplement

2012-08-27T00:22:00+02:00

Salut!
Tout d'abord, je tiens a m'excuser de ne pas avoir eu le temps d'écrire récement, mais j'ai eu la chance d'avoir un PC a monter, donc j'ai passé pas mal de temps assez occupé.

Enfin, après un certain temps a farfouiller au millieu des connecteurs SATA et a apprendre que, oui, l'alimentation sert aussi pour les disques durs, je suis de retour pour un court article.
Du coup, je m'étais dit que j'allais reprendre sur le thème de l'informatique expliquée au grand public, en tentant d'aller un peu plus loin que la dernière fois sur le thème de la programmation
Ce qu'il faut comprendre, c'est la facon dont fonctionne un ordinateur. Si a peu près tout le monde sait que "les ordinateurs, ils ne comprennent que les 1 et les 0!", peu de gens savent comment cela fonctionne en détail.

Si vous êtes sur ce blog, il y a pas mal de chance que vous ayez déjà des notions de base en informatique. Ainsi, vous savez surement que les ordinateurs fonctionnent avec des programmes, qui sont composés de code.
Ainsi, il faut comprendre que le code (source) est "compilé" en un fichier "binaire". Un fichier binaire est un fichier comprenant les instructions telles qu’exécutées par le processeur, et donc absolument illisible pour un humain.

La compilation est le processus qui transforme le code source en binaire executable. Les binaires ont, sous Windows, l'extension .exe, tandis que sous les systèmes UNIX-like, ils n'ont pas d'extension particulière.
Ceci étant dit, il faut comprendre que certains langages sont plus proches que d'autres du langage processeur, les langages les plus proches sont dits de "bas niveau". Les langages les plus éloignés sont donc dits de haut niveau.

Par exemple, l'assembleur est l'un des languages de plus bas niveau, tandis que python par exemple est un langage de plus haut niveau. Les langages de haut niveau sont souvent bien plus simples a comprendre et a apprendre que les langages de bas niveau

Ainsi, en C, un langage de niveau relativement bas, pour afficher "hello world" sur l'écran, le code nécessaire est :

#include 
void main() {
printf("hello world");
return 0;
}

le même programme en python s'écrit :

print "hello world"

et n'a pas besoin d'être compilé , puisqu'il peut être intepreté directement.

Python utilise en effet un système similaire a Java en ayant un interpréteur dit "runtime" ou "temps réel", qui interprète le programme sans le compiler. Java utilise un système légèrement différent, puisque le code a besoin d'être compilé, mais est interpreté par un interpréteur et non par le processeur.

Cette méthode permet le fameux "code once, run everywhere", ce qui signifie que le même code est exécutable sur quasiment tous les systèmes d'exploitation (en fait, tous ceux sur lesquels l’interpréteur est disponible.)

Voila, je vous laisse sur le fonctionnement de Java et de Python, et je vais me coucher.
A bientôt!

GNU/Linux pour les non technophiles, ou l'OS libre pour votre grand-mère

2012-08-22T20:33:00+02:00

GNU/Linux est un vaste et extraordinaire territoire technologique, mais je ne vais pas m'attarder ici sur les aspects profondément techniques de ce territoire pour faire plutôt une sorte d'introduction a ce qu'est vraiment GNU/Linux, pour les gens n'ayant aucune ou très peu de connaissances en informatique.

GNU/Linux, que j’abrégerai ici en Linux pour plus de simplicité, est un Système d'Exploitation. Un système d'exploitation est, pour simplifier, un ensemble d'outils informatiques qui vous permettent d'utiliser votre ordinateur, ainsi, Windows est un système d'exploitation. L'abréviation de système d'exploitation (Operating System en anglais) est OS. Les 4 principaux OS existants aujourd'hui sont Windows, Mac OS, GNU/Linux, et Solaris. Les trois derniers sont issus d'un autre système, plus ancien, nommé UNIX.

De ce fait, on pourrait penser que Linux remplace complètement Windows une fois installé, et comprend une interface graphique, et toutes sortes d'utilitaires permettant a l'utilisateur d'utiliser le système (sous Windows, pensez a l'explorateur de fichiers, ou a Internet Explorer. Pour l'interface graphique, pensez a... Pensez que votre système affiche autre chose que des lignes de commande.) Or non, une fois installé, Linux en lui même ne vous afficherait aucune interface graphique, et s'il est effectivement livré avec des utilitaires, ils ne sont que des programmes en ligne de commande. Autant les utilisateurs avancés sauront s'en servir, et pourront argumenter que c'est plus efficace ou plus rapide, autant les utilisateurs basiques préfèrent une interface graphique. Alors comment en obtenir une?

Ici, il convient de faire une précision importante. Si il n'existe qu'une seule version de Windows, ou de Mac OS, il existe en fait plusieurs centaines de "versions" différentes de Linux. Appelées distributions, ces dernière sont développées par des groupes complètement séparés, et se basent sur le fait que Linux soit entièrement placé sous licence libre (ce qui leur permet de l'utiliser a leur guise, a condition que leur travail soit lui aussi placé sous licence libre). De ce fait, de nombreuses distributions existent et se développent en parallèle. On peut ainsi citer Debian, qui est l'une des distributions les plus importantes, ou encore Ubuntu, qui est l'une des plus connues et des plus simples a utiliser.

Ainsi, ces distributions intègrent une interface graphique. Cependant, grâce a la liberté dont bénéficient les développeurs sous Linux, il existe de nombreuses interfaces graphiques différentes : Unity, la nouvelle interface d'Ubuntu; GNOME , une interface qui vise a la simplicité; ou encore KDE, une interface utilisateur ressemblant a Windows 7.

Ainsi, le choix astronomique de distributions Linux a bien un sens : chacune d'entre elle intègre des outils différents. Par exemple, Debian intègre GNOME 2, qui est l'ancienne version de GNOME, ce qui la rend particulièrement stable. Ubuntu intègre Unity, ce qui en fait une distribution particulièrement intuitive. Linux Mint intègre Cinnamon, qui est une version dérivée de GNOME 3, ce qui permet encore une autre expérience. Et Arch Linux n'intègre pas d'interface graphique du tout, ce qui permet a l'utilisateur de choisir entre les multiples interfaces existantes.

Ce qu'il est important de retenir de cela, c'est que Linux est un OS complètement libre, ce qui signifie que n'importe qui peut modifier et utiliser tout le code de Linux gratuitement et comme il l'entend. Ainsi, Linux est un OS qui est véritablement créé par des passionnés, pour tous et toutes. Surtout, il convient de retenir que Linux n'est pas compliqué a utiliser, ni a installer. Windows et Mac OS ne le sont pas non plus. Cependant, Linux donne la possibilité a l'utilisateur de le rendre affreusement complexe, mais aussi de le rendre adapté a ses besoins, quels que soient ceux ci. Et c'est la que réside l'incroyable puissance de ce Système d'Exploitation. Il est extraordinairement adaptable.

N'hésitez donc pas a le présenter a vos proches, même s'ils ne sont pas technophiles. Ils pourraient adorer, et peut être même le devenir :)

A bientôt!

Débuts, présentation, etc...

2012-08-18T20:27:00+02:00

Bonjour!

Je m'appelle Wxcafé, et ça fait pas mal de temps que je sévis sur Twitter, mais aussi sur IRC (Je traîne pas mal sur irc.freenode.net/##nolife et #debian-fr)

J'ai 17 ans, je suis donc étudiant (bac général), je vis a Paris, et je fais partie de ce genre de personne qui sont capables d'investir tout leur temps et leur énergie a s’intéresser a un sujet en particulier, et qui ne peuvent pas vivre sans leurs passions, avec une petite différence cependant, qui est que je m’intéresse a plusieurs choses : l'informatique, qui est un champ tellement large qu'on peut passer une vie a apprendre des choses dessus, et plus particulièrement à l'informatique avancée (Noyaux dérivés d'UNIX et de Linux, outils libres {bien que n'étant pas un barbu intégriste [ceci est un troll assumé. Les trolls seront a partir de maintenant indiqués avec le tag [tr]] du libre, je préfère utiliser de l'open-source si c'est possible}, programmation en C, python et java, etc...) , mais aussi a l’électronique.

Dans un tout autre registre, je m’intéresse aussi beaucoup aux différents aspects du féminisme et des égalités sexuelles (anti-homophobie/transphobie/biphobie/etc , anti-sexisme, et cætera) , et a la culture dite "geek" en général.

Je tenterai de poster ici le plus souvent possible, mais j'ai de gros problèmes en terme de régularité de post, donc ne vous inquiétez pas si vous ne voyez rien pendant deux semaines.

Merci beaucoup de votre attention, et a bientôt!