Skip to content

Linux Attitude

Le libre est un état d'esprit

Archive

Archive for September, 2007

Niveau :      
Résumé : Round Robin DNS

Contrairement à ce que vous pensez, il ne s'agit pas du mignon de Batman mais d'une méthode de répartition. Nous allons parler du round robin dns.

Le but est de répartir la charge d'un serveur sur des machines distinctes. Le principe est simple, il s'agit de fournir plusieurs IP pour la même entrée dns. Le client choisira alors de lui-même une de ces IP au hasard. C'est ce hasard qui répartira la charge entre les différents serveurs renseignés.

Les entrées DNS ressembleront donc à ceci

www.toto.net IN A 10.0.0.1
www.toto.net IN A 10.0.0.2

Attention tout de même :

  • En cas de problème sur une des 2 IP, le client doit faire de lui-même l'accès à une autre IP, ce qu'un certain nombre de logiciels devraient faire naturellement (mais pas tous).
  • Si le problème se situe au dessus de la couche TCP (par exemple une erreur HTTP 500), le logiciel client ne se rendra pas compte qu'il devrait interroger l'autre IP et l'utilisateur verra l'erreur. Pour une bonne gestion de la tolérance aux pannes, on préférera donc un loadbalancer.
  • Les applicatifs doivent faire attention à la notion de session. Si l'applicatif se nomme irc, il n'y a pas de problème car il y a une session par connexion. Si l'application est en PHP, vous avez le choix entre ne pas utiliser de session, stocker les données de session dans une base de données partagée, tout faire tenir dans un cookie ou enfin partager le répertoire contenant les données de session (avec NFS ou OCFS par exemple)

Notez au passage qu'un CNAME dans le DNS est un véritable alias, donc la ligne suivante conserve la fonction round robin DNS à test.toto.net :

test.toto.net IN CNAME www.toto.net.

Par contre, il est impossible de spécifier plusieurs CNAME pour un nom, et donc d'espérer faire du round robin de cette façon.

Notez aussi que le round robin DNS est un concept intégré au mail depuis longtemps. On l'utilise aussi fréquemment pour irc. C'est une solution permettant le partage de charge à peu de frais, mais pour le web on lui préférera l'utilisation d'un loadbalancer lorsqu'on en a les moyens et lorsque c'est possible. En effet leur utilisation est plutôt difficile entre plusieurs sites géographiques distincts.

Niveau :      
Résumé : Submission

Le protocole mail n'est pas mort, il évolue encore. La preuve, une RFC (2476) récente (de 1998) propose de changer la façon dont interagissent les serveurs mail. Cette évolution suit la logique de l'évolution de l'utilisation.

Au début un serveur mail servait à envoyer, recevoir et transmettre les mails. L'envoi de mail se faisait à travers une commande locale au serveur (sendmail) et la réception était locale au serveur. C'était pratique, toutes les machines connectées à internet étaient des serveurs. Puis le net a évolué et les gens devaient avoir un serveur mail chez eux pour envoyer des mails à d'autres serveurs. Et il a encore évolué lorsque les client se sont mis à implémenter eux-même l'envoi de mail à un serveur SMTP. Et c'est là qu'on est sorti du cadre d'utilisation prévue. Le SMTP a été fait pour communiquer de serveur à serveur.

La RFC en question propose donc de différencier les 2 usages. L'envoi d'un mail depuis un client devrait se faire depuis le port submission (587), tandis que la communication entre deux serveurs reste sur le port 25. Les deux conservant le protocole SMTP.

La différence se fera donc au niveau des vérifications faites sur le serveur.

Un serveur servant à recevoir des mails devra vérifier :

  • que le destinataire est valide et accepté localement

Un serveur submission doit :

  • fournir de nouveaux codes d'erreur pour que le client mail puisse mieux interpréter les problèmes
  • envoyer des mails contenant uniquement des domaines valides dans l'enveloppe
  • vérifier si possible que les adresses d'envoi fournies sont valides

Un serveur submission devrait :

  • répondre par un code d'erreur en cas de rejet et non par un mail au return path
  • vérifier que l'émetteur est valide et reconnu comme utilisateur par le serveur (voire l'authentifier) et donc que le chemin de retour est valable
  • rejeter les mails avec des adresses connues comme invalides
  • loguer les erreurs

D'autre part, du fait de sa position privilégiée, un serveur submission peut :

  • vérifier les droit d'envoi des utilisateurs
  • demander une authentification
  • vérifier la validité du contenu du mail
  • modifier les en-têtes du mail : champ date, sender, message-id ...

L'avantage du serveur submission est qu'il permet aux administrateurs de séparer clairement les politiques pour l'envoi et pour la réception du mail. Ainsi cela standardise une pratique déjà courante d'avoir 2 serveurs séparés pour l'envoi et pour la réception du mail.

Niveau :      
Résumé : RFC 2822

Un mail est composé d'en-têtes et d'un corps. Les en-têtes sont de 2 types. Les en-têtes d'enveloppes et les autres. Un serveur qui ne fait que faire transiter un mail devrait toujours ajouter une en-tête d'enveloppe au tout début des en-têtes et ne pas toucher du tout au reste du mail. Ces en-têtes précisent par où et à quelle heure le mail est passé, elles se lisent de bas en haut.

Les autres en-têtes sont celles écrites par l'émetteur. Seul l'émetteur et le récepteur ainsi que les serveurs de mailing-list (qui sont les 2 à la fois) devraient toucher à ces en-têtes. De nos jour, cela inclue aussi les serveurs qui font de l'antispam et/ou antivirus.

Les en-têtes obligatoires :

  • From: Savez vous que vous pouvez mettre plusieurs from ! Dans ce cas, il Faut préciser Sender:
  • Date: devinez

Les quasi-indispensables :

  • To:
  • Cc:
  • Subject:
  • Bcc: Sisi il existe, donc vous devez être au courant quand vous êtes destinataires d'un Bcc. Mais pourquoi les clients mail ne le précisent-ils pas ? Cela éviterait les bourdes.

Les utiles :

  • Reply-To:

Les indispensables mais incompris :

  • Message-ID: de la forme <truc@machin> doit être universellement unique
  • In-Reply-To: donne uniquement le parent (duplique l'information du suivant)
  • References: donne tout le fil parent (important pour suivre les conversations)

Les inconnus:

  • Comments: Mais qui les liraient ?
  • Keywords: C'est pas comme si vos mails étaient indexés
  • Resent-From:
  • Resent-Date:
  • Resent-Message-ID:

Les en-têtes d'enveloppe :

  • Return-Path: Indique où renvoyer les mails d'erreur (MAIL FROM: du protocole SMTP)
  • Received: date, heure, lieu de réception par le serveur

Les autres :

Les en-têtes commençant par X- permettent à leurs utilisateurs de créer les en-têtes qui leur semblent utile. En voici quelques exemples :

  • X-Mailer:
  • X-Spam-Level:
  • X-Loop:

Et comme toujours, les détails dans la RFC 2822

Niveau :      
Résumé : SMTP

Connaître le protocole SMTP est indispensable. Cela permet de faire quelque blagues, mais surtout de comprendre en quoi le protocole contient fondamentalement des failles et comment le spam fonctionne.

Le protocole est extrêmement simple, une session se résume en quelques commandes. Les codes de retour sont un peu les mêmes que FTP et HTTP , ainsi un 2xx indique une réussite. Voici une session typique (les lignes que vous tapez sont précédées de > ) :

> $ telnet smtp.mail.net 25
  220 smtp.mail.net ESMTP ; Wed, 1 Aug 2007 14:44:41 +0200
> EHLO toto
  250-smtp.mail.net Hello localhost [127.0.0.1], pleased to meet you
> MAIL FROM: ben@fr.fr
  250 ben@fr.fr... Sender ok
> RCPT TO: bob@fr.fr
  250 bob@fr.fr... Recipient ok
> DATA
  354 Enter mail, end with "." on a line by itself
> Coucou !
> .
  250 OAA25287 Message accepted for delivery
> QUIT
  221 smtp.mail.net closing connection 

Le EHLO devrait être suivi par le fqdn de l'émetteur. De plus en plus souvent le serveur vérifie ce qu'il contient. Il peut être évité ou remplacé par un HELO sur les serveurs mails qui font peu de vérifications.

MAIL FROM et RCPT TO doivent être indiqué dans cet ordre, ils indiquent la personne de qui vient le mail (non vérifié) et à qui il est destiné (le vrai destinataire). La norme suggère de mettre les adresses mail entre <> et certains serveurs l'exigent.

Enfin la commande DATA indique le contenu du mail. Lequel ne se termine que pas un '.' seul sur une ligne. Ce mail peu contenir absolument tout ce que vous voulez. Le serveur le transférera tel quel à la boite du destinataire avec quelques en-tête supplémentaires. Éventuellement il peut le faire passer par un antispam, antivirus, serveur de mailing-list ...

Pour plus de détails Lisez la RFC 2821

Vous aurez compris que les failles se situent dans les vérifications. Dans les champs, seul RCPT TO est toujours vérifié et entièrement validé seulement si le destinataire est local. Le mail lui-même n'est pas vérifié. Le format est (potentiellement) libre. Le mail étant lu par le client final, il est tout de même préférable qu'il respecte la RFC 822

On peut donc spécifier un destinataire ou un émetteur différent dans le corps et dans les informations données au serveur.

Il vous faudra attendre l'article suivant pour pouvoir écrire un mail complet.

Niveau :      
Résumé : IMAP

Ceci est le début d'une série sur le mail.

Comment tester un serveur IMAP qu'on vient juste d'installer ? Il suffit de connaître les bases du protocole IMAP.

Tout d'abord, chaque commande IMAP est précédée d'un identififant permettant au client de repérer à quelle requête correspond la réponse donnée par le serveur, ceci car le protocole peut être asynchrone. La plupart des client mettent des numéros, mais vous pouvez aussi les remplacer simplement par des '.'.

Tentons une connexion de base avec création d'un répertoire (les lignes que vous tapez sont précédées de > ):

> $ telnet imap.net.net 143
  Trying 127.0.0.1...
  Connected to localhost.
  Escape character is '^]'.
  * OK Dovecot ready.
> 1 LOGIN user password
  1 OK Logged in.
> 2 CREATE toto
  2 OK CREATE completed
> 3 LOGOUT
  * BYE Logging out
  3 OK Logout completed.
  Connection closed by foreign host.

Passons à quelque chose de plus sérieux. On sélectionne le répertoire INBOX, puis on liste les messages de 1 à la fin (1:*) et on récupère un message.


continue reading...

Niveau :      
Résumé : cal ; ncal : fc

Quel jour est-on ?

$ cal

Et quel jour était-on quand je suis né ?

$ cal 01 2000

Le sens ne vous plait pas ?

$ ncal

Préparer votre planning :

$ ncal -wy

Lister les 50 dernières commandes (il dit qu'il ne voit pas le rapport) :

$ fc -l -50

Envoyer un bip sur irc :

ctrl-g coucou

Savez-vous que dans un gnome-terminal, les mouvements de votre molette sont pris comme des évènements flèche vers le haut ? Essayez de lancer un less d'un fichier assez long dans un gnome-terminal et roulez !

Si vous constatez de nombreuses attaques sur votre serveur ssh et que cela vous gêne, essayez de changer le port sur lequel il écoute pour quelque chose comme 1022, vous n'en verrez plus jamais.

Niveau :      
Résumé : Xdmx

Si vous avez plusieurs écrans, vous voudriez bien avoir un seul couple clavier/souris ainsi qu'un seul window manager pour gérer l'ensemble. Si vous êtes en local, c'est simple. Il suffit de lancer un unique serveur X avec plusieurs écrans définis ou avec un seul écran viruel (ça marche même s'il s'agit de plusieurs cartes vidéos et non d'une carte multitête). Mais si vous devez avoir plusieurs serveurs X à cause d'un bug du driver ou, plus excusable, des écrans sur des machines différentes, vous pouvez regrouper plusieurs serveurs X en un seul. Imaginez une mosaïque de 16 écrans répartis sur 4 machines !

Xdmx sert justement à ça :

$ Xdmx -display machine1:0 machine2:0 :1

Notez que Xdmx ne prend pas nécessairement pour input le clavier/souris des display concernés. Vous pouvez prendre celui de n'importe quelle autre machine existante, ou celui de la machine sur laquelle il tourne si c'est en console.

# on utilise un autre display comme source d'input
$ Xdmx -display machine1:0 machine2:0 -input machine3:0 :1
# on utilise le clavier local à Xdmx
$ Xdmx -display machine1:0 machine2:0 -input local,kbd,ps2 :1

Par défaut Xdmx crée un unique display avec plusieurs écrans (:1.0 et :1.1 dans notre exemple), ce qui est finalement peu intéressant par rapport à l'utilisation de x2x. Mais on peut aussi lui demander de les regrouper en un seul écran virtuel grâce à xinerama :

$ Xdmx +xinerama -display machine1:0 machine2:0 -input machine1:0 :1

Et maintenant, astuce ...

Xdmx supporte la déconnexion et la reconnexion d'écrans.

Il est donc possible de faire une application qui supporte la déconnexion d'un serveur X de façon volontaire. Attention, lorsque ceci fonctionne, l'opengl est désactivé :

# on lance Xdmx sur un nouveau premier serveur X
$ Xdmx -display machine1:0 -addremovescreens -norender -noglxproxy :1
# on lance une application à travers xdmx (qui nous sert de proxy)
$ xclock -display :1
# on supprime l'accès au premier écran de xdmx (qui est sur le premier serveur X)
# attention à bien lancer cette commande, une coupure violent de l'écran fait planter xdmx
$ dmxrmscreen :1 0
# et on réactive le premier écran sur un 2e serveur X
$ dmxaddscreen :1 0 machine2:0

Et voilà !