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é.
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.
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)
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.
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)
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'
[^] # Re: Misc
Posté par symoon . En réponse au message Configurer sendmail pour php. Évalué à 2.
Depuis putty; simplement en sélectionnant comme sous X.
Depuis une autre application: avec Ctrl+C
# variables d'environnement
Posté par symoon . En réponse au message Comportement étrange de /bin/more. Évalué à 2.
Regarde la différence du résultat de la commande 'env'.
[^] # Re: Misc
Posté par symoon . En réponse au message Configurer sendmail pour php. Évalué à 2.
* pour coller dans putty, bouton droit.
# c'est sous tes yeux !
Posté par symoon . En réponse au message PB d'install du mod-security2 pour apache. Évalué à 3.
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é.
[^] # Re: dependances...
Posté par symoon . En réponse au message PB d'install du mod-security2 pour apache. Évalué à 3.
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
[^] # RTFQ
Posté par symoon . En réponse au message Plusieurs domaines, et serveurs httpd.. Évalué à 2.
http://wiki.squid-cache.org/SquidFaq/ReverseProxy
# ouh le méchant troll
Posté par symoon . En réponse au journal Dell va proposer deux portables sous Ubuntu en Europe. D'autres portables avec SuSE à suivre. Évalué à 7.
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 !).
# dans le dhclient.conf
Posté par symoon . En réponse au message Problèmes dhcp... Évalué à 2.
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.
[^] # Re: en ayant lu
Posté par symoon . En réponse au message p3scan : ce qu'il fait ou ne fait pas. Évalué à 2.
=> Précise le port 110 à ton client telnet.
[^] # Re: bugzilla ????
Posté par symoon . En réponse au message recherche de logiciel. Évalué à 3.
[^] # debian woody ?
Posté par symoon . En réponse au message Telnet ou SSH dans un navigateur web. Évalué à 2.
[^] # Re: attention
Posté par symoon . En réponse au journal Problèmes de window scaling ? Quelle est la meilleure solution face à cela ?. Évalué à 5.
[^] # Re: Re:
Posté par symoon . En réponse au journal Problèmes de window scaling ? Quelle est la meilleure solution face à cela ?. Évalué à 2.
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.
[^] # Re: "Chez moi ça marche pas" (c)
Posté par symoon . En réponse au journal Problèmes de window scaling ? Quelle est la meilleure solution face à cela ?. Évalué à 5.
# meilleure solution
Posté par symoon . En réponse au journal Problèmes de window scaling ? Quelle est la meilleure solution face à cela ?. Évalué à 10.
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..
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).
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 !
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é.
Rien à voir.
Le reste sur : http://linuxfr.org/comments/856353.html#856353
[^] # Re: definition ?
Posté par symoon . En réponse au message Fuzzing windows a partir de Linux. Évalué à 3.
http://fr.wikipedia.org/wiki/Fuzzing
[^] # Re: option window scaling de TCP ?
Posté par symoon . En réponse au message parefeu routeur qui bloque Linux, pas FreeBSD, Windows, Mac. Évalué à 3.
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.
Aucun lien, fils unique (enfin faudrait avoir très très peu de ram pour ne pas pouvoir utiliser le WS).
+par défaut
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.
[^] # Re: option window scaling de TCP ?
Posté par symoon . En réponse au message parefeu routeur qui bloque Linux, pas FreeBSD, Windows, Mac. Évalué à 2.
Détails sur http://kerneltrap.org/node/6723
[^] # en ayant lu
Posté par symoon . En réponse au message p3scan : ce qu'il fait ou ne fait pas. Évalué à 2.
[..]
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
# option window scaling de TCP ?
Posté par symoon . En réponse au message parefeu routeur qui bloque Linux, pas FreeBSD, Windows, Mac. Évalué à 6.
echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
# dogtail
Posté par symoon . En réponse au message piloter des programmes (graphiques). Évalué à 4.
ainsi que ceux listés sur http://en.wikipedia.org/wiki/List_of_GUI_testing_tools
# stfg ssh web browser terminal
Posté par symoon . En réponse au message Telnet ou SSH dans un navigateur web. Évalué à 3.
[^] # Re: Sous Fedora...
Posté par symoon . En réponse au message conversion commande RedHat->Ubuntu. Évalué à 2.
non, et /etc/rc.d/ n'existe pas sous debian en tout cas.
# distcc
Posté par symoon . En réponse au message cross compilation à partir d'une debian/sid. Évalué à 4.
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.
# man apt-get
Posté par symoon . En réponse au message Kwrite sous gnome. Évalué à 3.
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'