Nous allons voir un exemple récent, déterminer quels logiciels font les pies et finir par quelques réglages de ces derniers.

Quelques définitions rapides :

• MUA : Mail User Agent, c’est l’agent coté utilisateur. Thunderbird que j’évoque dans cet article, Evolution, KMail, mutt, mail et sendEmail sont quelques exemples.
• MTA : Mail Transfer Agent, le serveur smtp. Sendmail que j’évoque dans cet article, postfix, qmail, exim sont les plus connus, mais ssmtp et OpenSMTPd sont des alternatives montant en puissance.
• MDA : Mail Delivery Agent, c’est le logiciel qui remet les emails dans les comptes utilisateurs. Procmail est le plus connu.
• RFC : Request For Comment, un texte de référence. Le texte nous intéressant ici est la RFC 5321 http://tools.ietf.org/html/rfc5321

Cas concret

Décortiquons ensemble un email envoyé par un de mes fournisseurs. Il n’y a rien d’exceptionnel dans cette section qui n’ait déjà été maintes fois abordé dans la presse informatique vulgarisée.

L’email en question

Comment le lire ?

La RFC 5321 section 4.4 précise que le Mail Transfert Agent (mta) se DOIT, et avant toutes autres opérations de transfert, d’inclure une trace « Received » ou « timestamp ». L’ordre des « Received » se lit donc de bas en haut.

Nous apprenons que notre « correspondant » a émis son email depuis son « PC1 » 192.168.69.50 (IPV4) . On devine aisément son système d’exploitation, c’est celui qui donne des noms de machines en majuscules.

Jouons au jean-kevin

On déduit du mix « .fr »/ « .com » que notre sujet d’étude n’est pas très familier avec les dns et c’est sans doute la raison pour laquelle il n’en a pas en interne. Il n’est pas non plus familier avec ntp . Visiblement notre sujet d’étude n’est pas familier avec certains services réseaux.

Attardons nous quelques secondes sur le 3ème mta rencontré, OBS utilise un mta du nom de « localhost [127.0.0.1] », nous sommes dans une application minimaliste de la section 4.4 de la RFC 5321. Pourquoi être resté a minima, contrairement aux autres mta ? Le terme MX-ASAV nous donne un indice : AntiSpam AntiVirus … ce mta est vraisemblablement inaccessible il n’y a aucune raison de fournir plus de détails.

Que retenir de cette partie ?

Nous n’avons donc rien appris de bien intéressant car nous ne cherchons rien de particulier. Détails à priori inintéressants, mais avez-vous vraiment envie d’en faire profiter le reste de vos correspondants ?

Désolé, à cause de limitations techniques nous ne pouvons pas afficher la suite de cet article dans le flux RSS. Rendez-vous directement sur Geekfault pour lire la suite

Aucun post similaire.

OpenVZ est un système de virtualisation particulier. Il permet de faire tourner de multiples machines virtuelles partageant un seul kernel patché spécialement pour l’occasion. Cette techniques est donc limités à des machines (hôte ou invité) tournant sous linux. En contrepartie les performances sont particulièrement élevés. Il est également très aisé de modifier les particularités physiques des machines virtuelles sans les redémarrer. Cette technique est souvent employée chez les hébergeurs pour les offres « VPS ».

En pratique, c’est utile à des fins de sécurité. On essaie de mettre un seul serveur par VPS (serveur web sur un VPS, MySQL sur un autre, mail encore sur un autre …). Si l’un des serveurs possède une faille de sécurité, les autres serveurs ne pourront alors pas être impactés. Il y a également la facilité à backuper une machine virtuelle et donc au besoin de la dupliquer ou la déplacer. Cependant, on ne peut pas faire de migration à chaud comme certains de ses concurrents.

La création d’une machine ne prend guère plus d’une minute sur une machine correcte, ce qui permet de s’en servir comme d’un moyen de tester des logiciels sans encombrer votre distro. Qui plus est, le lancement d’une machine est quasi instantané, ce qui peut parfois sauver des manchots…

Installation de la bête

Le kernel

Cette partie dépend pas mal de la distro. J’aborderai ici la méthode pour Gentoo, à vous de l’adapter à votre distro.

On commence par installer les source du kernel patché qu’il faudra compiler :

Il faut ensuite adapter la config du kernel :
Rendez-vous dans ///usr/src/linux//

Ensuite, lancez:

Vérifiez que tout en haut il s’affiche bien le nom du kernel openvz : .config – Linux Kernel v2.6.27-openvz-briullov.1-r2 Configuration

Dans OpenVZ cochez tout (personnellement je préfère mettre en module le plus possible car je ne l’utilise pas tout le temps).
Puis allez dans Filesystems là vous aurez VPS Filesystems et Virtuozzo Disk Quota support, à ajouter également.

Maintenant enregistrez la config puis compilez votre tout nouveau kernel patché avant de faire une pause IRC :

Mettez votre kernel au chaud et préparez le reboot :

Ajoutez ces lignes en adaptant à votre cas dans /boot/grub/menu.lst :

Si vous avez suivit ces instructions sans virer ce qu’il y avait avant, vous ne devriez pas foirer votre machine : l’ancien kernel est toujours présent et le grub possède juste des lignes en plus. Donc maintenant faut tester avec un reboot en choisissant la nouvelle entrée du grub.

Si vous parvenez à reboot alors vous venez de faire le plus dur !
Un petit uname -r peut confirmer que vous tournez sur le noyau modifié.
Passons dès maintenant à la suite.

Les outils

OpenVZ se pilote avec la commande vzctl donc installons la :

Maintenant vous avez le kernel, les outils, il ne manque plus que les templates qui sont en faites les distros que vous pourrez monter en quelques secondes.
Vous pouvez les créer vous même mais généralement vous trouverez chaussure à votre pied sur le site officiel qui propose déjà une petite collection de templates pré-créés.

http://download.openvz.org/template/precreated/

Vous devrez les télécharger dans le dossier /vz/template/cache.

Prise en main du monstre

Ça y est : c’est tout bien installé et ça ne demande plus qu’à tourner.

Le script de démarrage fonctionne à merveille puisqu’il charge bien les modules (et les décharge en cas d’arrêt).
Pour faire en sorte de le lancer au démarrage de la machine :

Création d’une machine

OpenVZ a pour objectif de faire tourner de nombreuses machines virtuelles simultanément. Elles sont numérotées (en commençant à 101). Ce numéro se nomme CTID. Imaginons que vous ayez un template debian-5.0-x86:

Pendant quelques secondes ça mouline et vous pond une ptite Lenny des familles.

Configurons la pour qu’elle puisse rejoindre notre réseau :

Là je lui attribut un petit nom, une IP, un DNS, un quota de disque dur ainsi qu’un quota d’utilisation du processeur.

Bon c’est bien joli mais maintenant faut la faire tourner histoire de voir ce qu’on peut en tirer :

Et bha voilà elle est là … « Up & Running ».

Entrer et interagir avec une machine

Pour aller utiliser une machine rien de plus simple :

Sachez également que les templates pré-créés sur le site officiel possèdent toute un serveur SSH qui tourne afin de vous faciliter la tâche.

Il est possible d’exécuter des commandes dans une machine sans y rentrer :

Configurer un peu plus la bestiole

Il est possible de modifier la machine invitée pendant qu’elle tourne afin de lui ajouter de la ram, augmenter son quota d’espace disque ou bien restreindre son utilisation max de cpu. Pour cela vous devrez faire appel encore une fois à vzctl.

Modifier le bridage CPU

Il est donc possible de brider le pourcentage de processeur qu’une machine virtuelle peut utiliser afin d’éviter qu’une machine se goinfre et lèse le reste. Pour cela :

En sachant que chaque processeur représente 100%, si vous possédez une machine quadcore, vous pouvez jouer de 0 à 400%.
Vous constaterez que la modification est prise en compte immédiatement.

Modifier le quota de disque dur

Attribuons plus d’espace à une machine :

Modifier la quantité de RAM

C’est la commande la plus complexe :

Là on passe à 512 Mo de ram avec possibilité de monter en pic à 1024.

Là on passe à 256 avec possibilité de monter en pic à 512.
Vous voyez le principe …

Les paramètres réseaux

Le nom des paramètres est assez explicite.

Créer ou modifier le mot de passe d’un utilisateur

Il est possible de modifier le mot de passe d’un utilisateur (pratique en cas de boulette pour rester propre). Si l’utilisateur n’existe pas, il sera créé dans la foulée.

Tout le reste

Lancer une machine au boot

Il faut avoir lancé OpenVZ au boot. Il faut ensuite :

Configurer un peu tout

Il est possible et plus pratique de modifier la configuration directement dans le fichier de conf de la machine dans le fichier /etc/vz/conf/$CTID$.conf

Manipulons le bouzin

Voici à peu près tout ce que l’on peut faire.

• Créer une machine avec create
• Démarrer une machine avec start
• Stopper une machine avec stop
• Rentrer dans une machine avec enter
• Supprimmer une machine avec destroy

Pour plus de commandes :

Oui mais après ?

Ça y est vous savez créer vos machines en moins de trois minutes et gérer leur ressources comme un héros des temps modernes. Mais que faire de ce petit monde ?
Comme expliqué plus haut la virtualisation à pour but de fiabiliser une infrastructure. On peut déplacer une machine virtuelle l’une machine physique à une autre, on isole les différents serveurs publiques afin de limiter l’impact des failles de sécurité …
Il vous faut donc expérimenter ces différentes tâches afin de pouvoir parer l’imprévu. Replancher la gestion de son petit script iptables pour adapter son réseau à ce nouveau fonctionnement.
Le chemin est tout tracé…

Si vous avez aimé ce post...

1. Faille critique dans tous les noyaux Linux

Python est devenu assez à la mode, pour le développement web, ces dernières années avec l’arrivée de frameworks web comme Django, Pylons et web.py. On le voit souvent utilisé sur apache2, avec mod_python, ou sur des serveurs Python dediés à ça (CherryPy, etc)

Je cherche depuis longtemps un moyen de faire du Python sur HTTP. J’ai mis pas mal de temps mais je pense avoir trouvé une configuration sympa.

Je vous propose ici d’essayer nginx, un serveur HTTP (entre autres), très performant et beaucoup plus léger/rapide que apache2. Il est très efficace pour faire du reverse-proxy (c’est à dire être utilisé en frontal/load-balancer devant un serveur HTTP, et lui transmettre les requêtes en faisant du cache et le cas échéant du load-balancing).

La configuration de nginx est très simple, et la documentation est très complète : wiki.nginx.org. L’installation de nginx est facile, il est inclus dans la plupart des distributions actuelles, donc à vos emerge/apt-get.

nginx ne gère pas le python nativement. Il y a plusieurs solutions cependant :

• Faire du proxy vers un serveur qui gère le python, comme apache2. On perd la majeure partie de l’intêret de nginx, cependant.
• Faire du FastCGI vers un serveur FastCGI. C’est la solution la plus fréquente, en utilisant fcgi.py ou flup
• Faire du WSGI. C’est un protocole de communication entre serveurs HTTP et applications Python. Solution aussi assez fréquente.
• Faire du proxy vers un serveur qui gère le python de manière native. C’est une solution moins fréquente mais très pratique.

Avant même de penser à choisir une des solutions ici présentes, il faut les comparer entre elles.

nginx => apache2 => python

L’ennui de cette solution c’est : apache2. Utiliser nginx pour forwarder à apache2 est presque inutile. Presque ? Oui, car on peut dire à nginx de garder les fichiers statiques pour lui. Cependant, le gain de cette méthode est assez minime, et ce n’est intéressant que pour faire du load balancing sur plusieurs apaches.

le FastCGI

FastCGI c’est une norme, pour faire traiter du contenu dynamique par une application externe. Donc le support du FastCGI tout seul est inutile, il faut aussi quelque chose pour gérer derrière.

J’ai testé flup, un framework Python léger. Le résultat : ça marche, méééé c’est lent. Je tournais autour de 35/50 requêtes par seconde, et l’utilisation en mémoire vive était phénoménale, 150 mégas pour 1000 requêtes. (bien sur ces chiffres n’auront de valeur que lorsqu’ils seront comparés aux autres).

FastCGI est sympa pour faire une configuration “vite”. C’est d’ailleurs la seule solution viable, à ma connaissance pour faire du PHP sur nginx, à part le proxy vers un autre serveur HTTP.

Bref, FastCGI ne m’a pas convaincu. Et mes tests avec les autres solutions m’ont donné raison. Toujours avec moi ? On passe au WSGI !

le WSGI

WSGI is the Web Server Gateway Interface. It is a specification for web servers and application servers to communicate with web applications (though it can also be used for more than that). It is a Python standard, described in detail in PEP 333.

le WSGI, c’est le standard pour le Web Python. Il n’y a qu’à consulter wsgi.org pour se rendre compte que c’est tout un monde. Il consiste en un ensemble de normes (nom de variables, par exemple) pour permettre au serveur d’exécuter un fichier codé en Python.

Le standard pour le WSGI sur les serveurs HTTP grand public, c’est le mod_wsgi de apache2. Il a été porté sur nginx, mais c ‘est une #@!## infame, qui ne marche que sur les vieilles versions et qui n’a pas été mise à jour depuis bientôt 2 ans et demi (cf. hg.mperillo.ath.cx/nginx/mod_wsgi/). J’ai obtenu des performances d’environ 133 requêtes par seconde avec, ce qui est déjà mieux que FastCGI, pour ceux qui suivent . Par contre, dès que j’ai voulu avancer un peu avec (toucher à la configuration, et surtout, passer à une version supérieure de nginx), j’ai été confronté à ses limites (et aux #@!## de faute de frappe dans le code source)

D’autant plus que l’auteur de mod_wsgi pour apache2 et l’auteur de mod_wsgi pour nginx reconnaissent ses limitations, respectivement ici et ici. Le premier document est très intéressant pour comprendre un peu l’architecture de nginx et ses différences avec apache2. En effet, le mod_wsgi pour nginx a été codé à partir de celui pour apache2, et il subit les différences d’architecture entre apache2 et nginx.

Attention, je ne remet absolument pas à cause le WSGI ici, juste l’implémentation de mod_wsgi dans nginx.

Parce que justement, un projet super récent, c’est…. uWSGI ! uWSGI sert à combler le manque de support du WSGI dans nginx, en rajoutant un module, meilleur que mod_wsgi. Il nécessite donc de recompiler nginx. Il y a encore une autre solution, nommée gunicorn, qui ne nécessite pas de recompiler nginx. C’est un serveur HTTP minimal qui gère le WSGI nativement. uwsgi offre plus de fonctionalitées que gunicorn, mais gunicorn a l’air assez dynamique (dans le développement), et est plus facile à utiliser (pas de recompilation, support de Django natif). Au niveau des performances, je me suis amusé à faire cette comparaison :

Comparaison des performances entre uwsgi et gunicorn en fonction du niveau de parallélisme

On constate plusieurs choses :

• Les performances augmentent en utilisant 2 workers à la place d’un, mais au delà, le gain est ridicule, puis inexistant. Le nombre 2 est dépendant du nombre de coeurs de la machine, et le nombre de workers à utiliser ne sera pas le même sous un bi-socket octocore, bien évidemment. Les meilleures performances étaient obtenues en utilisant gunicorn+3workers.
• La différence est vraiment minime, gunicorn est en moyenne légèrement au dessus de uwsgi.
• Ces tests sont réalisés sur une application Django. Les performances augmentent en utilisant des frameworks plus légers comme web.py, bien évidemment.

uwsgi dispose de plus de fonctionalitées, comme par exemple une interface d’administration de serveur wsgi dans Django. Je vais ici expliquer l’installation et la configuration des deux solutions.

Ici je vais couvrir l’installation et la configuration de uwsgi et gunicorn avec Django et web.py, même si c’est bien sur adaptable avec d’autres frameworks supportant le wsgi (liste sur wsgi.org/wsgi/Frameworks).

Installation et configuration de uwsgi

Sous Debian :

1) Rajouter les dépots source, par exemple :

2) Télécharger la source

2) Télécharger uwsgi

3) Modifier le paquet source de nginx pour y ajouter uwsgi. Il faut éditer le fichier nginx-*/debian/rules, trouver le bloc qui commence par ./configure et ou se trouvent toutes les options de compilation, et y ajouter

$(CURDIR)/../uwsgi-0.9.4.2/nginx/ est le chemin vers le dossier du module dans la source de uwsgi

4) maintenant, dans le dossier de la source de nginx, faites (pas besoin de root) :

5) installer le .deb généré ainsi (en tant que root maintenant)

6) Dernière étape : compiler uWSGI (le binaire en lui-même, qui va communiquer avec nginx par le biais du module)

Cette dernière commande (le cp uwsgi_params…) sert à placer un fichier de configuration du module uwsgi exemple dans le repertoire de nginx.

Sous les autres distributions :

Il faut télécharger la source de nginx et de uwsgi, compiler nginx avec le module uwsgi (dans le répertoire nginx de la source de uwsgi), puis compiler uwsgi.

On a maintenant un serveur uWSGI et un nginx avec le module uwsgi. Il va maintenant falloir dire à nginx de transférer les requêtes au serveur uWSGI, avec une commande uwsgi_pass. Par exemple, dans la section server d’un de vos vhost (/etc/nginx/sites-enabled/default, par exemple, sous Debian) :

Il faut ensuite créer une application WSGI, par exemple, pour le framework web.py :

Pour Django :

Nommez ce fichier wsgi.py et placez le dans le repertoire ou vous allez placer votre code (pour Django, dans le repertoire du projet, évidemment). Si vos nerfs n’ont pas encore lâché ici, allez prendre une petite pause de 5 minutes à titre préventif, et reprenez. Maintenant, on va démarrer un serveur uWSGI. Placez vous dans le répertoire de votre fichier wsgi.py, et faites :

Explications : le -s indique ou placer le socket (ça pourrait aussi être une adresse au format hôte:port, pour un usage distant). Le -w wsgi indique de charger le fichier wsgi(.py), le -p2 indique de démarrer 2 processus, et le -L désactive l’envoi des requêtes à stdout (=>flood).

Si vous allez à l’adresse de votre serveur web, vous devriez voir votre application Python en face de vous ! Vous voilà en train d’utiliser nginx+uwsgi+python.

En annexe, je rappelle que uwsgi est aussi utilisable avec apache et lighttpd.

Aussi, dans le dossier source de uwsgi, vous trouverez des templates pour un module d’administration de Django, à installer dans le repertoire des templates de l’administration de Django (si, si).

Installation et configuration de gunicorn

gunicorn est carrèment plus facile à installer. Il est codé en python, donc pas de compilation, seulement un easy_install :

La configuration est tout aussi facile, il suffit de cela dans la configuration du vhost dans nginx :

On démarre ensuite gunicorn. Pour Django, gunicorn dispose d’un support intégré, il vous suffit de vous placer dans le répertoire de votre projet, puis :

Pour web.py, il faut créer un module :

Il faut ensuite démarrer le serveur Gunicorn. En étant dans le repertoire ou se trouve le module web.py (le fichier donc le code vient avant, là, au-dessus, oui), :

Je vous invite à consulter ce lien : gunicorn.org/tuning.html, pour vous permettre d’augmenter les performances de gunicorn.

Annexe

Fichiers statiques

Ces deux lignes, à rajouter après le “location /” avec uwsgi_pass ou proxy_pass (selon votre configuration) indiquent à nginx de traiter les fichiers statiques directement. Il faut bien évidemment adapter à votre configuration.

Munin

Vous pouvez trouver des plugins nginx pour munin ici. Je n’ai pas trouvé de plugin munin pour uwsgi/gunicorn, mais je pourrais peut-être en faire un si je trouve le temps.

Plusieurs serveurs

Si par hasard vous avez plusieurs serveurs gunicorn/uwsgi répartis sur plusieurs machines , vous pouvez les utiliser en déclarant une section

dans nginx, contenant les adresses des serveurs distant (hôte:port ou emplacement du socket) et en utilisant “nom” comme argument à uwsgi_pass et proxy_pass.

Conclusion

Ces deux architectures sont très pratiques pour faire tourner du python dans un serveur web, ici nginx. uwsgi dispose de plus de fonctionalités, mais la plupart (template d’admin Django, memory profiling) pourraient facilement être ajoutées à gunicorn, qui est beaucoup plus léger à installer/configurer/maintenir (2 commandes et 3 lignes de configuration dans nginx). J’ai les deux personellement sur mon serveur, j’ai eu à alterner entre les deux pour écrire cet article, et c’est pas bien dur, un daemon à arrêter, un autre à démarrer, et changer une ligne dans la configuration de nginx.

Liens

wsgi.org

gunicorn.org/

projects.unbit.it/uwsgi/

irc.freenode.org/#gunicorn

nginx.org/

djangoadvent.com/

www.django-fr.org/

www.djangoproject.com/

webpy.org/

Je tiens à remercier la communauté Geek{node|fault}, le chan irc #gunicorn, les développeurs de gunicorn qui sont très aimables, ainsi que Amandarn qui m’a aidé pour certains détails.

Si vous avez aimé ce post...

1. Serveur Lighttpd avec PHP sur iPhone
2. Le tunnel SSH facile
3. SSH sans mot de passe

Attentifs à son existence post-buzz, nous avons déjà couvert sa naissance sur Linux, le début de son apprentissage, et le moment semble venu de marquer un nouveau chapitre dans l’évolution du navigateur : l’adolescence.

Au risque de synthétiser les deux premiers articles, il semble nécessaire de ré-établir le contexte et la genèse de ce projet, afin de mieux en comprendre le parcours.

Attention : Cette page reprends ma vision personnelle du contexte de la sortie de Chrome/Chromium et a pour objectif de poser le décor pour la suite de l’article. Cette page n’engage donc que moi et n’est pas nécessaire à la suite de l’article, si vous n’êtes pas d’accord avec mon point de vue, ne vous énervez pas : passer à la page 2

Avant la conception

Le monde des navigateurs n’était pas rose, Internet Explorer avait le rôle du père violent, un échec total qui ne parvenait à maintenir son autorité que par la force de son poing et la violence de ses pratiques anti-concurrentielles, Safari était ignoré par au moins 90% du marché, Opera était un refuge obscur que l’on trouve presque par hasard, une sorte de soupe de bonnes idées (très) mal arrangées, et de choix intéressants, mais pas concluants.

Et Firefox là-dedans ? Il fut d’abord envoyé par la Mozilla Foundation en tant que messie venu se dresser contre l’hégémonie d’Internet Explorer, et prêcher la bonne parole du Logiciel Libre et des standards dans cet océan de code propriétaire.

Firefox fut rapide, Firefox fut efficace, Firefox fut puissant, Firefox fut multi-plateforme, Firefox fut meilleur. Il engrangea ainsi à juste titre des utilisateurs par poignées, une solide réputation, un écosystème de plugins et devint même le porte-flambeau de la lute pour la percée du Logiciel libre au delà de Linux, au delà des geeks : dans la vie quotidienne du grand public, au nez et à la barbe des logiciels propriétaires.
(petit témoignage humoristique représentant la place de Firefox dans nos esprits en ces temps-là)

Mais ce qui s’apparenta d’abord à de l’adoration et à de l’amour inconditionnel, commença à perdre de sa fraicheur à partir et au delà de Firefox 2.0. Il commença à perdre de sa légèreté, à traîner la patte, à s’approprier toute la mémoire RAM de nos systèmes et la retenir en otage, et à ne plus convenir à de plus en plus d’utilisateurs. Alors, tout naturellement (et surtout sous Linux), chacun partit en quête d’un navigateur plus léger, plus rapide, quitte à sacrifier quelques avantages de Firefox, mais à travers les 4 ou 5 petits projets inaboutis, chacun revint bredouille et se rendit à deux évidences : “Firefox reste un excellent navigateur”, et “Il n’existe pas d’alternative viable à l’Alternative.”

Et peu à peu, les utilisateurs se rendirent compte que la concurrence au sein des alternatives à Internet Explorer et aux navigateurs propriétaires était tout simplement inexistante, et que chacun avait un choix simple à faire : “Le mal, ou Firefox.”

naissance d’un navigateur, d’un buzz et d’un imparfait.

L’annonce et la sortie initiale de la toute première mouture du navigateur firent un fracas monumental. Ce que Google annonçait était purement et simplement une alternative à Firefox, et ses points forts et principaux arguments étaient très exactement les reproches faits à Firefox : la gestion de la mémoire RAM, la réactivité, la vitesse des rendus, le moteur JavaScript. Chrome les réalisait d’emblée.

Les frustrés et les curieux se jetèrent sur Chrome et déclarèrent dans les premiers jours avoir définitivement abandonné Firefox, et fait de Chrome leur navigateur par défaut. Dans les premiers jours seulement car comme notre premier article sur l’arrivée de Chromium (le parent/jumeau Opensource de chrome) sur Linux l’indiquait, même plus d’un an après la sortie du navigateur, ses carences en faisaient plus une PoC (Proof of Concept) qu’un navigateur viable dans la vie de tous les jours, c’est ainsi que le buzz s’éteignit, et que seuls les utilisateurs les moins exigeants continuèrent de l’utiliser quotidiennement.
Le pic d’utilisation de Chrome retomba largement, et tout le monde ou presque se retourna vers Firefox.

Malgré les désenchantements, Chromium était là, et alors qu’il luttait contre l’oubli, certains, dont une partie de la rédaction de Geekfault, restaient persuadés qu’il devait être suvi car il n’avait pas seulement sa place, mais était une nécessité dans l’équilibre concurrentiel des navigateurs.

Désolé, à cause de limitations techniques nous ne pouvons pas afficher la suite de cet article dans le flux RSS. Rendez-vous directement sur Geekfault pour lire la suite

Si vous avez aimé ce post...

1. Chromium, le Google Chrome sous Linux sans émulation
2. La maturation de Chromium
3. La recherche web… sans Google!

Un attaquant vera son adresse IP inscrite dans le fichier /etc/hosts.deny l’empêchant de se logguer.

Installation

Gentoo

Debian et dérivés

Red Hat et consorts

Configuration

/etc/denyhosts

Puis pour le lancer :

Sous Gentoo pour le lancer automatiquement au boot vous devez l’ajouter à votre « rc par défaut » :

Logs

Allons faire un tour dans les logs de DenyHosts pour voir à quoi s’attendre.

Exemple de synchro où l’on récupère des IP à blacklister :

Ajout d’un attaquant + upload au serveur central :

Reset du compteur en cas de login réussi :

Liens

Site officiel
Statistiques mondiales de DenyHosts

Si vous avez aimé ce post...

1. IPv6 pour les nuls^Wgeeks
2. SSH sans mot de passe
3. Mise en place d’un système de backup avec Rsnapshot

Combien de projets sont-ils morts ou ont-ils été paralysés par un défaut de structure, d’ordre et de clarté dans la manière de procéder ?

Freemind, ce n’est pas un nouveau procédé de méditation New-Age à la mode, mais c’est tout de même la solution à ce problème !

Freemind est un logiciel de création de schémas et d’organigrames de type WYSIWYG permettant de structurer graphiquement des idées ou des procédures, c’est à dire à peu près tout ce qui passe par votre tête.

Nous allons ici voir les avantages, pas toujours triviaux, et pourquoi il peut réellement être important de se forcer à représenter ses pensées schématiquement.

Freemind : comment regarder son cerveau dans un miroir, et y mettre un peu d’ordre !

Dans une citation célèbre, souvent attribuée à Einstein, il est dit que “Si tu n’es pas en mesure d’expliquer un concept à un enfant de 8 ans, c’est que tu ne maitrises pas ce concept correctement.”

Le premier intérêt d’une représentation graphique, au delà de tout autre utilité, est d’appréhender ses pensées.
Cela peut paraître stupide, ou inutile, mais la réalité est que, si on prenait la peine de se représenter correctement à soi-même ses propres pensées, avant de tenter de les appliquer ou de les expliquer à quelqu’un, on éviterait souvent de perdre beaucoup de temps à tenter d’expliquer un raisonnement qu’on n’appréhende et donc ne peut exprimer clairement, ou à tenter d’implémenter une procédure qui, sur un schéma correct, se révèle irréalisable, et dont les failles apparaissent comme des guirlandes de noël.

Une preuve ? Un exemple ? Mieux : un témoignage !

Pas plus tard que cette nuit, j’ai tenté de me mettre sérieusement à utiliser les services de réseaux sociaux dont on entends tant parler actuellement.
Mes 4 nominés ? Google Buzz, Facebook, Identi.ca et Twitter.
Mon objectif ? Parvenir à tous les utiliser en même temps, avec un moindre effort, et qu’ils se synchronisent correctement entre-eux le plus possible.

Ceux qui se sont déjà lancés dans ce genre d’initiatives savent à quel point les procédés pour relier deux services qui refusent de se parler (concurrents, par exemple) peuvent être tordus, mais surtout à quel point une structuration sans faille des interactions de ces réseaux est vitale pour éviter des redondances ou des boucles infinies.

Après avoir cassé les dents de mon petit esprit inférieur sur ce problème épineux, j’ai décidé de le représenter sur un bout de papier, ou mieux, sur “ce logiciel dont je dois faire un article Geekfault depuis des mois”, comment je voulais structurer mon réseau.

Ci-jointe, donc, la première itération de mon schéma logique des interactions entre ces différents services.

You're doing it wrong !

Il ne s’agit pas ici (uniquement) d’une inaptitude à utiliser un logiciel de schématisation. J’ai d’ailleurs très exactement reproduit le concept que j’avais en tête.
Là est précisément le problème.
Ce n’est qu’après avoir à moitié schématisé mon plan de pensée, que j’ai compris que si je n’arrivais pas à comprendre mon propre schéma, c’était tout simplement parce qu’il était déjà totalement bordélique dans ma tête, et qu’il devait être repensé from scratch.

C’est ainsi que, en quelques minutes seulement (voire quelques dizaines de secondes), j’ai recommencé mon schéma, en repensant, non seulement sa schématisation, mais également sa structure dans ma tête, et que je suis parvenu à ce simple mais efficace résultat :

La différence est frappante !

• Twitter occupe une position centrale, et est celui qui se charge de propager les mises à jours aux autres services. (flèches bleues)
• Identi.ca est le seul service qui poste des mises à jours à Twitter (flèche rouge)
• Chaque service est en contact avec chaque autre service via Twitter (flèches vertes, représentant des liens indirects)

Une fois qu’on a compris ça, on peut déjà mettre en place le dispositif de façon ordonnée, méthodique et productive, et on peut déjà très clairement apercevoir les implications plus abstraites :

• Tout ce qui est posté par Identi.ca est correctement propagé à tous les services, il doit donc être le service utilisé pour poster des mises à jour.
• On peut poster des mises à jours sur Facebook et Buzz sans qu’elles ne soient répercutées partout à la fois, ces deux services peuvent donc être utilisés pour poster des mises à jours plus personnelles/privées, ou simplement n’ayant pas la prétention de devoir être propagées sur tous les moyens de communications et «spamées» inutilement.

Cette expérience illustre parfaitement que même si je croyais avoir saisi la structure à appliquer, et avoir compris mon raisonnement, une représentation graphique m’a évité de me gratter la tête pendant des heures, et m’a permis de reprendre mes erreurs, qui apparaissaient évidentes en comparant les deux schémas.

Quelques minutes plus tard, mon dispositif était en place, et marchait du tonnerre de dieu. Ils vécurent heureux et eurent beaucoup de followers !

Désolé, à cause de limitations techniques nous ne pouvons pas afficher la suite de cet article dans le flux RSS. Rendez-vous directement sur Geekfault pour lire la suite

Si vous avez aimé ce post...

1. Faire planter le Weechat de votre correspondant
2. Minimeter : votre quota de téléchargement en permanence sous les yeux
3. Mise en place d’un système de backup avec Rsnapshot

Vous vous souvenez dans l’article : http://geekfault.org/2009/12/31/construire-sa-gateway-from-scratch/ Je vous ai parlé de plein de petits ajouts afin de rendre votre eeegw MUST.

Je vous avais parlé de :

Pouvoir mettre en place un proxy transparent pour votre connexion pour mettre en cache les pages les plus souvent demandées et ainsi économiser de la bande passante.

Finalement j’ai trouvé le soft parfait pour faire ça : http://www.pps.jussieu.fr/~jch/software/polipo/

Choix du soft de proxy cache

Pourquoi ne pas avoir choisi squid ?

- Parce qu’il est trop gourmand en ressource pour la eeegw.
- Parce que sa conf est imbittable pour un non initié.

Pourquoi avoir choisi Polipo ?

- Parce qu’il consomme que dalle en ressource et en espace disque.
- Parce que sa configuration est assez implicite.
- Polipo à toutes les fonctions d’un bon web proxy.
- Polipo est parfaitement adapté aux petits reseaux, mais pourrait parfaitement fonctionner sur un gros réseau bien qu’il n’ai pas spécialement été design dans ce but.
- Polipo sait filtrer, ainsi si on souhaite totalement interdire facebook.com ou msn.con/live.com sur son reseau On peut très facilement.
- Polipo sait causer ipv4 et ipv6, Ainsi polipo peut être utilisé en tant que bridge pour permettre aux clients ipv6 d’accéder à l’internet v4 et vis et versa.
- Polipo sait parler SOCKS, ainsi il peut très facilement se coupler (ou s’accoupler au choix :p) avec tor afin de surfer de façon anonyme.

Installation et configuration de Polipo

Sur eeegw rien de plus simple :

Allé on va le configurer : /etc/polipo/config

/etc/polipo/forbidden

Laissez le fichier option de base.

On peut faire feu

http://ip.eeegw:8118/polipo/

Vous pourrez ainsi voir la configuration ainsi que pas mal de chose étant mis en cache.

http://ip.eeegw:8118/polipo/index?

Le choix s’offre à vous

Deux solutions :
- Soit vous dites à vos clients d’utiliser dans leur firefox/chromium comme proxy : ip.polipo:8118
- Soit via une règle iptables vous dites simplement à votre eeegw que tout traffic sortant via le port 80 doit d’abord passer par polipo.

Croyez moi vous allez économiser de la bande passante

Si vous avez aimé ce post...

1. EeeGW : Créer soi-même une passerelle réseau

Je vais ici vous parler de Munin.
C’est un outils de génération de graphs basé sur rrdtool.
Il permet de grapher toute sorte de chose vachement bien, et comme j’en suis pleinement convaincu, je vais vous le présenter ici.
L’intégration de plugins supplémentaire afin de grapher des choses non prévu à la base est enfantine.
Il existe pas mal de munin publique qui peuvent vous permettre de vous rendre compte de la puissance de l’outils.
Allez par exemple visualiser : https://supervision.globenet.org/munin/

Geeknode génére sa page statistique grace à des plugins Munin homemade également :
Allez visualiser : http://www.geeknode.org/statistiques.html

J’espère ainsi vous avoir donné l’envie d’aller voir plus loin avec ce soft très bien fait.

Munin se décompose en 2 parties :

Le grapheur munin sur une machine qui va se charger de la surveillance, c’est la machine qui va s’occuper d’interroger tous les nodes, et de générer les graphiques à partir des fichiers rrd collectés.

Le démon munin-node sur chaque machine qui va fournir son état au grapheur.

Evidement, si vous n’avez qu’un seul serveur vous aurez a exécuter munin-graph et munin-node sur la même machine.

munin-node.conf doit binder sur 127.0.0.1 (host) et n’a pas besoin d’accepter autre chose que 127.0.0.1 (allow) dans le cas d’une machine simple.

Si vous avez plusieurs machines à grapher vous devez bien sur écouter sur une ipv4 publique afin que le grapher puisse récupérer vos données.

Pour firewaller munin-node :

On install munin-node sur les machines à surveiller

MUNIN-NODE est à installer sur toutes les machines que l’on veut grapher.

Installation du daemon munin-node sous Gentoo :

Installation du daemon munin-node sous Debian

Configuration du daemon munin-node

On importe les plugins sous gentoo :
On ajoute les plugins de base
Sous debian les plugins de base en fonction des services tournant sur la machine sont par defaut activés.

On ajoute les plugins apache

On autorise le serveur à grapher à accéder au munin-node

* /etc/munin/munin-node.conf
allow ^IP\.PRIVE\.DU-SERVEUR-QUI-GRAPH\.ETH1$

* au passage on bind le munin-node sur eth1 aussi, ça évite d’écouter inutilement sur toutes les autres interfaces
host IP.PRIVE.DE.CETTE.MACHINE

Exemple de fichier munin-node.conf

Installation du grapheur

Sous Gentoo :

Sous Debian :

Exemple de fichier munin.conf

crontab

Une crontab doit logiquement s’etre ajouté lors de l’installation sur le grapher pour l’utilisateur munin :

Si la crontab ne s’est pas mise en place rajoutez la.

Exemples de graphs

Et enjoy les supra bien graph )

Si vous avez aimé ce post...

1. nginx et python – le perfect setup
2. EeeGW : Créer soi-même une passerelle réseau

Si vous vous sentez l’âme d’un geek.
Si vous avez des projets open source qui vous tiennent à cœur à présenter.
Si vous avez l’âme d’un rédacteur d’article.
Si vous vous sentez seul et souhaitez partager vos découvertes glanées sur la toile.
Si vous pensez qu’il est plus important de partager la connaissance que d’en avoir réellement

Dans ce cas, vous êtes fait pour être rédacteur Geekfault.

Proposez nous des articles en commentaire avec un email valide, et nous vous contacterons si vos idées nous plaisent.

Si vous avez aimé ce post...

1. Nouveautés sur Geekfault
2. Migration de Geekfault
3. Baisse d’activité de Geekfault

Qu’est-ce qu’IPv6 ?

Comme vous le savez certainement, Internet aujourd’hui repose essentiellement sur IPv4. Pour lui succéder, IPv6 (ou IPng, bien que cette deuxième dénomination soit moins fréquente) a été conçu il y a bien longtemps déjà. Sa mise en service était prévue en 1996 !
Bizarrerie d’Internet, IPv5 n’a pas grand chose à voir avec les deux autres ; pour les curieux, il s’agit du Stream Protocol ST-II, qui est décrit ici.
Alors qu’une adresse IPv4 ressemble à 81.93.247.142, une adresse IPv6 ressemble plutôt à 2001:758:1664::42 … mais nous y reviendrons plus tard.

Pourquoi remplacer IPv4 ?

Disons-le tout net, IPv4 marche encore très bien (aux dernières nouvelles en tous cas). Mais comme une adresse IPv4 est codée sur 32 bits, IPv4 ne peut adresser que 2³² hôtes, soit un peu plus de 4 milliards de machines diverses et variées. La quantité d’adresses disponibles, qui semblait suffisante il y a 30 ans, diminue constamment, sans compter qu’une bonne partie de ces adresses sont réservées et ne peuvent être allouées. Selon certaines estimations, l’espace d’adresses IPv4 sera épuisé d’ici 2011/2012.

Par ailleurs, la plupart des FAI grand public attribuent en général UNE adresse IPv4 publique par abonné … et encore. Si vous êtes derrière un routeur ou une *box, sauf cas particulier, vous pouvez dire adieu à l’adresse IP publique : le routeur fera probablement du NAT (Network Address Translation). Et s’il s’agit d’une connexion Internet mobile, là encore, il n’y aura probablement pas d’IP publique au bout de la ligne.
Or, selon la définition que l’on donne à Internet, ne pas avoir d’adresse IP publique c’est ne pas être sur Internet (c’est en tout cas l’opinion de Benjamin Bayart, président de FDN).
Par ailleurs, le NAT c’est bien gentil, mais ça complique très nettement la vie dès qu’il s’agit de faire du peer-to-peer (la technologie au sens large) ou de la VoIP par exemple.

Enfin, de façon générale, IPv6 apporte de nombreuses améliorations par rapport à IPv4 : il a été conçu de manière à permettre une répartition plus facile de son espace d’adressage, à effectuer un routage plus efficace, à mieux supporter le multicast ou encore à intégrer un concept de mobilité pour les terminaux nomades : autant de bonnes raisons de migrer !

Désolé, à cause de limitations techniques nous ne pouvons pas afficher la suite de cet article dans le flux RSS. Rendez-vous directement sur Geekfault pour lire la suite

Si vous avez aimé ce post...

1. Geekfault disponible en IPv6
2. DenyHosts pour empêcher le bruteforce sur SSH
3. Firmware modifié pour Linksys WAG200G

Voici donc une petite présentation de cet évènement où les rédacteurs Geekfault seront bien sûr présents.

Un meeting internationnal

Très jeune déjà (en 2004, j’avais presque 14 ans!) j’ai commencé à participer à ce genre de conférences aux Rencontres Mondiales du Logiciel Libre. Mais je me suis vite rendu compte que cet évènement n’avait de Mondial que le nom : tout le monde était francophone !

Ce n’est que quelques années plus tard que j’ai découvert les FOSDEM, pourtant organisées dans ma propore ville. Et là ce fut la révélation : un forum en anglais dans une ville aussi centrale que Bruxelles était une bien meilleure idée!

Chaque année on y retrouve ainsi des développeurs, personnalités et organisations du Logiciel Libre venant des 4 coins du monde. Citons par exemple des développeurs de Mozilla, la Free Sofware Foundation et Richard Stallman. Les FOSDEM sont aujourd’hui considérées comme « le meilleur évènement du logiciel libre et gratuit en Europe ».

Programme

Le FOSDEM a lieu sur un week-end : les samedi 6 et dimanche 7 février 2010 dans les locaux de l’Université Libre de Bruxelles (campus Solbosch). Le programme est constitué de conférences, de débats et les couloirs sont parsemés de stands permanents.

Il y a aussi des séances de “travaux pratiques” pour découvrir différents langages de programmation, protocoles et API mais elles ne sont pas encore référencées sur le site. Finalement, les plus motivés peuvent même passer des examens pour obtenir par exemple la certification LPI.

En dehors de ces journées de conférences, vous pouvez visiter la ville et la soirée du vendredi au samedi, organisée au Délirium Café est devenue incontournable! (C’est un célèbre bar bruxellois avec plus de 2000 bières à la carte et où chaque année Google en offre quelques unes )

See you there!

Alors si vous souhaitez rencontrer la rédaction de Geekfault IRL et assister à des conférences/débats intéressants autour du Logiciel Libre, n’hésitez pas à nous rejoindre! Avec Koolfy, bragon, Tito, target0, roidelapluie et Tycale, nous resterons connectés sur IRC :

• irc://irc.geeknode.org/geekfault
• irc://irc.geeknode.org/fosdem

Liens

• Le site du FOSDEM 2010
• Le programme
• Plans d’accès

Aucun post similaire.

Je vous présente via cet article ma transformation d’un EeePC, qui ne me servait à rien, en routeur-passerelle réseau. Je vous présente mon travail, mais il est très facile d’adapter ce travail à votre utilisation et à votre propre machine afin de la transformer en un super routeur Linux qui tue tout

Article illustré par l’exemple

Cette documentation est adapté à mon LAN qui est paramétré sur le subnet 10.0.69.0/24. Le eeegw, comme je l’appelle, prend donc l’adresse 10.0.69.250/24 est sera la gateway de mon réseau afin que mes autres machines puissent accéder à l’internet.

À quoi ça sert de monter sa propre Gateway ?

• Ne pas avoir à redémarrer sa connexion internet chaque fois qu’on a envie de toucher aux règles de firewalling. En effet les box des FAI nécessitent de redémarrer pour prendre en compte de nouveaux paramètres
• Ne pas avoir une boite noire à la place de routeur : on peut surveiller son réseau et savoir quels sont les packets qui y passent
• Pouvoir loguer via iptables et ulogd par exemple (futur article)
• Pouvoir grapher via rrdtool / Mrtg la bande passante qui passe par vos liens
• Pouvoir héberger un petit blog (par exemple) directement sur votre passerelle
• Pouvoir mettre en place un proxy transparent pour votre connexion pour mettre en cache les pages les plus souvent demandées et ainsi économiser de la bande passante (futur article)
• Savoir exactement ce qui se passe avec votre connexion internet
• Mettre en place des outils de détection d’attaques sur votre réseau via SNORT (futur article)

Choisir le bon matériel

N’importe quel ordinateur avec un tant soit peu de puissance est suffisant pour faire un bon gateway, il suffit que cette machine soit munie de plusieurs interfaces réseau.

Durant des années j’ai eu en tant que passerelle un PII 266Mhz muni de 128MB de ram et d’un disque dur de 2Go. Pour cette nouvelle gateway j’ai choisi le EeePC 7″ que j’ai baptisé eeegw

Pourquoi ce choix? Parce que le EeePC dispose de beaucoup d’avantages à être transformé en Gateway :

• Il est muni d’une batterie donc non affecté par une coupure de courant éventuelle
• Il dispose d’une interface réseau ethernet et d’une interface wifi
• La carte wifi intégrée est une Atheros et supporte donc (via le pilote madwifi) les multi wireless WAN
• Sa puissance est honorable (512 de RAM / 900Mhz / 4Go de SSD)
• On peut très facilement installer une distribution GNU/Linux dessus
• On peut installer un serveur web dessus en toute tranquillité
• Son matériel est pleinement supporté par le noyau Linux
• Sa consommation est très faible, permettant donc d’être allumé 24/24 sans détruire son budget EDF

Installer la bonne distribution

Si comme moi vous souhaitez transformer un EeePC, je vous conseille Debian. Personnelement j’aurais bien choisi Gentoo, mais le EeePC prendrait trop de temps à compiler, et ne refroidit pas spécialement bien.

Installer la distribution Debian sur un EeePC est très bien documenté, il vous suffit de créer une clée usb bootable. Je vous renvoie à la documentation de Debian : EeeDebian.

Glossaire des packets Debian nécessaires pour ce howto

• iproute
• iptables
• apache2
• munin munin-node
• wireless-tools

Désolé, à cause de limitations techniques nous ne pouvons pas afficher la suite de cet article dans le flux RSS. Rendez-vous directement sur Geekfault pour lire la suite

Si vous avez aimé ce post...

1. EeeGW – ZE retour du détour ! – Proxycache.
2. Firmware modifié pour Linksys WAG200G
3. Partager la connexion de son laptop

Dimanche soir, une panne de courant à Equinix Saint-Denis, notre datacenter à Paris, a engendré une coupure d’un peu moins d’une heure. Lorsque le courant est revenu, Geekfault est aussi revenu en ligne sans soucis.

Ce n’est que vers 3h30 du matin que notre serveur, Xanadu, est réellemment tombé.

C’est apparemment la carte Raid (qui permet de répliquer nos données sur deux disques durs différents) qui a grillé. Avec notre chance inouïe de lundi matin, cela a aussi grillé un des deux disques durs. Un simple remplacement des pièces aurait dû suffire, puisque le disque dur encore fonctionnel est censé être la réplique exacte de l’autre.

Mais étrangement ce second disque dur n’était plus synchronisé depuis le 18 octobre! Nous n’avions pas d’autre choix que de restaurer ces données vieilles de plus de deux mois… Heureusement nous avons aussi un script qui envoie par mail deux backups de la base de données par jour.

Putain de loi de Murphy

Apparemment le script de backup se croit tout-puissant et prend congé le dimanche >_<. Aujourd'hui je n'ai donc pu restaurer que le backup le plus récent que j'aie, c'est-à-dire datant du 19 décembre 21h42.

Résultat: Nous avons perdu un super article de bragon, expliquant comment il avait transformé son EeePC en routeur réseau, ainsi que tous les fichiers depuis le 18 octobre, ce qui inclut une vingtaine d’images de différents articles.

Nous espérons pouvoir vite réécrire les parties manquantes de l’article et réillustrer nos articles. Merci de votre patience!

Si vous avez aimé ce post...

1. Geekfault recherche des partenaires
2. Geekfault disponible en IPv6
3. Migration de Geekfault

Depuis cette annonce, nous n’avions plus de nouvelles. Mais au début du mois dernier ProcessOne annonçait avoir découvert un serveur XMPP hébergé sur chat.facebook.com !

Attention : Cet article est sujet aux trolls sur l’utilité des réseaux sociaux

Une vieille idée

Facebook a lancé son système de chat le 7 avril 2008, via son interface web. Dès le début on s’est vite rendus compte qu’elle n’était pas très stable et nous obligeait à garder l’onglet Facebook ouvert en permanence.

Et le 14 mai, un développeur annonce qu‘ils développent activement une interface XMPP compatible avec ce chat. Pourtant, depuis ce post, on n’en a plus entendu parler (malgré les nombreux groupes, wish reports et lettres ouvertes le réclamant).

Mais une très bonne idée

Dès le lancement du chat Facebook, celui-ci a rencontré un grand succès. Après tout, quel est l’intérêt d’un IM si ce n’est de parler avec ses amis? Et Facebook connait, à priori, une grande partie de ceux-ci. J’ai personnellement remarqué que la plupart de mes contacts avaient délaissé MSN pour n’utiliser plus que ce chat Facebook.

Mais évidemment on se heurte vite aux limites des web-apps : lenteurs, instabilités, utilisation d’un navigateur, absence de notifications et encore instabilités! Je suppose que c’est ce qui a motivé les développeurs à utiliser un vrai protocole de messagerie instantannée.

Le XMPP

Le serveur de chat de Facebook découvert par ProcessOne a été déployé sur chat.facebook.com (port 5222, port standard serveur-client pour Jabber) et répond aux requêtes de type XMPP!

Nous ne pouvons que saluer le choix de Facebook pour ce protocole libre et déjà supporté par une multitude de clients de messagerie instantannée, aussi bien desktops que mobiles!

Le XMPP n’a malheureusement jamais connu le succès escompté, loin derrière Yahoo! Messenger et Microsoft Live Messenger aux protocoles propriétaires mal implémentés dans nos logiciels libres. Facebook va peut-être redorer un peu le blason de ce protocole délaissé en lui apportant ses 350 millions d’utilisateurs.

On regrettera tout de même que, selon les scans de ports, Facebook n’a pas activé le server-to-server qui aurait permis aux utilisateurs du chat Facebook de communiquer avec des utilisateurs de réseaux Jabber concurrents et vice-versa.

À quand le déploiement public?

Même si le serveur de type ejabberd modifié répond aux requêtes de connexion, il répond toujours par la négative. Facebook n’a pas encore fait d’annonce publique, sans doute parce que le service est actuellement en phase de tests.

L’existence de ce serveur est encourageante, mais on est en droit de se demander si les administrateurs de Facebook valideront sa mise en service puisqu’ils n’ont, à priori, aucun moyen de le monétiser…

Si vous avez aimé ce post...

1. Serveur Lighttpd avec PHP sur iPhone
2. La petite guerre du Warez
3. Google Wave #1 : C’est quoi Wave?

Categories

Categories permet de créer des dossiers pour classer ses applications. Cette application vous évitera de finir avec 9 écrans d’applications sur votre SpringBoard.
Je l’ai utilisé sur mon iPhone pour créer trois répertoires : Réseau, Jeux et Système. Ce classement simple me permet de n’avoir que deux écrans sur mon Springboard. A noter qu’on peut très bien placer un dossier dans un autre.

Source: BigBoss (http://apt.bigboss.us/repofiles/cydia/)

Flashlight

Flashlight est une application qui affiche simplement un écran blanc. Contrairement aux versions officiellement disponibles sur l’AppStore, cette version disponible dans Cydia augmente la luminosité du rétro-éclairage au maximum, transformant votre iPhone en une lampe de poche d’appoint incroyablement efficace.

Source: BigBoss (http://apt.bigboss.us/repofiles/cydia/)

Notifier

Notifier est un ajout à MobileSubstrate que j’aimerais beaucoup voir intégrer dans la prochaine version du firmware tellement il est pratique et, forcément, indispensable. Il ajoute dans la barre des tâches (à côté du niveau de batterie) des icônes si vous avez des SMS, MMS, e-mails et même messages instantannés non-lus, des appels manqués ou encore des rendez-vous en cours dans votre calendrier.

Source: BigBoss (http://apt.bigboss.us/repofiles/cydia/)

asVibra2

Vous aussi avez l’impression de rater des e-mails et SMS lorsque votre iPhone est en silencieux parce qu’une vibration ne suffit pas? Ce petit tweak permet de faire vibrer trois fois votre iPhone lors de la réception d’un message.

Source: iPhone-Storage.de (http://apt.iphone-storage.de/)

LockInfo

Un des trucs les plus frappants dans l’interface de l’iPhone c’est l’inutilité du “LockScreen”, la page avec le slide “Déverouiller”. LockInfo a pourtant transformé cet écran inutile en un des écrans que je consulte le plus souvent puisqu’il m’affiche mes prochains rendez-vous, mes SMS et mails non lus ainsi que mes appels manqués. Si vous êtes adeptes de WinterBoard vous pouvez même lui appliquer des templates pour améliorer son design déjà très soigné (je vous conseille Black Motion).
Cette application bien utile est malheureusement payante (5$) après une période d’essai de 14 jours… sauf si vous trouvez le crack sur Google.

Source: ModMyi.com (http://apt.modmyi.com/)

Custom HomeButton

Apple nous laisse déjà choisir l’utilité du double clic sur le bouton Home (bouton principal), mais on n’a le choix qu’entre 5 possibilités. Custom HomeButton permet de lier le double-clic à n’importe quoi, que ce soit une application de l’AppStore, de Cydia ou même une page web. Je l’utilise pour lancer Flashlight

Source: iSpazio (http://ispaziorepository.com/)

CyDelete

Cette application ajoute la croix de désinstallation qu’on connait bien pour les applications de l’AppStore, mais pour les applications Cydia. Indispensable pour tous les accros de Cydia

Source: BigBoss (http://apt.bigboss.us/repofiles/cydia/)

Cyntact

Cyntact est un tweak qui affiche les photos dans les listes de contacts. Cyntact est même actif dans les applications tierces qui utilisent la liste de contacts. Cette application de Saurik est malheureusement payante (1$), mais sans DRM

Source: Telesphoreo (http://apt.saurik.com/)

Veency

Veency est l’application qui m’a le plus impressioné dès son installation. C’est tout simplement un serveur VNC pour iPhone! Très pratique pour prendre le contrôle de son iPhone à distance mais le meilleur c’est tout simplement de pouvoir utiliser le clavier de son laptop pour taper par exemple des SMS sur son iPhone!

Source: Telesphoreo (http://apt.saurik.com/)

Installous

Je ne pouvais pas finir cet article sans vous le présenter : Installous permet d’installer des IPA crackés directement sur votre iPhone. Un navigateur intégré vous connecte directement à la version mobile d’Appulo.us. Et pour couronner le tout, Installous permet de synchroniser automatiquement ces nouveaux IPA avec iTunes!

Source: Hackulo.us (http://cydia.hackulo.us/)

À noter qu’une nouvelle version maintenue par puy0, renommée Install0us, permet de télécharger les IPA en arrière-plan et donc en télécharger plusieurs à la fois. Celle-ci n’est malheureuement pas maintenue par Hackulo.us et il faudra donc installer son repository dédié : http://cydia.install0us.com.

Si vous avez aimé ce post...

1. Serveur Lighttpd avec PHP sur iPhone
2. Internet sur votre laptop via un iPhone
3. iPhone OS 3.0

En effet aujourd’hui je préfère faire confiance à Google pour conserver mes messages plutôt que risquer la perte de ceux-ci après un crash de mon disque dur. Mais comment tout de même faire un backup mensuel de mon compte Google Apps?

Gmail Backup

Je suis tombé sur un projet intéressant : Gmail Backup, compatible Windows et Linux. Pour Linux vous aurez le choix entre la ligne de commande et une petite interface en wxPython.

L’interface graphique est très simple d’utilisation puisqu’elle vous demande votre adresse Gmail, mot de passe et dossier où enregistrer le backup. On peut éventuellement demander de ne sauvegarder qu’une certaine période dans le temps.

L’interface en ligne de commande est tout aussi puissante, et très pratique si vous souhaitez faire vos backups sur un serveur SSH.

• Sauvegarder tout le compte :
  ./gmail-backup.sh backup /dossier/où/backup user@gmail.com password
• Sauvegarder du 28/02/2008 au 31/08/2009 :
  ./gmail-backup.sh backup /dossier/où/backup user@gmail.com password 20080228 20090831
• Restaurer un backup :
  ./gmail-backup.sh restore /dossier/où/backup user@gmail.com password

IMAP Backup

Personnellement j’ai une confiance totale en Google pour conserver mes données (Troll inside). Si toutefois vous êtes chez un autre prestataire, le seul moyen efficace que j’aie trouvé pour faire un backup est d’utiliser un client e-mail tel que Thunderbird.

Si vous êtes intéressé par un tel backup, je vous renvoie à d’autres sites:

• En anglais et très bien illustré
• Ou en français si vous êtes vraiment allergique à l’anglais

Si vous avez aimé ce post...

1. Mise en place d’un système de backup avec Rsnapshot
2. Plowshare : MegaUpload, RapidShare et autres en CLI
3. Google Wave #1 : C’est quoi Wave?

Dans cet article, tap0 est l’interface du serveur VPN. C’est via cette interface qu’on réalise le lien. La première étape est donc d’attribuer une IPv6 à votre interface tap0.

tap0 représentant le mode “bridge” d’OpenVPN ,

Nous somme donc sur le même segment Ethernet que le client du VPN. Ainsi, nous pouvons envoyer des trames d’autoconfiguration IPv6 aux clients de notre VPN !

Configuration exemple d’un serveur OpenVPN TCP/TAP

Configuration exemple d’un client OpenVPN TCP/TAP

Vif du sujet

10.0.98.1 (concentrateur VPN) et 10.0.98.4 (client VPN) se pinguent en IPv4 sur le segment ethernet du VPN.
Nous pouvons désormais avancer

• Activons l’IPv6 forwarding sur notre concentrateur VPN
  # echo "net.ipv6.conf.all.forwarding = 1" >> /etc/sysctl.conf
  # sysctl -p
• Activons le proxy NDP (qui va nous servir a relayer les packets IPv6 entre eth0 et tap0)
  # echo "net.ipv6.conf.all.proxy_ndp = 1" >> /etc/sysctl.conf
  # sysctl -p

  Notre Concentrateur VPN est quasiment prêt à forwarder des trames IPv6.

• Installons radvd et configurons-le (/etc/radvd.conf) :
  interface tap0
  {
         AdvSendAdvert on;
         MinRtrAdvInterval 3;
         MaxRtrAdvInterval 10;
  
         prefix 2001:758:f00:x::/64
         {
                 AdvOnLink on;
                 AdvAutonomous on;
                 AdvRouterAddr on;
         };
  };
• Attribuons une adresse IPv6 a notre interface tap0:
  # ip -6 a add  2001:758:f00:x:x::1/64 dev tap0
• Nous pouvons lancer radvd
  # /etc/init.d/radvd start
• Vérifions sur le client que nous avons bien des trames IPv6 qui arrivent (si tap1 est l’interface VPN du côté client)
  # tcpdump -t -n -i tap1 -s 512 -vv ip6 or proto ipv6

  devrait donner des trames ainsi :

  IP6 (hlim 255, next-header ICMPv6 (58) payload length: 56) fe80::94c7:eaff:fe5e:ea46 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 56
          hop limit 64, Flags [none], pref medium, router lifetime 30s, reachable time 0s, retrans time 0s
            prefix info option (3), length 32 (4): 2001:758:f00:8::/64, Flags [onlink, auto, router], valid time 2592000s, pref. time 604800s
              0x0000:  40e0 0027 8d00 0009 3a80 0000 0000 2001
              0x0010:  0758 0f00 0008 0000 0000 0000 0000
            source link-address option (1), length 8 (1): 96:c7:ea:5e:ea:46
              0x0000:  96c7 ea5e ea46
• Notre client VPN obtient une IPv6 grâce au radvd de notre concentrateur VPN (par exemple 2001:758:f00:x:ffff:ffff:ffff:ffff/64)
• Configuration ndp proxy du concentrateur
  # ip -6 neigh add proxy 2001:758:f00:x:x::1 dev tap0
  # ip -6 neigh add proxy 2001:758:f00:x:ffff:ffff:ffff:ffff dev eth0

  Ainsi les packets a destination de 2001:758:f00:x:ffff:ffff:ffff:ffff arrivant sur eth0 seront automatiquement traite par 2001:758:f00:x:x::1 se trouvant sur le meme segment ethernet que 2001:758:f00:x:ffff:ffff:ffff:ffff

• Test de la configuration :
  • Sur le client OpenVPN
    # ping6 2001:758:f00:x:x::1
  • Sur le concentrateur OpenVPN
    # ping6 2001:758:f00:x:ffff:ffff:ffff:ffff

  Si les deux ping6 passent vous pouvez continuer, sinon vous avez un soucis lors d’une des etapes précédentes.

Tests de pings

On peut essayer de pinger Google depuis le client

Et pinger le client depuis une machine hors du VPN

Si tout passe c’est gagné, vous avez donné une connectivité IPv6 à une machine over VPN!

ERRATA

Attention openvpn à chaque connexion attribura dynamiquement et aléatoirement une adresse mac à l’interface tap1 du client du vpn.
Ainsi radvd se basant sur l’adresse mac de l’interface reseau afin d’attribuer une ipv6 pourra poser des problèmes du coté du concentrateur.
En effet il faut lancer la commande permettant au concentrateur via le proxy ndp de forwarder les trames.
C’est donc ultra pas pratique.
Plusieurs solutions s’offrent à vous en outre.
1) attribuer un nouveau subnet ipv6 (autre que celui attribué à eth0) sur votre tap0 du concentrateur vpn, ainsi vous vous évitez toute la partie concernant le proxy ndp.
2) Attribuer des ips fixes aux clients qui devront les donner manulement de leur coté à leur interface.
3) scripter via les scripts up.sh et down.sh fourni avec openvpn en natif.

Annexes

Côté serveur

Côté client

Si vous avez aimé ce post...

1. Geekfault disponible en IPv6
2. Allocation d’adresses IPv4 publiques over VPN
3. IPv6 pour les nuls^Wgeeks

Là, vous avez deux solutions : payer (ce qui peut vite devenir cher si vous passer plus d’une semaine à l’hôtel) ou contourner les limitations. Vous vous rendrez vite compte que, même avant d’avoir payé, tous les hotspots résolvent les DNS… et il ne vous aura pas échappé qu’une résolution de DNS est un échange de données!

Le port UDP 53

Pour faciliter la configuration de ces hotspots, de nombreux administrateurs n’hésitent pas à tout simplement ouvrir le port DNS, c’est-à-dire le port UDP 53. Une solution simple pour accéder à internet serait donc d’avoir un serveur VPN sur ce port.

Malheureusement on tombe souvent sur des hotspots bien configurés, qui n’autorisent du trafic que vers leur propre serveur DNS. Pourtant, vous avez remarqué qu’un

vous a retourné la bonne adresse IP (81.93.247.142 actuellement) et non une adresse IP du hotspot. Vous venez de communiquer avec l’internet!

Échange de données over DNS

L’idée est donc simple : traduire vos “requêtes IP” en requêtes DNS. Un faux serveur DNS va comprendre ces requêtes, les exécuter et retourner la “réponse IP” en réponse DNS! Ce détournement du système DNS est réalisable grâce à NSTX, ou Name Service Transfer Procotol qui crée un véritable tunnel IP entre votre laptop et votre serveur, grâce aux requêtes DNS.

Par exemple vous essayez de vous connecter à Geekfault.

• Firefox génère une requête HTTP vers geekfault.org
• Celle-ci est interceptée par le client NSTX tournant sur le laptop. Il génère une requête vers le domaine KJhjh33.dd_2sT-XXT.dAAoi_f.tunnel.example.com
• Le NSTX tournant sur le serveur reçoit cette requête DNS et décode le KJhjh33.dd_2sT-XXT.dAAoi_f en “requête HTTP vers geekfault.org”
• Le serveur se connecte alors à geekfault.org et récupère son contenu
• Le contenu récupéré est encodé de la même manière et transmis vers votre laptop en tant que réponse DNS TXT
• Le NSTX tournant sur le laptop décode les données, reformant les paquets IP
• Firefox reçoit les données HTTP, Geekfault.org s’affiche

Mise en place du serveur

Attention il est important que votre vrai serveur DNS et votre serveur NSTX soient sur deux machines différentes, ou au moins sur deux IP différentes. En effet, il faut qu’un vrai serveur DNS fasse pointer le sous-domaine tunnel.example.com vers NSTX. Pour cela, ajoutez à la fin de votre zone DNS

où example.com est votre domaine et 1.2.3.4 est l’IP du serveur où vous installerez NSTX.

Vérifiez que votre kernel est compilé avec le “Universal TUN/TAP device driver support” (dans Network device support) . Installez NSTX, disponible en package pour de nombreuses distributions.

Et il ne reste plus qu’à créer le tunnel côté serveur:

Le client sur le laptop

De la même manière, vérifiez que vous avez le support TUN/TAP dans le kernel et installez NSTX.

Récupérez l’adresse IP du serveur DNS fourni par DHCP (dans /etc/resolv.conf) ainsi que l’adresse IP du routeur (dans route). On crée alors l’autre bout du tunnel et on route le trafic approprié dans celui-ci:

Performances

Vous devriez maintenant être capable de surfer sur le web. Selon le serveur DNS du fournisseur, vous pouvez espérer entre 10 et 60ko/s. Malheureusement les fortes latences de toutes les requêtes empêchent l’utilisation de plusieurs services, dont le SSH. Mais, hé, vous accédez à internet sans vous défaire de 10€

Vous aurez aussi sans doute compris que nous sommes là au bord de la légalité : on exploite en quelque sorte une faille dans le système de hotspot. À utiliser avec précaution et parcimonie.

Si vous avez aimé ce post...

1. Le tunnel SSH facile
2. Allocation d’adresses IPv4 publiques over VPN
3. EeeGW : Créer soi-même une passerelle réseau

Je vous explique ici la mise en place d’une solution d’allocation d’adresses IPv4 publiques over VPN. Je vous recommande d’avoir de bonnes notions en matière de routage avant de vous engager plus loin.

Prérequis

• Un prefix annoncé sur la table globale
• Un routeur (celui qui annonce le prefix)
• Un serveur dédié (qui distribuera les IPs over VPN)

Dans cet article, je prendrai les données suivantes comme exemple :

• Le prefix sera 1.2.3.0/24
• L’adresse publique du routeur (quagga sous FreeBSD 7.x) sera 2.2.2.2
• L’adresse publique du serveur dédié (Linux 2.6) sera 3.3.3.3

Mise en place d’un tunnel GRE

Selon la définition de Wikipédia, « Generic Routing Encapsulation (GRE) is a tunneling protocol developed by Cisco that can encapsulate a wide variety of network layer protocol packet types inside IP tunnels, creating a virtual point-to-point link to Cisco routers at remote points over an IP internetwork. »

Ce tunnel sera établi entre le routeur et le serveur dédié. Il servira à router un subnet vers le serveur dédié. Prenons comme exemple 1.2.3.16/28. Il faut également choisir deux IPs d’interconnexion, qui doivent être des IPs publiques. Ce seront les IPs assignées à chaque bout du tunnel. Choisissons 1.2.3.225 pour le routeur et 1.2.3.226 pour le serveur (ce qui donne 1.2.3.224 comme network et 1.2.3.227 comme broadcast, un /30 donc).

Sur le routeur, voici la procédure à suivre :

• Il faut d’abord s’assurer que le module if_gre soit chargé ou bien compilé en dur. Si ce n’est pas le cas
  # kldload if_gre
• On crée le tunnel
  # ifconfig gre0 create
  # ifconfig gre0 tunnel 2.2.2.2 3.3.3.3
  # ifconfig gre0 inet 1.2.3.225 1.2.3.226 netmask 255.255.255.252
  # ifconfig gre0 up
• Vérifiez également que le forwarding soit activé :
  # sysctl net.inet.ip.forwarding=1

Afin que le tunnel se monte automatiquement au boot, voici les quelques lignes à rajouter dans /etc/rc.conf :

Le tunnel est maintenant prêt côté routeur. Passons à la configuration côté serveur :

• Le kernel doit être compilé avec les options CONFIG_IP_ADVANCED_ROUTER et CONFIG_IP_MULTIPLE_TABLES activées.
• On crée le tunnel
  # ip tun add gretun mode gre local 3.3.3.3 remote 2.2.2.2 ttl 64 dev eth0
  # ip addr add dev gretun 1.2.3.226 peer 1.2.3.225/30
  # ip link set dev gretun up

Le tunnel est maintenant opérationnel et chaque bout devrait être capable de pinger l’autre.

Routage d’un subnet vers le serveur

Côté routeur, il suffit d’ajouter une entrée dans la table de routage :

Côté serveur, il faut effectuer une manipulation un peu particulière. En effet, dans l’état actuel des choses, le serveur dédié risque d’avoir des problèmes s’il utilise une des IPs du prefix 1.2.3.16/28 routé. Supposons que nous avons assigné l’IP 1.2.3.16 à une interface du serveur :

Si on essaye de joindre cette IP depuis l’extérieur (un ping par exemple), les packets arriveront bien jusqu’au serveur (après avoir été routés par le routeur (encore heureux)). Le problème se pose lorsque le serveur essaye de répondre : il va router les packets sortants sur l’interface par défaut et non via l’interface gretun. Cela peut marcher chez certains hébergeurs qui ne filtrent pas l’adresse source des packets sortants, mais cela n’est pas toujours le cas. Et puis c’est plus propre d’avoir la même route pour l’aller que pour le retour. Il faut donc router en fonction de l’adresse source des packets. C’est ici qu’intervient la feature de tables de routage multiple du kernel Linux.

Voici la manipulation à suivre :

La première commande permet d’assigner un nom à un numéro de table (200 est ici un nombre arbitraire, il suffit de prendre un numéro de table qui n’est pas encore utilisé).

La deuxième commande indique que tous les packets dont l’adresse source fait partie du prefix 1.2.3.16/28 doivent être routés en consultant la table de routage “tunnel”.

La troisième commande fait la même chose que la deuxième, si ce n’est qu’elle n’affecte que les packets en provenance de l’adresse 1.2.3.226. Cette commande est nécessaire pour que l’IP d’interconnexion soit accessible depuis l’extérieur.

Enfin, la quatrième commande ajoute la route par défaut inhérente à la table “tunnel”. Les packets utiliseront dorénavant la même route pour joindre le serveur que pour en partir. Il suffit de vérifier :

Le ping devrait se dérouler correctement.

Allocation d’IPs publiques over VPN

Il reste à présent à mettre en place une solution VPN sur le serveur dédié. Après avoir tenté avec OpenVPN, je me suis rendu compte qu’il était incapable de prendre une autre IP principale que le .1 du subnet alloué over vpn. Cela est inacceptable dans notre cas où le subnet alloué commence à partir de .16. Je me suis alors tourné vers vtun et c’est cette solution que je vais exposer ici.

Premièrement, il faut choisir une adresse IP du subnet qu’utilisera vtund. Prenons 1.2.3.17. Une nouvelle règle de routage est ici nécessaire. En effet, les packets ayant comme adresse source 1.2.3.17 doivent être routés vers les interfaces du VPN, et non pas vers gretun comme c’est le cas actuellement :

Cette commande fait une exception de routage parmis le subnet 1.2.3.16/28, indiquant que les packets en provenance de 1.2.3.17 doivent utiliser la table de routage principale et non la table “tunnel”. Il reste alors à rendre possible la communication entre deux IPs du même subnet :

Ceci permet d’éviter que les packets soient envoyés sur l’interface gretun, ce qui est le comportement par défaut pour les packets en provenance de 1.2.3.16/28 selon la règle indiquée précédemment.

Assurez-vous également que la redirection IP est activée sur le serveur :

Voici un exemple de vtund.conf pour le serveur :

On alloue donc l’IP publique 1.2.3.18 au client “user0″.

Voici la configuration correspondante côté client (Linux 2.6, avec les options kernel CONFIG_IP_ADVANCED_ROUTER et CONFIG_IP_MULTIPLE_TABLES activées) :

Quelques explications sont ici nécessaires. Le path indiqué par “ppp” a été modifié pour pointer sur un script permettant de rediriger tout le trafic over vpn. Il est également nécessaire d’ajouter une entrée “200 tunnel” dans le /etc/iproute2/rt_tables du client.

Voici redirectall.sh :

Tout est à présent fin prêt. Lancez le daemon vtun sur le serveur et le client, et vous serez joignable directement sur l’IP assignée. Si vous ne désirez pas rediriger tout votre trafic over vpn, il suffit de commenter les deux commandes ppp dans le up { } et down { } de la configuration client.

Schéma

L’architecture ressemble à ceci :

Remerciements

Merci à bragon, avec qui j’ai initialement mis en place ce système avec le /24 de GeekNode.
Merci à GeekNode pour le /28

Si vous avez aimé ce post...

1. Allocation d’IPv6 over OpenVPN
2. IP over DNS : Contourner les limitations des hotspots
3. Le tunnel SSH facile

Nous sommes donc fiers de vous présenter la version entièrement réécrite de ce script pour télécharger les Guignols de l’Info en cette rentrée 2009!

La technique

Vous vous souviendrez peut-être que notre précédente technique profitait d’une faille de sécurité sur le site de Canal+ : bien que le player exploitait le RTMP, les fichiers étaient toujours accessibles en HTTP. Nous en profitions donc pour simplement wget les différentes vidéos. Évidemment cette année le HTTP est entièrement bloqué et il faut donc passer par le RTMP.

Le hic, c’est que récupérer une URL RTMP relève du parcours du combattant. Mais il y a quelques jours jeantube est passé nous signaler une URL très, très intéressante : http://www.canalplus.fr/rest/bootstrap.php?/bigplayer/search/guignols. Celle-ci correspond, je pense, au résultat AJAX des recherches de vidéo sur le site de Canal+.

Ce qui est génial avec ce fichier, c’est qu’il comporte en clair les URL rtmp://. Il ne nous reste plus qu’à utiliser un petit logiciel nommé rtmpdump pour enregistrer localement le fichier.

Le script

Pour automatiser la tâche, je vous ai rédigé un petit script bash très simple qui à coups de sed et grep récupère l’URL d’un épisode et lance le rtmpdump dessus. Il essaye toujours de prendre la plus haute qualité disponible et s’utilise comme le précédent:

Le script est publié sous GPLv3 et j’ai inclu dans l’archive le binaire rtmpdump distribué sous GPLv2. Le tout se télécharge ici

A noter que le code est très facile à comprendre et devrait être aisément adapté à d’autres émissions publiées sur le site de Canal+.

Remerciements

Je remercie jeantube sans qui nous ne serions nulle part et les quelques acharnés de Chrogeek.com qui ont permis de démêler le schmilblik.

Si vous avez aimé ce post...

1. Télécharger les Guignols de l’Info
2. Plowshare : MegaUpload, RapidShare et autres en CLI