symoon a écrit 1123 commentaires

pour putty, je voulais savoir comment copier :s

Depuis putty; simplement en sélectionnant comme sous X.
Depuis une autre application: avec Ctrl+C

Sans doute les variables d'environnement (cf la section ENVIRONNEMENT du man 1 de more).

Regarde la différence du résultat de la commande 'env'.

* exim4 est installé par défaut sous debian

* pour coller dans putty, bouton droit.

je suppose que les paquets binaires dispos à la racine du dépôt sont pour sid, d'où la dépendances à une libc6 récente.

Il suffit de lire :
http://etc.inittab.org/~agi/debian/libapache-mod-security2/R(...)

Pour etch, il suffit d'aller dans le répertoire etch :
http://etc.inittab.org/~agi/debian/libapache-mod-security2/e(...)

Je me demande quel gain en sécurité vaut le coup d'installer un paquet binaire d'une source inconnue, dont on ne sait pas s'il sera mis à jour en cas de pb de sécurité.

disons plutôt 4 mois et demi :-)

c'est la 4.0r1 (révision 1 de Etch) qui date d'il y a quelques jours.
Etch 4.0r0 date du 8 avril : http://www.debian.org/News/2007/20070408

La question ne porte pas sur le VH dans apache :-)

http://wiki.squid-cache.org/SquidFaq/ReverseProxy

les 3 actueurs principaux du marché Linux (les autres etant insignifiants) : Ubuntu, SuSE et Redhat

Pour être plus précise et par là-même éviter certains trolls, préciser "les 3 acteurs commerciaux principaux du marché linux" aurait été mieux :-)

Je doute que Debian, Gentoo, Mandriva soient des acteurs insignifiants.

Livrer des portables avec une distribution linux, c'est bien, pouvoir les livrer sans OS, ça serait mieux (et en plus ça respecterait la loi !).

send host-name "toto";

Tu trouveras de la doc en cherchant "dynamic dns" ou "ddns", ou en lisant le man dhclient.conf / dhclient.

Il semble que le client DHCP "pump" envoie par défaut le nom de la machine sans avoir à s'embêter.

Si tu ne précises pas à ton client telnet le port de pop3 (110), celui-ci va utiliser le port par défaut de telnet, le port 23.

=> Précise le port 110 à ton client telnet.

request-tracker, otrs, le BTS debian, etc.

il serait peut-être temps d'upgrader vers sarge/etch :-)

Sauf que tu ne peux pas avoir une fenêtre de 128ko sans window scaling, étant donné que c'est la taille de la fenêtre est comptée sur 16 bits.

Je ne connais pas les détails de l'affaire, Mais si les dev Linux ont fait le choix de ne pas activer le "windows scaling" par défaut,

En l'occurrence, c'est le contraire, les développeurs Linux ont fait le choix d'activer le window scaling par défaut, qui est indispensable pour utiliser le lien à plein quelques soient les conditions de latence / débit du tuyau.

Certainement pas la stack TCP, mais plutôt la stack ethernet ou IP (suivant la config) de l'hôte vmware.

Comme d'habitude, la meilleure solution, c'est de corriger les comportements incorrects, ici les routeurs qui :
1/ touchent à TCP alors qu'ils ne devraient pas !
2/ mettent le WS à 0 sans enlever l'option elle-même !

Alors forcément ensuite les deux bouts de la connexion parlent pas avec la même échelle..

Ce problème n'affecte ni mac os x, ni windows, ni freebsd, ni solaris, seulement linux.

Reformulé correctement: le comportement défectueux des routeurs ne peut être facilement mis en évidence que sous linux à partir du 2.6.17 (et Windows vista aussi).

Est-ce que la force d'un système ce n'est pas d'être suffisamment tolérant aux erreurs, pour pouvoir continuer à fonctionner en cas en problème ?
Mark Lord proposait de garder la fonctionnalité window scale, mais de pouvoir renégocier la transaction TCP sans window scale si la connexion n'aboutissait pas, ce qui me semble raisonnable comme option.

Empiler les hacks pour pallier le comportement de routeurs (qui du coup en touchant à TCP ne sont plus seulement que des routeurs), ça serait vraiment la pire des bêtises.., ou comment se retrouver avec des effets de bords, comme si TCP n'était déjà pas assez compliqué pour en plus se donner la tache de corriger les erreurs de routeurs qui outrepassent leurs attributions.

Les RFC / normes sont là pour éviter de partir dans tous les sens !

Si un nouvel utilisateur Linux (voire un plus ancien) tombe sur ce bug cette fonctionnalité, et qu'il remarque que "sous windows ça fonctionne bien", il va se dire que "linux c'est pourri".

Dans l'autre sens, si un utilisateur voit (qu'avec le WS activé par défaut) il atteint de bien meilleurs débits que sous les autres OS, il sera content.
Et les routeurs foireux sont qd même en minorité.

car apparemment avec une mémoire inférieure ou également à 512 Mo, le problème n'est pas perceptible (à vérifier)

Rien à voir.

Le reste sur : http://linuxfr.org/comments/856353.html#856353

c'est quoi le fuzzing ?

http://fr.wikipedia.org/wiki/Fuzzing

Malgré tout c'est gênant de savoir que certains sites ne fonctionnent pas à cause de cela, et c'est assez hallucinant de lire ici :
http://lwn.net/Articles/92727/

Je ne vois pas en quoi c'est hallucinant. TCP sur internet ne va pas rester à la préhistoire par défaut parce que certains routeurs foutent la merde.

Le window scaling est indispensable pour utiliser à plein un gros tuyau avec un RTT élevé (satellite, lien transatlantique, etc.).

Donc faut penser également à ceux qui n'arrivent pas à tirer le meilleur d'une connexion : il est moins simple de diagnostiquer un faible débit en TCP (vu que c'est aussi lié à la bande passante dispo) que "pas de TCP, mais ping ok".

- Et la RFC a plus de 15 ans, il serait peut-être temps d'en tirer parti
- Les routeurs ne *doivent* pas toucher au niveau TCP, sinon on voit les désastres que ça donne.

Apparemment, la quantité de mémoire de la machine joue aussi.

Aucun lien, fils unique (enfin faudrait avoir très très peu de ram pour ne pas pouvoir utiliser le WS).

Je crois également que vista vient d'incorporer cette option

+par défaut

À mon avis, comme qu'un l'a suggéré sur kerneltrap, la bonne attitude serait d'avoir cette option d'activée malgré tout, et si un site ne répond pas correctement au bout d'un certain moment (1 min par exemple), désactiver l'option, mettre un message en console à ce sujet, et retenter la négociation.

C'est à dire lancer une deuxième session TCP si la première échoue, etc., ouvrir un popup à la demande du noyau ??
Mais c'est du délire complet, excuse-moi :-)

Non la bonne attitude, c'est de mettre un avertissement sur ce comportement dans les notes d'installation des distributions (ce que fait Debian par exemple, cf. http://www.debian.org/releases/stable/i386/release-notes/ch-(...) ), et d'avertir les sites qui se trouvent derrière un routeur qui outrepasse ses attributions en touchant à TCP.

Pour la précision, même si le correspondant ne gère pas le window scaling, cela ne doit pas poser problème, car c'est une option.

Détails sur http://kerneltrap.org/node/6723

Package: p3scan
[..]
Description: transparent POP3-proxy with virus- and spam-scanning

Donc il n'est pas nécessaire d'aller chercher les mails sur le poste sous linux.

iptables -t nat -A OUTPUT -p tcp --dport pop3 -j REDIRECT --to 8110

Je pense qu'il faudrait plutôt utiliser la chaine INPUT pour rediriger tout ce qui va à destination du POP vers p3scan.

Essaie de regarder la doc dans /usr/share/doc/p3scan

Si le ping fonctionne, mais pas les applications TCP, essaie de désactiver sur les linux le window scaling (qui permet d'obtenir des produits débit*RTT plus importants) car le routeur du milieu s'il est trop bête peut ne pas l'apprécier. (normalement le routeur ne doit pas toucher au niveau tcp et rester au niveau IP, mais sait-on jamais)

echo 0 > /proc/sys/net/ipv4/tcp_window_scaling

http://people.redhat.com/zcerza/dogtail/

ainsi que ceux listés sur http://en.wikipedia.org/wiki/List_of_GUI_testing_tools

Sinon en pas efficace du tout (à mon avis), tu peux regarder du côté de ajaxterm.

/etc/init.d n'est-il pas un alias ?

non, et /etc/rc.d/ n'existe pas sous debian en tout cas.

La cross compilation, c'est compiler un programme sur une autre architecture que l'architecture du binaire cible (exemple compiler sur un pc normal un programme destiné à un mips pour borne wifi).

Ce que tu cherche, c'est "simplement" répartir le travail, c'est exactement pour cela que distcc existe.

C'est très simple à mettre en oeuvre, tu trouveras des tuto partout. En revanche, essaie d'avoir la même version gcc sur le vieil ordi comme le récent.
Note : le fait de répartir les calculs via le réseau ajoute pas mal de traitement supplémentaire, on gagne pas forcément de temps à faire du distcc.

--print-uris
Au lieu d'aller chercher les paquets à installer, leurs URI sont affichées. Chaque URI a un chemin, un nom de fichier destination, une taille et une clé md5 attendue.

Avec cette option, tu obtiendras les adresses de tous les paquets à télécharger pour obtenir kwrite : 'apt-get install --print-uris le_paquet'

Tu les places ensuite dans /var/cache/apt/archives

Tu relances la commande même sans l'option --print-uris : 'apt-get install le_paquet'