Unicorn et Thin sont deux serveurs pour Ruby assez fréquemment utilisés et cités dans la littérature informatique. A titre d'exemple, Unicorn est utilisé notamment chez Github: une bonne référence ! Thin est souvent cité pour sa robustesse et sa légèreté. Lequel choisir ?

Avant d'envisager le déploiement d'une application en production (prévision de charge : quelques centaines d'utilisateurs simultanément), j'ai souhaité les comparer.

Protocole de test

• Linux Debian Jessie, Core M 5Y10, 4 Go de RAM, disque dur SSD ; les tests sont effectués en local sur la machine et le réseau n'intervient donc pas comme facteur dans le test.
• Le stress test est réalisé avec Gatling (dont j'ai déjà décrit le fonctionnement ici) qui simule l'arrivée de 200 utilisateurs en 120 secondes sur l'application, chaque utilisateur exécute 8 requêtes sur l'application.
• L'application Ruby on Rails (Rails 4.2.1, Ruby 2.2.2) est prête à l'emploi en environnement de production, les 2 gems Thin et Unicorn sont installés et fonctionnels.
• Quand cela est nécessaire, Pound est utilisé comme "load balancer".
• Thin est exécuté avec la commande :

thin -s 4 -e production -p 8080 start

ou, quand on le lance avec un seu

thin -e production -p 8080 start

• Unicorn est exécuté par la commande :

unicorn -c config/unicorn.rb -E production -p 8080

avec pour contenu du fichier de config unicorn.rb une configuration très proche de celle proposée par Github sur cet article :

rails_root = "/path/to/app"
rails_env = ENV['RAILS_ENV'] || 'production'

# 4 workers, may be changed to 1 for the tests
worker_processes (rails_env == 'production' ? 4 : 1) 

# Load rails+app into the master before forking workers
# for super-fast worker spawn times
preload_app true

# Restart any workers that haven't responded in 30 seconds
timeout 30

before_fork do |server, worker|
  ##
  # When sent a USR2, Unicorn will suffix its pidfile with .oldbin and
  # immediately start loading up a new version of itself (loaded with a new
  # version of our app). When this new Unicorn is completely loaded
  # it will begin spawning workers. The first worker spawned will check to
  # see if an .oldbin pidfile exists. If so, this means we've just booted up
  # a new Unicorn and need to tell the old one that it can now die. To do so
  # we send it a QUIT.
  # Using this method we get 0 downtime deploys.

  old_pid = rails_root + '/tmp/pids/unicorn.pid.oldbin'
  if File.exists?(old_pid) && server.pid != old_pid
    begin
      Process.kill("QUIT", File.read(old_pid).to_i)
    rescue Errno::ENOENT, Errno::ESRCH
      # someone else did our job for us
    end
  end
end

after_fork do |server, worker|
  # Unicorn master loads the app then forks off workers - because of the way
  # Unix forking works, we need to make sure we aren't using any of the parent's
  # sockets, e.g. db connection
  ActiveRecord::Base.establish_connection
end

Les résultats

Match 1 : Unicorn vs Thin, avec un seul processus pour chacun

Quand un seul processus (un seul "worker" dans le vocable propre à Unicorn) est activé, l'arrivée ininterrompue de nouveaux utilisateurs charge considérablement l'application...

Voici les résultats du "stress test" :

On observe que :

• Thin parvient à servir tout le monde, mais au prix de temps de réponse assez longs
• Les temps de réponse sont un petit plus courts avec Unicorn mais en revanche Unicorn échoue à servir un certain nombre d'utilisateurs - le résultat du second graphe montre que l'unique worker d'Unicorn arrête de répondre aux requêtes à plusieurs reprises et pendant des durées assez longues... je n'explique pas bien ce comportement... J'ai pensé à l'impact du paramètre 'timeout 30' mais je n'ai pas observé de différence lorsque j'ai porté la valeur du timeout à 300 (j'ai même observé une amplification du phénomène)...
• Thin semble donc vainqueur sur ce match avec un seul processus... mais voyons vite avec plusieurs processus ce qui sera plus proche d'un déploiement réel !

Match 2 : Unicorn vs Thin, avec 4 processus pour chacun

Nous démarrons cette fois Unicorn avec 4 "workers" et 4 instances de Thin. Afin d'accéder de manière aléatoire aux différentes instances de Thin, nous utilisons cette fois Pound comme "load balancer". Pound a également été utilisé avec Unicorn pour rendre les conditions des tests équivalentes. Pound n'est toutefois "en théorie" pas nécessaire pour Unicorn qui répartit automatiquement les requêtes sur les différents "workers".

Place aux résultats :

On constate que :

• Thin et Unicorn parviennent à servir tous les utilisateurs plus efficacement (normal, la multiplication des processus profite des plusieurs coeurs de la machine hôte)
• Mais Unicorn est plus véloce que Thin : 97% des requêtes sont servies en moins de 800ms par Unicorn alors que seules 63% sont servies dans le même délai par Unicorn
• On remarque également que les 4 processus d'Unicorn jugulent le flux des nouveaux utilisateurs avec au pic 24 utilisateurs en attente là où Thin faiblit peu à peu jusqu'à atteindre un pic à plus de 50 utilisateurs en attente dans l'application (pour rappel, dans le scénario testé, 200 utilisateurs se connectent régulièrement au cours des 120 secondes à l'application et exécutent 8 requêtes)
• C'est donc une victoire d'Unicorn qui se tire mieux cette fois de la situation !

Conclusion

Je suis tenté de préférer Unicorn pour servir un site Ruby on Rails chargé. Cependant, il conviendra d'offrir suffisamment de workers à Unicorn pour qu'il puisse faire le travail correctement !

Quelques enseignements annexes :

L'impact de Pound sur les temps de réponse

Sans Pound, le temps de réponse moyen de Unicorn est de 117 ms. Avec Pound, toute autre chose étant égale par ailleurs, le temps de réponse moyen est de 161 ms. Il semble donc que le passage par Pound augmente le temps moyen de réponse d'environ 40 ms.

La multiplication des workers pour Unicorn : bonne ou mauvaise idée ?

La machine de test dispose de 4 coeurs. J'ai testé 4 workers et 16 workers avec Unicorn. Les résultats sont très similaires : respectivement 131 et 130 secondes pour effectuer le scénario de test complet. Les temps de réponse moyens sont là encore très proches : 113 ms vs 117 ms. Je ne pense pas que les différences constatées soient significatives. Les écart-types sur le temps de réponse diffèrent plus : 216 ms avec 4 workers et 265 ms pour 16 workers... Compte-tenu du nombre de coeurs sur la machine de test (4), l'utilisation de 16 workers ne semble pas permettre des gains substantiels. Un petit excès du nombre de workers par rapport au nombre de coeurs est peut-être à conseiller toutefois.

Original post of Pierre-Alain Bandinelli.Votez pour ce billet sur Planet Libre.

bonjour

J'ai le plaisir de vous annoncer la sortie de HandyLinux-2.0 basée sur Debian-8 



Cette version est la première basée sur Debian Jessie et sera supportée aussi longtemps que sa base (5ans minimum).
HandyLinux-2.0 renoue avec ses ambitions d'accessibilité en intégrant le lecteur d'écran ORCA grâce aux tests de totophe56.
Cette version se veut aussi encore plus orientée vers les grands débutants avec une mise à jour complète de la documentation , l'apparition d'une FAQ et une série de tutoriels vidéos passant en revue l'essentiel des fonctions de votre distribution (encore en cours de tournage, mais la plupart sont déjà disponibles).
HandyLinux-2.0, c'est aussi la fusion des versions ancien PC / PC modernes (noyaux 586 et 686-pae) en une seule image ISO avec un outil de suppression semi-automatique du noyau inutile.
Pour cette nouvelle version, Tibérias nous a offert un nouveau thème avec sa page de démarrage internet. Je m'en suis inspiré pour la refonte complète des sites handylinux* ainsi que pour le thème utilisé par défaut dans la distribution, HandyLinuxClear.
Starsheep nous offre les fonds d'écran par défaut ainsi qu'un outil de changement rapide d'interface, le HandyTheme.
Thuban, quant à lui, en nous rejoignant, amène BTshare, un outil de partage de données via BitTorrent, ultra simple d'utilisation, pour partager en "torrent" P2P des données présentes sur votre ordinateur personnel.

Vidéo Officielle

musique : "lil-mel" par Herrera

quelques shots ... ?

Liens de téléchargements :

HandyLinux-2.0 est disponible sur les serveurs SourceForge.net ou sur LinuxTracker pour les utilisateurs du protocole BitTorrent. Tous les liens depuis la page de téléchargement officielle :

=> Téléchargez HandyLinux-2.0 <=

Mise à jour depuis HandyLinux-1.x :

Comment passer de HandyLinux-1.x à HandyLinux-2.x. ?

La méthode la plus sûre est la ré-installation du système . Mais si ce n'est pas possible (pas de disque dur pour la sauvegarde), vous pouvez tenter la mise à jour classique en suivant bien la procédure.

Bugs ?

3 bugs connus  :

• trop de mises à jour après l'installation ? Ne les acceptez pas ! C'est parce que vous avez refusé les mises à jour lors de l'écran de post-installation ou que votre réseau n'était pas configuré. Bref, la solution est simple et tout est expliqué sur le forum .
  
• l'intégration de gnome-orca, le lecteur d'écran, oblige à inclure le serveur "pulseaudio" pour certaines machines. XFCE4-Mixer n'apprécie pas le serveur pulseaudio et si vous diminuez au maximum le volume du canal PCM, ça met le volume général en sourdine. Il faut alors ouvrir XFCE4-Mixer afin de rétablir le volume. Solution ? ne jamais diminuer le son au minimum avec la molette ;)
• Iceweasel est en version ESR ( 31 lorsque j'écris ces lignes ), aucun soucis de sécurité ou de fonctionnement, mais le plugin "hello" n'est pas disponible. Si vous désirez obtenir la version "release" (38) d'Iceweasel, rendez-vous sur le post dédié (merci à fredbezies pour le retour) ... notez que ce bug est résolu par le point n°1
  

le changelog complet :

• mise à jour de la base : passage à Debian-8 "Jessie" (merci Debian)
• mise à jour du handymenu et des outils *handylinux*
• refonte admin du site 'handylinux.org' et mise en place des sous-domaines
• ajout de BTshare, un outil de partage P2P simplifié (merci thuban)
• ajout des actions personnalisées pour Thunar (merci coyotus & thuban)
• passage de Skype en option (merci coyotus)
• intégration de gnome-orca (merci totophe56)
• ajout des lanceurs outils/sociaux/galerie...
• ajout du témoin de mot de passe (merci coyotus)
• définition de "handylinux" comme hostname par défaut (merci fredbezies)
• ajout des Modèles dans le dossier utilisateur (merci dyp)
• ajout de menulibre pour l'édition des menus XFCE
•  ajout de bash-completion (merci torxxl)
• ajout de cups-pdf (merci rb)
• ajout de transmission pour la gestion du partage P2P
• ajout de thèmes pour Iceweasel
• ajout des fonts carlito & caladea (eq. Calibri & Cambria) (merci thuban)
• ajout des modèles et config pour LibreOffice (merci thuban)
• ajout de unoconv pour l'exportation rapide en PDF (merci thuban)
• ajout de anacron et de la configuration apt (merci base10)
• ajout de command-not-found + fix bashrc (merci base10)
• ajout de la notification de mise à jour (merci coyotus)
• kernel :
  
• passage de 486 à 586 pour les vieux PCs
• fusion des version 586 et 686-pae
• ajout du script de détection/suppression du kernel inutile
• theming/graphics :
  
• refonte graphique du site/forum/wiki/blog
• ajout du handylinuxlook
• ajout du HandyTheme pour le changement rapide d'interface (merci Starsheep & thuban)
• nouveau thème Slim "flat" par Starsheep
• nouveaux walls par Starsheep
• ajout de qt4-qtconfig pour vlc
• ajout thèmes d'icônes additionnels (tango, gnome-colors, gilouche)
• modification de l'îcone whiskermenu (merci julien)
• switch :
  
• remplacement du software-center par gnome-packagekit
• remplacement de file-roller par xarchiver
• remplacement de gnome-searchtool par catfish et mlocate (merci Elm et thuban)
• remplacement de quodlibet par clementine
• remplacement de shotwell par ristretto
• remplacement de leafpad par mousepad comme éditeur de texte par défaut (merci coyotus)
• remplacement de xpad par xfce4-notes-plugin pour une meilleure intégration au panel
• nettoyage :
  
• suppression de l'option de placement du HandyMenu en conflit avec XFCE (merci Caribou22)
• suppression des préférences apt obsolètes pour LibreOffice
• suppression des paquets obsolètes ntfsprogs/netatalk/fuse-utils/dfc/xfprint4/gtk3-engines-unico
• suppression de xl-wallpaper : xfce gère maintenant les changement de fonds
• suppression des dépôts compiz-handylinux
• suppression de slingscold-launcher
• suppression de bleachbit
• suppression de zram
• suppression de Minitube
• suppression de phonon
• suppression d'oggconvert
• suppression du win32-loader
• nettoyage des addons Iceweasel
• nettoyage des walls
• suppression des thèmes d'icônes Nitrux/NitruxButtons

Un grand merci à toutes celles et tous ceux qui ont participé à l'élaboration de cette distribution collégiale. Les discussions furent parfois animées, mais ça fait du bien de confronter ses idées et trouver des solutions ensemble.

Je vous laisse maintenant tester HandyLinux-2.0. N'hésitez pas à venir sur notre nouveau forum (le désormais célèbre dyp vous y attend ) afin de profiter du support de la communauté et participer à l'avenir d'HandyLinux au travers de sa collégialité.

... et HandyLinuxLight ?? HandyLinuxLight-2.0 sortira dans le courant de la semaine, il me reste quelques détails à régler pour la post-installation

épilogue ... bye bye le serveur v1 ...

Aujourd'hui, c'est la sortie d'HandyLinux-2.0 et aussi la fin du serveur v1. La redirection est déjà effective... vous n'avez plus accès à l'ancien serveur.

Alors je voulais tout de même dire un grand MERCI à wiscot, Goodbox et Aphelion pour avoir offert, mis en place et maintenu notre serveur dédié .

HandyLinux et toute sa famille sont maintenant réunies sur un seul serveur hébergé en mutualisé chez OVH, ce qui me permet de me concentrer sur la distribution uniquement, et pas sur la surveillance du serveur.

++
arp

HandyLinux - la distribution Debian sans se prendre la tête...

Original post of arpinux.Votez pour ce billet sur Planet Libre.

Une étude réalisée à Saint-Denis (ïle de France), 2012 – 2014

Le projet OLPC a soutenu de nombreux programmes de déploiement d’ordinateurs pour enfants à travers le monde. Les évaluations réalisées montrent notamment que les enseignants et l’entourage de l’enfant ont un rôle à jouer pour favoriser le développement d’usages autonomes et créatifs des ordinateurs portables de type XO. Comme le rappelle Yarosh [Yarosh et al. (2011)], « an entire social ecology needs to be in place for the child to successfully learn and connect« .(« la présence d’un écosystème social complet doit être en place pour que l’enfant réussisse à apprendre »).

Comment les enseignants s’approprient-ils les XOs pour en proposer un usage pédagogique à leurs élèves ?

S’approprier une technologie, la faire sienne, l’intégrer à ses pratiques quotidiennes, semble être un processus lent et progressif, qui passe par de multiples explorations des utilisations possibles des ordinateurs, des adaptations, etc. Qu’en est-il des classes mobiles composées d’ordinateurs portables ?

Pour observer et analyser ce processus dans la durée, nous avons conduit une étude pendant 2 ans et demi (janvier 2012-juin 2014) dans une école de St-Denis, aux portes de Paris.

Résultats

Introduction de la classe mobile: des transformations non anticipées

Les XO ont d’abord été utilisés par les enseignants pour remplacer certaines activités classiquement réalisées sur feuille (calcul mental, géométrie, production d’écrit) en vue de proposer des activités plus motivantes pour les élèves avec des applications susceptibles d’être plus adaptées à leurs besoins.

Pour mettre en œuvre ce projet, les enseignants ont dû faire face à des contraintes organisationnelles nouvelles (déplacement, chargement) qui leur demandaient une réorganisation de la préparation de leur activité.

Au-delà de la préparation, l’observation des séances a montré que l’introduction des XO transformait toutes les dimensions de leur activité en classe (mise en place des situations d’apprentissage, gestion de la classe) ; ces transformations n’avaient pas été anticipées et ont été plus ou moins bien vécues. Néanmoins, l’attitude des enfants et leur implication importante dans les activités a motivé les enseignants à dépasser ces contraintes.

A l’issue de cette première phase, tous les enseignants étaient très enthousiastes !

Utilisation des XO dans la durée : deux trajectoires d’appropriation différentes

Durant la deuxième année, 7 enseignants ont souhaité participer au projet. Au cours de l’année, ils ont adopté deux attitudes différentes vis-à-vis du XO et deux trajectoires d’appropriation distinctes.

La majorité des enseignants ont exploré différentes activités des XO dans des disciplines diverses en s’appuyant sur les formations proposées. Ces explorations les ont parfois conduits à constater un écart avec leurs attentes, ce qui les a conduits à explorer d’autres directions. A chaque nouvelle exploration, les gestes professionnels habituels étaient remis en question, ce qui demandait une adaptation des séances proposées. C’est pourquoi les enseignants ont choisi de restreindre leurs explorations à un petit nombre de disciplines bien maitrisées. L’une d’entre elles a par exemple consisté en la réalisation d’une planche de manga avec fototoon (cf. précédente note de blog).

L’un des enseignants a choisi une autre stratégie. Il a utilisé une seule activité (tuxmaths, application proposant du calcul mental sous forme ludique), mais pendant plusieurs. Cette utilisation au fil de l’année scolaire lui a rapidement permis d’organiser son activité de façon très stable et de concentrer son attention sur l’apprentissage des élèves plutôt que sur la prise en main de l’ordinateur et de l’application.

Différents facteurs qui influencent positivement ou négativement l’appropriation

Au fur et à mesure de l’utilisation différents facteurs ont influencé positivement ou négativement le processus d’appropriation

Facteurs positifs. La formation proposée aux enseignants, la conception collective de scénarios pédagogiques et la dynamique d’équipe positive présente dans l’école ont motivé les enseignants à tester de nouveaux usages et à persévérer. On perçoit ici l’importance de la dimension sociale de l’appropriation.

L’attitude très positive des élèves face à la classe mobile (motivation, engagement, émulation, fierté devant le résultat produit) ainsi que les progrès observés sont également des facteurs qui facilitent l’appropriation.

Facteurs négatifs. En revanche de multiples contraintes freinent les usages des XO en classe. Il est à noter que ces facteurs évoluent au cours du temps :

• Lors de l’introduction de la classe mobile, les facteurs principaux semblent être les contraintes logistiques (déplacement, chargement) mais aussi les perturbations de l’activité de l’enseignant.
• Dans un second temps, les enseignants trouvent des solutions aux contraintes logistiques mais sont affectés par le manque de fiabilité de certaines applications. Ceci peut conduire l’enseignant à perdre le contrôle de la séance. Le manque de compétence technique peut accentuer cette sensibilité aux aléas et autres problèmes techniques. Des tensions temporelles entre les multiples tâches que doivent gérer les enseignants freinent également leur investissement.
• Dans un troisième temps, les enseignants qui continuent à utiliser le XO souhaitent mettre en place des utilisations plus ambitieuses (collecte de données sur le terrain, puis réalisation d’analyse, de recherche d’information, de documents) mais un ensemble de contraintes techniques et des problèmes d’interopérabilité (fiabilité de la connexion wifi, absence de serveur pour gérer l’ensemble des ordinateurs, impossibilité d’imprimer, etc.) limitent les possibilités d’action.

Ces différentes contraintes conduisent progressivement les enseignants à utiliser les XO pour des enseignements disciplinaires spécifiques, à réinvestir la salle multimédia pour des projets plus globaux, impliquant de la recherche d’information ou la production de documents multimédias ou à renoncer à certains projets.

Réfléchir collectivement à des solutions

En conclusion, Le processus d’appropriation des XO est lent, il s’inscrit sur plusieurs années. Un ensemble de facteurs influence ce processus au cours du temps, et oriente les choix des enseignants et les usages proposés aux élèves.

L’accompagnement proposé aux enseignants et l’existence d’un collectif d’enseignants dynamiques et impliqués semblent être essentiels à la réussite du projet. Cet accompagnement doit avoir lieu lors de l’introduction de la classe mobile, mais aussi régulièrement ensuite, afin de permettre aux enseignants d’identifier les freins à l’utilisation et de réfléchir collectivement à des solutions.

Néanmoins, des contraintes techniques et « écosystémiques » freinent les usages. Pour que les enseignants puissent les dépasser il est important de mettre à leur disposition non seulement un ordinateur et des applications appropriées aux besoins des enfants, mais aussi un éco-système adapté aux besoins des enseignants, aux différentes facettes de leur activité. Ainsi, il s’agit non seulement de fournir des technologies supports aux apprentissages individuels, mais aussi de veiller à instrumenter la dimension collective de l’apprentissage à travers le suivi de l’activité des enfants, la gestion de leurs productions, et surtout le partage collectif de ce qui est réalisé par chacun.

Pour en savoir plus…

Rapport de l’étude : Nogry et al. (2015). Appropriation d’une classe mobile à l’école primaire : étude de cas durant 2 ans et demi à St-Denis. Rapport de recherche – Université Paris 8.
Rapport complet
Rapport synthétique

A lire aussi Decortis F. (2015). L’ergonomie orientée enfants. PUF

Partenaires du projet

Ce projet est est réalisé par Sandra Nogry MCF en Pyschologie des apprentissages (laboratoire Paragraphe, Université Cergy-Pontoise) et Françoise Decortis, Professeure en ergonomie, (Equipe C3U, Laboratoire Paragraphe, Université paris 8).
Il est financé par la région île de France (Projet PICRI) et soutenu par l’association OLPC-France avec le soutien de la fondation Lyoness Child and Family.

Pour toute information complémentaire vous pouvez contacter Sandra Nogry

Original post of OLPC France.Votez pour ce billet sur Planet Libre.

Postfix est un serveur libre de messagerie électronique développé à l'origine comme une alternative, plus simple et plus sécurisée, à sendmail. Aujourd'hui c'est une énorme usine à gaz qui demanderait quelques bonnes vies de chat pour être correctement maîtrisée.

L'objectif de ce tutoriel est de voir comment nous pouvons utiliser cet outil de manière très fortement allégée dans le seul but de gagner en indépendance vis à vis d'un fournisseur, mais aussi en puissance et en souplesse.

DNS et enregistrement MX

Pour recevoir du courrier un prérequis est de disposer d'une IP fixe, ce qui est automatique avec une dédibox ou une freebox. Il est cependant possible d'utiliser des IP variables en passant par des services comme DynDNS.org mais de nos jours, avec le volume de SPAM et la violence des contre-mesures, ce n'est clairement pas conseillé.

Pour pouvoir utiliser notre IP, il nous faut aussi acheter un nom de domaine. Il s'agit là d'une formalité qui ne coûte pas le service qu'il rend (12€ chez Gandi pour un .fr ou un .net). Et une fois ce domaine en poche, il ne nous reste plus qu'à configurer ses zones de sorte à ce que notre nouveau nom pointe sur notre IP.

Chez Gandi cela se fait très facilement avec un peu de courage et de gougueulage en passant par l'interface "gestion des Zones", en mode Avancé ou Expert. La version la plus simple que nous devons obtenir pour le routage du courrier doit ressembler à cela :

mon_server 300 IN A 11.22.33.44
smtp.mon_domaine.net 300 IN CNAME mon_server
@ 300 IN MX 10 smtp.mon_domaine.net.

Sans rentrer dans les arcanes de la syntaxe DNS, tout ceci indique que la machine mon_serveur pointe sur l'adresse IP 11.22.33.44 de sorte à ce qu'un ping mon_server.mon_domaine.net réponde positivement. C'est ce que l'on appelle une enregistrement A (principal).

Ensuite vient un enregistrement CNAME qui n'est autre q'un alias sur un enregistrement A. Ce n'est pas strictement nécessaire mais c'est plus propre ainsi, notre serveur SMTP sera donc accessible par smtp.mon_domaine.net.

Enfin vient un enregistrement MX qui définit le nom qualifié de la machine qui prend en charge le courrier entrant (n'oubliez pas le . final). Notez le chiffre 10 qui définit la priorité de cet enregistrement. L'idée est que si vous avez des amis qui ont eux aussi un domaine et un serveur courriel, vous pouvez ajouter d'autres enregistrement MX pointant chez eux. Ainsi si le MX de plus forte priorité ne répond pas, le courrier est envoyé à celui qui une priorité inférieur. Ainsi il est possible de renforcer mutuellement plusieurs serveurs pour être certain de ne rien perdre.

Pour chacun des enregistrements 300 indique un délai en secondes que les serveurs utilisent comme base de temps pour les mises à jour. Ici, la mise à jour est faite, en cas de changement des données DNS, toutes les 5 minutes.

Une fois que vos modifications sont correctement propagées sur le net (comptez 24 heures pour la première fois). Ceci fait, la mécanique fonctionne de la manière suivante:

1. Lorsqu'un utilisateur du Net veut vous envoyer un courriel, il le fait à l'adresse gaston@mon_domaine.net.
2. Son client de courriel va poster le courrier au serveur SMTP (Simple Mail Transport Protocol) de son fournisseur d'accès.
3. Le SMTP du FAI va extraire le domaine du destinataire et analyser la définition de zone associée (celle que nous venons de propager).
4. S'il trouve un enregistrement MX il remonte (je simplifie, hein ;-)) à l'enregistrement CNAME pour finalement récupérer son IP par son enregistrement A.
5. Le serveur SMTP du FAI va alors se connecter sur l'adresse IP du serveur de Gaston, sur le port 25.

Et là, il faut bien que quelqu'un lui réponde sinon c'est la cata, courriel perdu, amis fâchés, tout ça, tout ça. Nous allons donc donc passer à l'installation chez nous de ce fameux serveur SMTP, M. Postfix.

L'organisation de postfix

Postfix est donc un serveur de messagerie qui a la particularité de se composer d'une série de sous-démons travaillant de concert pour former une véritable chaîne de traitement du courrier entrant. Dans le graphique ci-dessus, en vert sont les entrées de courrier, en orange les démons traitant les messages, en chocolat les différentes files de stockages, et en prune les sorties.

Les messages peuvent ainsi être distribués soit localement en les insérant dans la file maildrop ou à distance en passant par le service SMTP. Dans les deux cas, les messages finissent par être pris en charge par le démon cleanup qui les stocke dans la file incoming. Ensuite le démon qmrg ventile les messages vers du stockage local, un autre serveur SMTP ou vers le démon lmtp communiquant via le protocole LMTP (Light Mail Transport Protocol) très bien adapté au transport local du courrier, par exemple vers le serveur dovcot (imap).

Installation de postfix

Ici rien de sorcier, tout est dans le même paquet sur la grande majorité des distributions, sur une debian cela donnerait donc

$ sudo aptitude install postfix
installation de postfix

Le résultat sera une installation quasi vierge que nous allons pouvoir paramétrer proprement.

Paramétrage de postfix

L'installation de postfix ne pose aucun problème, c'est plus sa configuration qui rend va vous dégarnir prématurément.

Pour rentrer directement dans le vif de sujet, allons jeté un oeil à ce que devra être la configuration principale du serveur, le fichier /etc/postfix/main.cf. Ce qui suit est une configuration qui fonctionne sur trois serveurs dont j'ai la charge et ce sans problème depuis des années.

L'identité du serveur

Pour éviter de trop donner d'informations au monde extérieur sur ce qui tourne sur notre machine, nous donnons allons donner ici à notre serveur PostFix de charmants petits noms d'oiseaux :

smtpd_banner = $myhostname Tagazok !
mail_name = PiouPiou
mail_version = 6.6.6
limitation de l'identification au strict minimum

Voilà, comme cela, ce sera difficile à un attaquant potentiel de comprendre ce qui tourne exactement chez nous.

Paramétrage du réseau

Nous allons maintenant spécifier la manière dont postfix "écoute" le réseau. Cela consiste basiquement à le connecter à toutes les IP de la machine (c'est un serveur ouvert sur l'extérieur) et à se concentrer sur IPV4.

inet_interfaces = all
inet_protocols = ipv4
Paramétrage de l'écoute

Gestion du domaine

Le paramétrage du domaine pris en charge par postfix reste assez simple nous concernant :

# définis le nom Internet (fqdn) de la machine.
myhostname = mon_serveur.mon_domaine.net

# spécifie le nom du domaine local (myhostname moins le nom de la bécane)
mydomain = mon_domaine.net

# définit l'adresse d'émission des messages postés localement
myorigin = mon_domaine.net

# définit une liste de domaine ou nom de bécanes que postfix
# considérera comme la destination finale des messages.
# Il faut donc mettre ici la liste des domaines qui ne sont pas relayés
# sur d'autres machines.
mydestination = mon_domaine.net, mon_second_domaine.net
définition du domaine

Il faut maintenant définir nos "réseaux de confiances", c'est à dire les plages d'adresses IP pour lesquels postfix vous autorisera par exemple l'envoi de courriels vers d'autres serveurs. On y ajoute donc notre réseau local car c'est de là que sera expédié le courrier (plus la peine d'utiliser le SMTP de votre FAI). L'ajout du localhost nous permettra d'installer par exemple un WebMail comme Roundcube sur la même machine que postfix.

mynetworks = 127.0.0.0/8,192.168.154.0/28
réseaux de confiance

Ensuite nous indiquons les domaines que postfix a le droit de relayer. Attention à ce paramétrage car il ne faudrait pas que votre serveur devienne ce que l'on appelle un "relais ouvert" permettant aux spammeurs d'accomplir leur méfaits. Vous allez y mettre bien sur votre domaine (mydestination), mais vous pouvez aussi ajouter les domaines "amis" que nous prenons en charge que ce soient ceux correspondant à nos enregistrements MX de backup ou simplement des domaines que vous hébergez chez vous.

relay_domains = $mydestination domaine_ami.net
définition des domaines relayables

Lorsque vous avez terminé votre configuration, vérifiez systématiquement que votre serveur n'est pas une porte ouverte aux spams avec des outils en ligne comme celui-ci.

Normalement lorsque l'on utilise notre postfix pour envoyer un mail, il va chercher directement à contacter le serveur SMTP du destinataire. Si vous préférez utiliser un serveur SMTP mandataire, par exemple celui de votre FAI, il suffit d'ajouter la ligne suivante :

relayhost = smtp.free.fr
définition d'un serveur SMTP de relais

Avant poste du filtrage des SPAM

Notre ennemi juré, c'est le SPAM. Nous verrons dans un autre papier comment s'en prémunir avec SpamAssassin. Mais en attendant, il est possible d'applique à notre serveur PostFix une bon hygiène.

Nous allons donc adjoindre au module SMTP un ensemble de règles lui permettant de qualifier le courrier entrant. Le principe est que c'est très mais alors très rapide en comparaison de SpamAssassin car directement intégré au moteur SMTP de postfix. Si le test ne passe pas, le vilain est jeté sans somation.

smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination
check_recipient_access hash:/etc/postfix/spam,
permit
Qualification des courriels entrant

Alors j'ai mis ici les règles les plus "safe" en ajoutant un "plus" particulièrement intéressant, la référence à un fichier /etc/postfix/spam pouvant contenir des motifs d'adresse cible à rejeter. Cela va nous permettre d'éliminer des adresses non utilisées mais très polluées, typiquement des adresses que vous avez "grillées" et qui sont pourries de SPAM.

Pour initier cette liste, commencez par la créer (avec nano, vi, etc.) et y ajouter une adresse suivie d'une action REJECT. Le principe sera que dés que le serveur SMTP verra arriver cette adresse cible (dans le champ TO), il arrêtera tout traitement concernant ce courriel. Brutal mais efficace.

vielle_adresse@mon_domaine.net      REJECT
exemple de fichier /etc/postfix/spam

En l'état cette liste n'est pas utilisable par postfix. Elle doit préalablement être "compilée" en une base de donnée. Pour cela, utilisez la commande postmap

rootpostmap spam
rootls spam*
spam    spam.db
Compilation d'une table postfix

Comme vous le voyez, la commande à généré un fichier spam.db, la version indexée de la liste d'origine. A chaque fois que vous modifiez une table, vous devrez lancer cette commande dessus.

Gestion des alias

Les alias sont une étape optionnelle si vous ne gérez qu'un domaine et que vous n'avez au final qu'un compte mail cible par adresse source. En réalité ce cas n'est jamais vérifié car nous avons tous besoin au minimum de rediriger une série d'adresses sur un même compte (ex. root@mon_domain.com vers mon adresse standard). Les alias permettent donc de jouer le rôle de redirecteur d'une adresse, d'un groupe d'adresse ou même d'un domaine complet vers une autre adresse.

Pour mettre ceci en oeuvre, nous ajoutons allons ajouter une autre liste (comme pour les spams) qui va nous permettre cette mise en relation :

virtual_alias_maps = hash:/etc/postfix/aliases
Définition des aliases

Reste maintenant à nourrir ce fichier :

# tous les courriers pour le domaine mon_domaine.net et mon_second_domaine.net va en priorité à gaston
@mon_domaine.net             gaston
@mon_second_domaine.net     gaston

# le courrier de robert lui revient
robert@mon_domaine.net       robert
exemple de fichier /etc/postfix/aliases

Comme pour la liste des spams, nous devons compiler cette liste après modification à l'aide de la commande postmap.

rootpostmap aliases
rootls aliases
aliases    aliases.db
Compilation d'une table postfix

Limitations de taille

Pour terminer, vous pouvez aussi modifier les limites de tailles imposées à un message et une boîte aux lettres (en octets). Cette opération nous permet de recevoir de très gros fichiers sans encombres, ce qui est un autre avantage à posséder son propre serveur :

message_size_limit = 104857600
mailbox_size_limit = 104857600
limitation de la taille des messages et des boîtes aux lettres

Placer l'une de ses valeurs à 0 pour ne pas avoir de limitation du tout.

Gestion des erreurs

Le soft bounce est à manier avec beaucoup de précaution. D'une certaine manière, il assure que vos courriels ne seront jamais rejetés mais stocké en queue si par exemple votre espace disque est totalement consommé ou que SpamAssassin est parti en vrille. En contrepartie, il va ré-émettre comme un sauvage les courriels à "faux numéro", ce qui a le don d'exaspérer les serveurs d'en face avec le risque de vous faire marquer comme spammeur. Personnellement je le laisse à no et le passe à yes lorsque je fais des opérations de maintenance pour ne pas perdre de courrier.

soft_bounce=no
définition du 'soft bounce'

Lorsque soft bounce est à no, nous avons donc le risque de perdre du courrier si un élément est défaillant dans la chaîne de traitement des messages (spamassassin en carafe, disque plein, etc). Pour contrer cela, l'astuce est de changer le code d'erreur généré pour un destinataire invalide de 550 (ce qui veut dire "mail rejeté") à 450 (ce qui veut dire "essayez un peu plus tard"). Du coup le serveur d'en face va (de mémoire) retenter l'envoi toutes les 10 minutes pendant 4 heures, avant de déclarer que votre courrier est vraiment mort.

unknown_local_recipient_reject_code = 450
stratégie de récupération d'erreurs

Test de l'installation

Maintenant que nous avons paramétré notre serveur, il nous reste à vérifier que cela fonctionne. La première chose à faire sera évidement de le (re)démarrer

root/etc/init.d/postfix restart
Stopping Postfix Mail Transport Agent: postfix.
Starting Postfix Mail Transport Agent: postfix.
Redémarrage de postfix

Vous pouvez aussi utiliser la commande /etc/init.d/postfix reload si postfix est déjà lancé, c'est un peu moins bourrin.

Ensuite pour tester, le plus simple dans un premier temps est d'utiliser l'antique client telnet que nous allons connecter au port 25 (SMTP) de notre serveur :

roottelnet smtp.mon_domaine.net 25
Trying 11.22.33.44...
Connected to smtp.mon_domaine.net (11.22.33.44).
Escape character is '^]'.
220 mon_serveur.mon_domaine.net Tagazok !!
>ehlo son_domaine.net
250-smtp.mon_domaine.net
250-PIPELINING
250-SIZE 1004857600
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
>mail from: robert@son_domaine.net
250 2.1.0 Ok
>rcpt to: gaston@mon_domaine.net
250 2.1.5 Ok
>data
354 End data with .
>Robert parle à gaston !!
>$
>.
250 2.0.0 Ok: queued as D421D908DA0
>quit
221 2.0.0 Bye
Connection closed by foreign host.
root#
Session de test de notre serveur Telnet

Si tout c'est bien passé, gaston devrait ainsi recevoir un courriel de robert. Cette approche peut aussi être utilisée pour tester les barrières anti-spam. Toujours est-il que cela fonctionne, nous pouvons donc passer à la suite, le stockage du courrier.

Redirection du courrier

A ce stade, notre serveur postfix est capable de prendre en charge le courrier entrant, c'est déjà une bonne chose. Côté stockage, si rien n'est fait, le courrier de gaston est posé, à l'ancienne, dans le dossier /var/mail/gaston. gaston peut donc lire son mail, avec l'ancestrale commande 'mail', ou alors avec Pine ou Mutt. Ou alors vous allez devoir installer un serveur IMAP tel que DoveCot ou Cyrus.

En revanche si votre serveur postfix est sur une machine distante (ex. une dédibox), il va falloir trouver un moyen pour que votre courriers soient ré-acheminés sur votre serveur local.

Pour y arriver, une solution assez simple est d'installer un second serveur postfix sur votre réseau local. Ce serveur postfix sera configuré pour ne prendre en charge que le courrier de votre domaine ce qui au fond reprend à peu prés (au delta du paramétrage des domaines amis) la configuration que nous venons de voir.

Ensuite, la seule chose à faire est d'indiquer au postfix distant comment ré-acheminer le courriels de votre domaine. Pour cela nous allons rajouter une nouvelle table transport

transport_maps = hash:/etc/postfix/transport
Définition de la table de transport

Nous pouvons maintenant créer et alimenter cette table :

mon_domaine.net           smtp:[11.22.33.44]
domaine_ami.net           smtp:[mail.domain_local.org]
Exemple de fichier /etc/postfix/transport

Comme toujours, pensez à recompiler la table avec la commande postmap après modification.

Comme vous le voyez, c'est aussi là que nous traitons le ré-acheminement du courrier du domaine ami que nous avons déclaré plus haut par relay_domains.

Une fois nos deux postfix paramétrés, le courriel arrive sur le premier (le serveur distant), est accepté (à cause de relay_domains), puis redirigé sur le serveur local grâce à la table transport. Là vous pouvez un routage final vers votre serveur IMAP, et c'est terminé.

A ce stade tout est presque prêt sauf un léger détail, postfix va rejeter tous ces courriels non-locaux parce qu'ils sont... non locaux... Pour éviter ce gag, il faut demander à notre ami de ne plus vérifier que le destinataire dispose d'un compte en local pour traiter son courriel :

local_recipient_maps =
Déclaration d'une table de destinataires vide

Quelques astuces

Remise en queue des messages

L'objectif de cette commande est de permettre aux messages d'être à nouveau interprétés par postfix pour être replacés dans les bonnes queues. Elle est notamment très utile lorsque l'on a des erreurs de configuration qui une fois corrigées laissent des messages en attente (ex. désinstallation d'amavis et message d'erreur warning: connect to transport smtp-amavis: No such file or directory) :

rootpostsuper -r ALL
postsuper: Requeued: 5 messages
remise en queue des messages

Liste des messages en queue

Lorsque Postfix n'arrive à rien faire d'un message, il le met en file d'attente. Les commande suivantes permette d'avoir l'état de ces files :

ces deux commandes sont équivalentes
rootpostqueue -f
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
1DEC5908D05     3716 Mon Jan 19 14:33:50  tcpv@mon_domaine.com
(mail forwarding loop for tartignole@mon_domaine.com)

rootmailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
1DEC5908D05     3716 Mon Jan 19 14:33:50  tcpv@mon_domaine.com
(mail forwarding loop for tartignole@mon_domaine.com)
Affichage des messages en non-traités

Lire le contenu d'un message en queue

Il arrive souvent qu'avant de détruire un message bloqué en queue, on ait envie de savoir ce qu'il contient.. Pour cela nous avons la commande postcat (depuis postfix 2.0)

rootpostcat -q ID_MESSAGE
Lecture d'un message unique

Suppression d'un message en queue

La commande précédente donne la liste des messages en attente dans la queue de postfix (généralement des spams :/). Chaque message dispose d'un ID qui permet de le détruire spécifiquement :

rootpostqueue -d ID_MESSAGE
destruction d'un message unique

S'il s'agit de détruire tous les messages en queue (attention !!) vous pouvez utilisez la commande suivante :

rootpostqueue -d ALL
postsuper: Deleted: 5 messages
destruction de tous les messages en queue

Profil de répartition des messages dans les queues

Pour voir de plus prés l'utilisation d'une queue :

rootqshape deferred
T  5 10 20 40 80 160 320 640 1280 1280+
TOTAL   7  0  0  0  0  0   0   0   1    0     6
chez.com   6  0  0  0  0  0   0   0   0    0     6
tiscali.fr  1  0  0  0  0  0   0   0   1    0     0
Profile des queues

Erreur de droit sur les fichiers

Si vous avez dans vos logs l'erreur suivante warning: mail_queue_enter: create file maildrop/163133.6208: Permission denied, une solution possible est de lancer les commandes suivantes :

rootpostfix set-permissions
rootpostfix reload
correction des droits postfix

Conclusion

La mise en place d'un serveur Postfix, sous réserve de prendre quelques précaution pour ne pas l'ouvrir aux spammeurs, est relativement simple. Et surtout c'est très fiable. Ceci étant dit il manque quelques trucs à notre arsenal :

• une vraie gestion des spams avec SpamAssassin,
• la gestion de SPF et DKIM pour signer nos mails et ne pas être pris pour des spammeurs.

Original post of Artisan Numérique.Votez pour ce billet sur Planet Libre.

Vous avez peut-être manqué ça, mais Mozilla va intégrer nativement le plugin Pocket dans la prochaine version de Firefox.

Forcément, en tant que développeur principal de wallabag, alternative libre aux solutions propriétaires que sont Pocket, Readability ou encore Instapaper, cette nouvelle me chagrine un peu.
Pas uniquement parce que Mozilla n'a pas choisi wallabag comme solution "officielle".

Non. Aussi parce que Pocket n'est pas libre et on ne sait pas ce qu'ils font des données de leurs clients utilisateurs.
Alors, OK, Mozilla peut dire : "nous ne transmettons aucune des données à Pocket". Mais dans le principe, ils envoient leurs utilisateurs vers des silos tels que Google, Amazon, Facebook ou Apple. Et les utilisateurs de Firefox ne sont pas forcément conscients de ça. Mieux, ils utilisent Firefox car ils se disent qu'il y a une certaine éthique derrière la fondation Mozilla. De source proche du dossier, il paraitrait que Mozilla s'attèlerait à faire changer les conditions d'utilisation de Pocket, histoire de nous faire croire qu'ils agissent pour la liberté des utilisateurs de Pocket. Mouais, la marmotte tout ça.

Chagriné également parce que Mozilla ne propose que l'intégration de Pocket. Comme le suggère Thomas, pourquoi ne pas avoir intégré Instapaper et Readability également ? Un peu comme ce qui est fait dans les moteurs de recherche par défaut.

Si vous aussi, vous souhaitez manifester votre déception, vous pouvez en parler à Mozilla, un ticket a été ouvert.

Firefox Hello, l'intégration de Pocket, votre navigateur qui vous affiche du contenu en fonction de votre historique : la fondation Mozilla ne serait-elle pas en train de filer du mauvais coton ?

Original post of Nicolas Lœuillet.Votez pour ce billet sur Planet Libre.