Gnus et reseau

Le 16 juillet 2007 à 21:33, Insitu a formulé :

Re-bonjour (j'en profite),
Merci pour les conseils précédents. J'ai encore quelques petits
problèmes avec emacs, ou plus précisèment avec Gnus. J'ai configuré ce
dernier pour utiliser imaps, tout fonctionne bien, sauf que
régulièrement emacs 'freeze'.

C'est le gros inconvénient de Gnus quand il est question d'interroger
des machines distantes et que ces machines ou la connexion tombent. Ça
vient de la conception du moteur lisp d'Emacs qui n'est pas multi tâches
et je pense qu'il n'y a pas de solution possible à court ou moyen terme
(ça fait longtemps que je ne suis plus à jour de la mailing liste des
développeurs d'emacs mais le réécriture multitâches serait sans doute le
plus gros progrès possible avec l'utilisation interne d'utf - qui elle
est prévue)

Dans le meilleur des cas, je tue openssl
et je peux recharger le groupe ou rafraîchir le buffer *Group*. Il
arrive cependant qu'emacs 'freeze' lors du chargement des groupe de
news normaux nntp (tels que celui-ci).

Si l'interruption intervient en dehors d'un échange réseau de bas niveau
tu peux espérer débloquer le bouzin en campant sur C-g (même si le
minibuffer semble bloqué sur une récupération de message).
Si tu n'as pas de bol, emacs est coincé et seul le kill -9 peut
décoincer (ou le timeout tcp ? mais je crois me rappeler qúil est de
l'ordre de 13 minutes alors faut pas être pressé).

Enfin, en l'utilisant sur un portable qui est régulièrement
ensommeillé donc deconnecté du réseau, je suis souvent obligé de tuer
tout le monde pour repartir sur des bases saines.

Oui, c'est pénible, j'ai le même souci sur mon iBook, heureusement je le
débranche fort peu souvent : je préfère m'y connecter par ssh :)

J'avais auparavant une config à base de fetchmail qui fonctionnait
bien (ou plutôt mieux) mais avait l'inconvénient d'être localisée à
une machine pas toujours accessible en ssh (j'interviens régulièrement
dans des entreprises où les règles sont sévères et stupides:
http/https et point-barre).

J'ai aussi ce problème, mais iptables et ssh ont été ma solution pour
continuer à contacter ma messagerie de l'extérieur, même à travers des
proxy un peu trop contraignants. En gros tu indiques à iptables de
router le port 443 vers le port 22 (éventuellement en restreignant la
redirection à l'ip d'origine (le proxy pénible) si tu la connais. Testé
et approuvé depuis 4 ans depuis divers sites sans souci.

Bon, enfin voila, j'ai retourné le manuel de Gnus mais avec peu de
succès.

Le souci vient en fait d'EmacsOS et pas de Gnus :(

Toute aide serait bien sûr appréciée.

Voilà mon expérience perso, mais si quelqu'un a une solution, je suis
aussi preneur.
--
Sébastien Kirche

Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> writes:

C'est le gros inconvénient de Gnus quand il est question d'interroger
des machines distantes et que ces machines ou la connexion tombent. Ça
vient de la conception du moteur lisp d'Emacs qui n'est pas multi tâches
et je pense qu'il n'y a pas de solution possible à court ou moyen terme
(ça fait longtemps que je ne suis plus à jour de la mailing liste des
développeurs d'emacs mais le réécriture multitâches serait sans doute le
plus gros progrès possible avec l'utilisation interne d'utf - qui elle
est prévue)

J'avais cru comprendre effectivement qu'emacs était 'monotâche' ce qui
n'enlève rien à ses autres qualités mais bon...

Si l'interruption intervient en dehors d'un échange réseau de bas niveau
tu peux espérer débloquer le bouzin en campant sur C-g (même si le
minibuffer semble bloqué sur une récupération de message).

J'essaierai le C-g, merci.

J'ai aussi ce problème, mais iptables et ssh ont été ma solution pour
continuer à contacter ma messagerie de l'extérieur, même à travers des
proxy un peu trop contraignants. En gros tu indiques à iptables de
router le port 443 vers le port 22 (éventuellement en restreignant la
redirection à l'ip d'origine (le proxy pénible) si tu la connais. Testé
et approuvé depuis 4 ans depuis divers sites sans souci.

Oui, effectivement, ça marche si on a que du filtrage par port. Mais
j'ai eu souvent le pb d'avoir un filtrage par proxy donc la, c'est
plus compliqué. Il y a bien ajaxterm, j'ai un ami qui m'en a dit du
bien.

Insitu.

Le 16 juillet 2007 à 22:26, Insitu s'est exprimé ainsi :

> J'ai aussi ce problème, mais iptables et ssh ont été ma solution
> pour continuer à contacter ma messagerie de l'extérieur, même à
> travers des proxy un peu trop contraignants. En gros tu indiques à
> iptables de router le port 443 vers le port 22 (éventuellement en
> restreignant la redirection à l'ip d'origine (le proxy pénible) si
> tu la connais. Testé et approuvé depuis 4 ans depuis divers sites
> sans souci.
>

Oui, effectivement, ça marche si on a que du filtrage par port. Mais
j'ai eu souvent le pb d'avoir un filtrage par proxy donc la, c'est
plus compliqué. Il y a bien ajaxterm, j'ai un ami qui m'en a dit du
bien.

Qu'appelles tu « filtrage par proxy », en opposition au filtrage des
ports ? Un proxy « intelligent » qui analyse ce qui passe ?

Parce pour la plupart des cas, faire passer du ssh (donc chiffré) sur
par le 443 (https) passe inaperçu car comme https est aussi chiffré la
différence ne saute pas aux yeux de tous les admins incompétents que
j'ai pu croiser jusqu'à aujourd'hui. Maintenant si tu es tombé sur un
filtrage intelligent, c'est pas de bol :(
--
Sébastien Kirche

Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> writes:

Parce pour la plupart des cas, faire passer du ssh (donc chiffré) sur
par le 443 (https) passe inaperçu car comme https est aussi chiffré la
différence ne saute pas aux yeux de tous les admins incompétents que
j'ai pu croiser jusqu'à aujourd'hui. Maintenant si tu es tombé sur un
filtrage intelligent, c'est pas de bol :(

En fait, curieusement, les proxy ne font pas la différence, mais elle
serait relativement simple à faire : si j'ai bien compris, En HTTP, le
client parle d'abord (il envoie la requette), alors qu'en ssh, le
serveur parle d'abord (il envoie une banière avec son numéro de
version, ...).

Une fois la liaison établie et les échanges de clés terminés, là,
c'est sûr, c'est plus dûr ...

--
Matthieu

Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> writes:

Qu'appelles tu « filtrage par proxy », en opposition au filtrage des
ports ? Un proxy « intelligent » qui analyse ce qui passe ?

Un 'proxy', pas un filtre justement. Un proxy retraduit une requête
applicative, un filtre une requête transport. Je me trompe peut-être,
mais dans le premier cas, j'envoie une requête HTTP qui est reroutée
vers la destination, dans le second un paquet IP.

Insitu.

Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> writes:

'Lut,

C'est le gros inconvénient de Gnus quand il est question d'interroger
des machines distantes et que ces machines ou la connexion tombent. Ça
vient de la conception du moteur lisp d'Emacs qui n'est pas multi tâches
et je pense qu'il n'y a pas de solution possible à court ou moyen terme
(ça fait longtemps que je ne suis plus à jour de la mailing liste des
développeurs d'emacs mais le réécriture multitâches serait sans doute le
plus gros progrès possible avec l'utilisation interne d'utf - qui elle
est prévue)

Je garde un oeil sur celui-là, les dernières lignes de la page de
présentation sont vraiment alléchantes :
http://www.sxemacs.org/

--
Je vous conseil vivement de répondre à ce message, que je ne
manquerais pas de ne pas lire.
-+- D in www.le-gnu.net - L'autisme pour les nuls -+-

Le 17 juillet 2007 à 07:26, Insitu a dit :

Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> writes:

>
> Qu'appelles tu « filtrage par proxy », en opposition au filtrage des
> ports ? Un proxy « intelligent » qui analyse ce qui passe ?
>

Un 'proxy', pas un filtre justement. Un proxy retraduit une requête
applicative, un filtre une requête transport. Je me trompe peut-être,
mais dans le premier cas, j'envoie une requête HTTP qui est reroutée
vers la destination, dans le second un paquet IP.

Ak, ok donc pour appeler les choses par leur nom il y a le proxy qui
filtre et / ou sert de mandataire (éventuellement avec un cache pour ne
pas redemander plusieurs fois la même ressource) l'http, et le firewall
qui filtre et / ou route des ports et des paquets ip.

Parfois le firewall peut servir à dérouter de façon transparente (i.e.
sans que le client final ne le remarque) le trafic http du port 80 vers
un proxy qui filtrera les sites autorisés, c'est courant en entreprise).

Avec putty par exemple il n'y a pas de souci en général avec les proxys
qui respectent un minimum les standards (proxy socks), mais j'ai le cas
d'un proxy brain dead microsoft qui oblige à s'authentifier en ntlm et
qui ne respecte pas (ben tiens) l'utilisation des variables habituelles
HTTP_PROXY_USER et HTTP_PROXY_PASS... J'ai trouvé une solution grâce à
un proxy en python[¹] qui s'installe localement et qui lui est capable de
s'authentifier sur le proxy MS.

Donc si l'usage du proxy est obligatoire, le paramétrage de putty est
possible (putty existe en linux et windows au passage, autrement je ne
sais pas comment on fait en unix, les autres fois j'ai pu utiliser ssh
en direct). Et quand un firewall t'interdit le port 22 mais que tu peux
au moins utiliser http (80) ou https (443) ou encore pop (110) (mais
bizarrement beaucoup plus rarement imap (143)) tu peux soit faire
écouter le sshd que tu souhaite joindre sur ces ports, soit faire router
les paquets sur le port 22 quand ils arrivent sur l'un des autres
ports...


[¹] http://ntlmaps.sourceforge.net/ il mérite un coup de pub
--
Sébastien Kirche - Mitnick junior ;)

Le 17 juillet 2007 à 09:08, Eric Masson s'est exprimé ainsi :

Je garde un oeil sur celui-là, les dernières lignes de la page de
présentation sont vraiment alléchantes :
http://www.sxemacs.org/

Ouahou, il y a des trucs assez intéressants là-dessus !
J'y jetterais bien un coup d'oeil de plus près. Un ou 2 bémols,
cependant :
- « SXEmacs does not support the Win32 platform and it never will. Yes,
we consider this a feature. »
- et c'est un fork d'XEmacs... sans vouloir relancer les guerres de
religion, j'ai simplement essayé un moment XEmacs (j'ai même proposé
des builds de la dernière version quand Andrew Choi (mainteneur du
port MacOS X d'Emacs) est passé à XEmacs mais au final je n'ai pas
accroché, peut-être parce que j'utilisais des features de la version
cvs d'Emacs qui n'avaient pas d'équivalent XEmacs. S'y remettre
implique Yet Another Migration de la conf...

Merci pour le tuyau.
--
Sébastien Kirche

Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> writes:

- et c'est un fork d'XEmacs...

Et c'est fait par un maniaque du fork.

Déjà, forker un fork d'Emacs, c'est pas mal, mais il avait réussi à
forker Xtla (interface pour GNU Arch dans Emacs) aussi. Il m'avait
envoyé un patch qui ne _pouvait_ juste pas marcher. 3 bugs en un
patch, alors qu'on était en phase de stabilisation pre-1.0, j'avais
rejeté le patch, je lui ai suggéré d'installer GNU Emacs si il voulait
contribuer à un truc portable entre les différents Emacs (il utilisait
des trucs XEmacs-specifiques toutes les 3 lignes). Il m'a traité
d'idiot, et il a forké sans rien me dire, je m'en suis rendu compte
bien plus tard, en cherchant dans google (quand je dis « forké »,
c'est bien un fork, avec tout ce qu'il faut pour empêcher le merge :
ré-importation dans le gestionnaire de version au lieu d'une branche,
renommage des fonctions, et pour être sûr que ça foute bien la merde,
on s'arrange pour garder quelques conflits avec l'original, pour que
l'utilisateur ne puisse pas avoir les deux installés en même temps).
Le résultat de leur histoire, c'est qu'en quelques mois, ils étaient
totalement largués au niveau fonctionalité, et ils n'ont jamais pu
bénéficier du boulot qu'on faisait en upstream.

Dans l'annonce initiale de la création de SXEmacs [1], le type
justifiait le fait qu'il forkait XEmacs plutôt que d'y contribuer
directement par ceci :

,----
| We don't wish to eventually become absorbed into the XEmacs (or
| GNU/Emacs) code base, and we have no desire for the opposite to
| happen.
|
| I'm a leader, not a follower, the SXEmacs Project is the same. I
| sincerely hope you can keep up with (even surpass) us.
`----

Que je traduirait en Français par un truc du genre « J'ai fait SXEmacs
parce que là, au moins, c'est moi le chef ».


Bref, si vous croyez à la pérénité de ce truc, bah pas moi.

--
Matthieu

Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> writes:

Ak, ok donc pour appeler les choses par leur nom il y a le proxy qui
filtre et / ou sert de mandataire (éventuellement avec un cache pour ne
pas redemander plusieurs fois la même ressource) l'http, et le firewall
qui filtre et / ou route des ports et des paquets ip.

C'est ce qu'il me semble.

Donc si l'usage du proxy est obligatoire, le paramétrage de putty est
possible (putty existe en linux et windows au passage, autrement je ne
sais pas comment on fait en unix, les autres fois j'ai pu utiliser ssh
en direct). Et quand un firewall t'interdit le port 22 mais que tu peux
au moins utiliser http (80) ou https (443) ou encore pop (110) (mais
bizarrement beaucoup plus rarement imap (143)) tu peux soit faire
écouter le sshd que tu souhaite joindre sur ces ports, soit faire router
les paquets sur le port 22 quand ils arrivent sur l'un des autres
ports...

Oui, j'ai utilisé putty sous windows, c'est très bien. Je suis plus
souvent sous linux donc j'utilise plutôt ssh/scp. Je parle bien de
proxying, j'ai effectivement travaillé dans des contextes avec
firewall et dans ce cas, c'est très simple de changer le
port d'écoute de sshd ou d'utiliser le tunneling de ssh. Il y a aussi
tsocks que l'on m'a conseillé mais je ne suis pas parvenu à l'utiliser
correctement.

Mais il y a des clients paranoïaques (sans raison d'ailleurs, c'est
pas la DGSE): dans le cas que j'ai en tête, non seulement on ne
pouvait utiliser que du http/https au travers d'un proxy/cache, mais
en plus on ne pouvait pas télécharger ce qu'on voulait et parfois le
proxy analysait le contenu des .jar :) J'en connais qui utilisent
ajaxterm, mais je n'ai personellement jamais essayé.

Insitu.