Sébastien Koechlin a écrit 854 commentaires

Ce que tu décris n'est pas ce qu'on appelle habituellement du déport d'affichage.

Le cas habituel est le lancement d'une application sur la machine distante avec affichage sur la machine locale. Il suffit d'avoir un serveur X sur la machine locale; et de paramétrer l'environnement pour que l'affichage des applications que tu lances sur la machine distante se fasse sur la machine locale (variable DISPLAY, xhost..). SSH dispose d'un mode tunnel X qui gère cela.

Toutes les applications X lancées depuis ta session sur la machine distante s'affiche sur ta machine locale.

Le cas que tu évoques est plutôt de la connexion à distance sur un bureau qui tourne lui-même sur la machine distante. Il existe beaucoup de solutions, vnc, nx...

Ça dépends beaucoup de ce que tu veux faire:

• Si ta machine distante est un serveur que tu aimes administrer via une interface graphique, alors la première solution est bien plus simple et légère; il n'est pas nécessaire d'installer X sur le serveur ni d'occuper la mémoire avec un serveur X.

• Si tu as besoin d'un bureau distant que tu retrouves tel quel à chaque connection, avec tes applications lancées et tes documents ouverts tels que tu les as laissé; alors on est plutôt dans la seconde solution. Un serveur X virtuel tel que Xvfb ou vnc-server propose d'avoir un bureau sans carte graphique ni souris/clavier, sur lequel on peu se connecter à distance pour interagir.

Je ne comprends pas bien la question. Rediriger un port avec une seule carte réseau ?

J'imagine qu'il y a un tas de solutions, mais rien qu'en faisant un NAT sur la machine de redirection, je ne pense pas que ça pose de problème qu'il y ait une carte ou plusieurs.

Dans ce cas, je ne peux utiliser IPMI que lorsque la machine est en état de fonctionner. Je ne peux pas la démarrer ou la rebooter à distance, je ne peux pas me connecter si SSH ne réponds pas, je ne peux pas accéder au BIOS.

On peut d'ailleurs noter que certains développeurs du noyau prévoient un mode x32. Ce mode doit combiner le meilleur des deux modes:

• Les instructions et les registres supplémentaires du mode 64 bits
• Des registres et des pointeurs sur 32 bits pour réduire l'empreinte mémoire

Lire http://lwn.net/Articles/456731/ et voir https://sites.google.com/site/x32abi/

Ok, c'est parti.

Le PAE (Extension d'adresse physique) est un principe plutôt simple: le MMU (Unité de gestion mémoire) qui fait la conversion entre adresse logique et adresse physique est étendu afin que les adresse physiques soient codées sur 36 bits (64Gio). Les adresses logiques restent sur 32 bits (4gio), ce qui explique que les processus soient limités à 4Go.

Lorsque le processeur accède à une case mémoire, l'adresse logique sur 32 bits est convertie en adresse physique sur 36 bits via le TLB (Translation Lookaside Buffer) et tout le monde est content. De ce coté, ça n'a quasiment aucun impact.

Pour le kernel, les choses sont moins roses. Lui aussi est limité à 4Gio car toutes les adresses sont sur 32 bits. Or le kernel a globalement besoin d'accéder à toute la mémoire de tous les processus (pour mapper les pages du programme, des fichiers, lire ou écrire les données réseau, disque etc...) et comme on a plus de 4 Gio de mémoire, il est impossible de faire tout rentrer dans l'espace d'adressage de 32 bits du kernel.

Ça oblige à revenir aux joies de la mémoire paginées. Le kernel modifie en permanence les réglages de la MMU pour accéder, morceaux par morceaux, aux pages mémoires dont il a besoin. Opération très couteuse parce qu'elle oblige à vider un certain nombre de cache, en particulier le cache TLB qui conditionne tous les accès à la mémoire.

Bref, un bricolage pas très élégant.

Le plus simple est probablement de faire un 'ps' et de voir les options utilisées par X.

Un 'netstat' te montrera aussi si X est a l'écoute en TCP.

Y'a aussi le

[security]
DisallowTCP=true

qui mériterait de creuser un peu la doc.

Voila, c'est exactement le genre de paragraphe qu'il convient de mettre en introduction de la dépêche.

Le fait que la mesure de protection est contournable n'en fait pas de la foutaise.

Un keylogger qui capture les touches saisies peut retrouver très facilement le code. Il y en a eu des paquets, et on voit encore pas mal ce genre d'attaque en circulation; surtout pour pirater les comptes webmail et balancer du spam.

Avec le clavier virtuel; c'est le navigateur qui fait l'association entre le clic et le chiffre; et ensuite envoi la requête chiffrée au site. Pour intercepter les chiffres, il faut aller lire dans le navigateur; ce qui n'est pas impossible, mais déjà plus difficile.

On pourrait encore améliorer le mécanisme, pour que le navigateur ignore le code, mais ce n'est pas une raison pour cracher bêtement sur les mesures qui sont mises en place.

Sur un portable, c'est probablement peu intéressant:

• Tu n'en parles pas, mais je pense que c'était sous entendu, il faut retirer la batterie pour supprimer la consommation liée à la charge ou l'entretien de la charge de la batterie.
• Selon s'ils sont branchés sur le secteur ou non, les portables activent ou désactivent tout un tas de chose. Si le but est d'augmenter l'autonomie de la machine, alors la mesure de la consommation lorsqu'il est branché est peu significative. Il faudrait être capable de faire croire à la machine qu'elle fonctionne sur batterie; et je ne suis pas certain que tout puisse se configurer de façon logiciel.
• Les wattmètres du commerce que je connais n'ont pas de calibre adapté à d'aussi petites puissances. Celui que j'utilise pour les appareils ménagers courants a une sensibilité de 5 ou 6 watts, il sera bien incapable de distinguer une réduction de consommation de 1W. Sur un portable qui en consomme entre 10 et 15, il n'est pas possible de faire de mesure intéressante. Au contraire, la couche ACPI me remonte la consommation avec une sensibilité de 1W, permettant de voir plus facilement l'impact de chaque paramètre.

Oui, merci, ce n'est pas vraiment ce que j'attendais.

Tant qu'à râler, je me joins à toi:

Tout le monde n'est pas un spécialiste de tous les logiciels open-source. Est-ce que ça serait trop demander de reprendre une saine habitude: donner au moins une phrase explicative de ce qu'est MongoDB au début de la dépêche ?

C'est indispensable pour permettre à un plus grand nombre de profiter de l'article. Là, c'est l'exemple typique de l'article imperméable.

Je ne comprends pas ce qui te dérange.
> Qui me ment ?

Personne, on a bien 2582904µs > 2578351µs > 1003254µs

Apache bufferise-t-il ce qui lui vient de plus loin avant de le renvoyer ou le renvoie-t-il au fil de l'eau ?

Il bufferise dans une certaine mesure. Le reverse-proxy n'est pas un switch ou un équipement réseau de niveau IP. Lorsqu'il reçoit une requête, il la traite, et il créer une NOUVELLE requête vers le serveur suivant. La bufferisation dépends de la version d'apache et du protocole HTTP utilisé pour chaque liaison (tu as 3 requêtes HTTP différentes). Regarde en particulier le mode chunked de HTTP/1.1. Si tu as un filtre de sortie, genre compression, ça augmente les besoins de bufferisation.

Le temps indiqué dans les logs indique-t-il :
- du début de la requête jusqu'à ce que le dernier octet soit renvoyé et la connexion clôturée ?
- du début de la requête jusqu'à ce que le premier octet soit renvoyé ?

C'est le temps depuis l'arrivée de la requête jusqu'au moment où toute la réponse est partie dans la couche réseau et que Apache est en train de logger la ligne. Ça se passe ligne 650 de http://svn.apache.org/viewvc/httpd/httpd/tags/2.2.20/modules/loggers/mod_log_config.c?revision=1163057&view=markup

D'où peut venir cette latence ?

Chaque serveur doit parser la requête qu'il reçoit, appliquer un certain nombre de règles, se connecter au serveur suivant, envoyer sa requête. Dans le pire des cas, il peut avoir un filtre sur la sortie, genre une compression, ou des entêtes à calculer, comme la taille de la réponse.

Si en amont de mes RPs le débit/latence est pourrave cela peut-il faire que le RP molassonne mon WS ?

Pas sur quelques Ko, parce que l'OS fait tampon, mais il est facile de montrer qu'a partir de quelques dizaines ou centaines de Ko, si le RP est bloqué sur une émission vers le navigateur, il ne va pas lire ce qui est arrivé du serveur (l'OS réduit la fenêtre TCP jusqu'à 0 si nécessaire), et toute la chaine ralentie.

Le test est facile à faire, gdb permet d'aller de syscall en syscall (commande "catch syscall" puis "continue" pour avancer) pour ralentir la lecture des paquets. Faire envoyer un gros fichier d'un nc à un autre sur le localhost. Un tcpdump montre bien que la fenêtre TCP tombe à 0, on constate aussi que l’émetteur est bloqué tant que le récepteur ne lit pas de données.

Pas mal, cette notion de tags n'est pas très clair et je n'ai jamais réfléchi à quoi ça pouvait bien servir. Je vais essayer.

Bon, je n'ai pas été clair; je voulais que tu fasses une stack-trace du plantage.

Est-ce que tu as au moins le nom du binaire qui plante dans dmesg ?

Jamais constaté. As-tu une stack-trace du plantage ?

Si tu veux du sans-abonnement sur du DATA, j'ai vu que SFR a une offre de clef en pré-payé, la clef coute une trentaine d'euros, et tu peux acheter des recharges appelées "le Pass Internet 3G+". J'ai fais un tour chez quelques autres opérateurs sans trouvé d'équivalent.

La clef a l'air compatible Linux. Pour la voix, ça m'étonnerait que ça passe.

Je n'ai pas bien compris si tu lançais le rsync depuis PC2 ou depuis PC3, voici la solution depuis PC3, pour l'inverse il suffit d'inverser les noms:

A mettre dans le .ssh/config de PC3:

Host PC1
        ProxyCommand nohup ssh PC2 nc -w1 %h %p

Ensuite tu pourras faire un ssh user@PC1 directement depuis PC3; il n'y a pas de raison que ça pose des problèmes pour rsync.

On reprends:

démarrer un service à la demande ? Y'avait pas un déjà truc qui s'appelait inetd ?

Je parle justement de inetd dans la dépêche; pour t'éviter de tout lire: oui, inetd le fait pour les sockets Internet; mais n'est pas utilisé dans ce mode (généralement il lance une instance par requête). Il semblerait que certaines implémentations existe pour le faire sur les sockets de type fichier; mais je n'en ai jamais vu. Rien n'existe pour les messages SystemV à ma connaissance, ni sur la présence de fichiers dans un répertoire. systemd propose une solution qui généraliste le démarrage à la demande à un maximum de solutions techniques.

eviter de démarrer 1000 processus ? y'a qu'à utiliser un shell plus complet, comme un bon vieux lisp des familles.

On pourrait utiliser emacs ? Le soucis c'est qu'à nouveau, on sort du normalisé. Les shells plus puissant sont généralement bien plus lourds parce qu'ils ont aussi beaucoup de développements liés à l'interactivité qui n'ont aucun intérêt dans un script.

suivre les processus? J'ai du mal avec ça, mais il y a pas un système de log sous linux?

Si, bien sur; mais je ne connais aucun système qui va rediriger les logs des services. Généralement la tache en est confiée au service.

contrôler le contexte du service ? je ne vois pas ce qui ne pourrait pas être fait sous un shell, avec quelques librairies.

A nouveau, rien n'est impossible; mais il n'existe pas de lanceur de service qui s'occupent à la fois de modifier l'user, les groupes, les cgroups, les capacités, le chroot, les logs, le contexte selinux, les limits, le umask et que sais-je encore. A chaque fois ça passe par l'écriture ou le bidouillage du script de démarrage qui n'a généralement pas été prévu pour. On se retrouve avec 150 scripts très semblables dans /etc/init.d dont aucun n'est complet.

Dans ce sens, systemd permet de passer en chroot un service qui n'avait pas été prévu pour, simplement en modifiant son fichier de configuration.

Le mieux est probablement de lire les premiers chapitres de la documentation du kernel: http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt

A hierarchy is a set of cgroups arranged in a tree, such that every task in the system is in exactly one of the cgroups in the hierarchy, and a set of subsystems; each subsystem has system-specific state attached to each cgroup in the hierarchy. Each hierarchy has an instance of the cgroup virtual filesystem associated with it.

At any one time there may be multiple active hierarchies of task cgroups. Each hierarchy is a partition of all tasks in the system.

En résumé: On peut avoir plusieurs hiérarchies; dans chaque hiérarchie on peut mettre plusieurs cgroups. Les processus sont présent une et une seule fois dans chaque hiérarchie.

Cela permet, par exemple, de définir une hiérarchie pour isoler les services et les sessions; et de définir une seconde hiérarchie n'ayant rien à voir pour les I/O disque.

Si j'essaye de résumer les deux solutions

1. Solution à la demande

   • lancer le service à la demande

2. Solution pré-chargement

   • lancer le service au démarrage, au moment où il y a pleins d'I/O
   • attendre que la pression mémoire pousse a récupérer de la mémoire du service
   • virer les pages de texte (le binaire) de la mémoire puisqu'il est déjà sur disque
   • swapper sur disque les pages de données
   • a la première sollicitation remonter les pages de texte depuis le fichier
   • remonter les pages de données du swap

Au final dans la seconde solution, on a chargé une fois de plus le binaire depuis le disque, on a lu et écrit une fois toutes les données, et on a fait le lancement à un moment ou le disque est très sollicité.

Le seul avantage qu'on a, c'est que le service réponds plus rapidement, puisqu'il a déjà été initialisé. Mais en général le temps d'initialisation est ridicule devant le temps de lecture.

Je n'ai pas vraiment plus d'informations que ce qui a été cité dans l'article et dans le thread que tu pointes. C'est une déduction de:

• systemd est déjà dans testing.
• un certain nombre de paquets dans testing sont déjà compatibles systemd

Il y a actuellement un problème qui touche également upstart: sysvinit est taggé comme "Essential".

Enfin je n'ai pas parlé d'avoir systemd comme système par défaut; pour la principale raison qu'il n'est pas compatible avec Debian GNU/Hurd ni avec Debian GNU/*BSD

Ce n'est pas tout-à-fait exact

Le terme double-fork dans son sens littéral est effectivement trompeur. Je n'ai pas voulu expliquer en détail le mécanisme qu'on entends par là pour éviter d'allonger un article déjà très long. Merci de l'avoir fait dans les commentaires.

Suite à une remarque d'un relecteur, j'ai vérifié en écrivant l'article.

http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.39.y.git;a=blob;f=kernel/pid.c;h=57a8346a270e07702e21d7bab15303427bf2fce0;hb=HEAD

Ligne 167 dans la fonction alloc_pidmap(struct pid_namespace *pid_ns)

pid = last + 1;
if (pid >= pid_max)
    pid = RESERVED_PIDS;

La suite de la fonction détermine si pid est utilisé dans ce namespace pour chercher une autre valeur.

La fonction alloc_pid un peu plus bas, fait une boucle dans la pile des namespaces pour affecter un pid dans chaque namespace défini en utilisant alloc_pidmap

Donc le kernel à la vanille incrémente bien de 1 le PID pour chaque nouveau processus, en tout cas tant qu'on n'a pas dépassé pid_max qui vaut de mémoire 0x8000 en mode normal.

Si vous doutez de ma capacité à écrire 10 lignes de code, vous pouvez vérifier sur [https://github.com/pcarrier/stuff/blob/master/fun/forking.c].

Ton test ne fait que le fork; il manque pas mal de travail. Il faudrait tester avec un exec qui va parcourir PATH pour trouver le bon fichier, qui va modifier le mappage mémoire, qui va faire la résolution dynamique des librairies, charger les locales, lire sur stdin, écrire sur stdout, sortir, enfin coté fils il faut encore lire le résultat.

Le test d'une série me semble pas mal, genre partir de n=0 et lancer 2048 fois "bc" en lui passant "n+2".

En shell ça donne ça:

$  time bash -eu -c 'N=0; for I in $(seq 2048); do N=$(echo "$N + 2" | bc); done; echo $N'
4096
real    0m3.352s
user    0m0.940s
sys     0m2.390s

Ce qui fait 3.3 secondes chez moi.