Jonathan Giannuzzi a écrit 21 commentaires

En fait, en ligne de commande sous windows, les commutateurs "/" fonctionnent comme les commutateurs "--" en unix, c'est à dire que
runas /u:plop /ne cmd
est équivalent à
runas /user:plop /netonly cmd
A partir du moment où il y a suffisamment de caractères pour ne pas avoir d'ambiguïté entre les différents commutateurs, le raccourci est compris.

Merci pour ta réponse courtoise.
Si tu regarde l'heure à laquelle j'ai posté mon commentaire, tu remarqueras que c'était avant ta réponse sur les tooltips, et même avant la question à laquelle tu faisais allusion.

Sinon, je tenais juste à te signaler que dans la plupart des applications GTK que je connais, le premier tooltip apparaît après un certain laps de temps, mais les suivants apparaissent et disparaissent instantanément; ce qui correspondrait bien au comportement que tu décris.

C'est assez simple à tester. Dans une application GTK qui possède une toolbar, se placer sur le premier bouton, attendre l'arrivée du tooltip, puis faire glisser la souris de bouton en bouton...

Cordialement ;-)
Jonathan

Ça ne viendrait pas tout simplement de la création et de la destruction des tooltips, ces petites étiquettes qui apparaissent pour donner plus d'information sur une entrée de la liste?

As-tu déjà essayé de laisser le curseur de la souris sur une entrée de la liste sans bouger?

Sur OSX, il n'y a que GNU make sous la dénomination make.
Donc même sur les systèmes propriétaires, la commande ne s'appelle pas toujours gmake.

Conclusion: comme le dit Larry Cow (et comme réalisé par les autotools), il suffit de faire un script qui vérifie quel exécutable est GNU make, et d'en utiliser le résultat.

Je pense que ça dépend vraiment de la boîte en fait.

Dans mon équipe par exemple, tout le monde a PuTTY, mais tout le monde n'a pas Java...
Dans d'autres équipes, ils ont tous SecureCRT (qui est aussi un client SSH, mais proprio), mais de nouveau pas Java.
Et sur nos différentes machines AIX, Linux et Solaris, de nouveau, il y a du SSH, mais pas de Java.

Mais je peux bien comprendre que chez toi (et certainement chez beaucoup d'autres), ce soit l'inverse.

En tout cas, avec SSH et OpenVPN, je n'ai, jusqu'à maintenant, jamais eu de problèmes pour me connecter chez moi (et je touche du bois!)

euh... installer?

Pour OpenVPN, je suis d'accord, puisque il faut utiliser le driver TAP sous Windows ou insérer le module tun.o sous Linux (je ne sais pas pour les autres OS, j'avoue n'avoir jamais essayé).

Par contre, si tu veux faire du SSH, ben sur la plupart des *nix (MacOS X compris), c'est livré en standard!
Et sous Windows, tu as PuTTY qui est un simple petit exécutable de 400 Ko!

Pour httptunnel, même chose, un simple petit exécutable pour tous les OS, bref rien à installer!

Par contre, le VNC en java dans webmin, c'est bien, mais tu fais comment sans installer de JRE? :p (sans compter que c'est pas top top du VNC tout nu non crypté...)

Ce qui est quand même étrange, c'est que manatlan rencontre aussi ce problème lorsqu'il lance un deuxième serveur X en local.

Peut-être jeter un oeil dans $HOME/.xsession-errors ?

En théorie, que tu utilises NX, xming, ou n'importe quel serveur X distant ou local, s'il te manque des icônes, ce sera partout ou nulle part.

Si tu rencontres ce problème avec NX, tu devrais l'avoir en local aussi.

Pour information, NX utilise en fait un serveur X comme client. Je pense que c'est X/Cygwin sous Windows, et un bon vieux Xnest sur les *nix.

Alors là non, pas du tout!

Avec ssh, tu as une simple compression gzip (qui n'est donc pas spécialement adaptée à X11).

Avec NX, c'est un ensemble de techniques de compression spécialement conçues pour X11, comme par exemple le fait de réduire les allers-retours entre le client et le serveur.

Le mieux, c'est d'essayer! Tu verras, c'est vraiment bluffant!
Si je me souviens bien, il y a moyen de t'inscrire pour un Test Drive sur leur site. Tu reçois un user/pass pour te connecter en NX sur un de leurs serveurs.

De toute manière, l'idée de base de NX, c'est justement de faire l'équivalent de ssh -NX toto@computer, la compression en plus.

debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: Sending env LANG = fr_FR.UTF-8
debug1: Remote: X11 forwarding disabled; not compatible with UseLogin=yes.

Ca m'a l'air assez clair...

Tu devrais enlever le "UseLogin yes" de ton sshd_config.
Je ne sais pas si c'est la valeur par défaut sur une Ubuntu, mais en tout cas, sur ma Debian, c'est UsePam qui est utilisé plutôt.

Pour information (venant de sshd_config(5)):

UseLogin

Specifies whether login(1) is used for interactive login sessions. The default is ``no'' Note that login(1) is never used for remote command execution. Note also, that if this is enabled, X11Forwarding will be disabled because login(1) does not know how to handle xauth(1) cookies. If UsePrivilegeSeparation is specified, it will be disabled after authentication.

Quand tu fais une connexion https en passant par un proxy, tu fais en fait une requête CONNECT.
Cette requête demande au proxy d'établir une connexion TCP pour toi.
Une fois la connexion établie, tu fais passer ce que tu veux dedans, HTTPS (c'est à dire SSL) ou autre.

Techniquement, il serait faisable d'identifier le genre de traffic qui passe (différence entre SSL et autre), mais en pratique ce n'est jamais fait.

En plus, certains proxys mal configurés vont te permettre de faire des CONNECT sur d'autres ports que le 443...

Ce qui est encore plus intéressant qu'un sshd sur le port 443 quand on est derrière un proxy au boulot, c'est de faire tourner un openvpn.
Là, plus besoin de s'amuser avec le port forwarding, tu as directement accès à tout ton réseau local!
Personnellement, c'est la solution que je privilégie. Je fais tourner un openvpn sur mon Linksys WRT54GS sous OpenWRT et je suis très content!

Encore une autre solution pour passer à travers le proxy, si les CONNECT sont interdits (très peu probable), c'est d'utiliser httptunnel comme mentionné dans un commentaire plus haut.
Ca te permet d'établir une connexion TCP encapsulée dans du HTTP.

Bref, il y a toujours moyen de s'en sortir... (sans oublier TCP over DNS ou TCP over ICMP...)

un autre moyen simple de voir ce qui se passe:

en local sur ta machine ubuntu, tu fais un ssh -X -v localhost (tu dois avoir DISPLAY qui est défini évidemment (à ":0" par exemple) et tu regardes ce qu'il te dit et si DISPLAY vaut bien "localhost:10.0".

si tu ne trouve pas, envoie toujours l'output obtenu.

Tiens, je profite de ce journal pour poser la question:

Est-ce que quelqu'un a déjà réussi à utiliser nxtunnel (ou nxproxy je ne sais plus) manuellement?

Je m'explique:
Ce que je n'aime pas trop avec NX, c'est qu'il crée un utilisateur nx grâce auquel le client se connecte, et l'authentification n'est faite que par la suite. En plus, il rajoute une clé publique correspondant à la clé privée qui se trouve dans tous les clients NX (si j'ai bien compris...).
Bref, je n'aime pas trop, j'aurais de loin préféré une vrai authentification de l'utilisateur faite via ssh (et donc, le choix de la méthode: password, key, etc.).

Puisqu'après tout NX n'est qu'un proxy X11 qui compresse (très bien d'ailleurs!), je me demande s'il ne serait pas possible de l'utiliser manuellement.
Cela me permettrait par exemple de faire passer du X11 compressé dans un tunnel ssh (exactement ce que fait NX), mais aussi dans un VPN, ou un réseau local dans lequel je n'ai pas peur de ne pas être crypté, etc.

L'idée étant d'avoir le contrôle complet de ce qui se passe, même si c'est bien moins "user-friendly".

Je pense que tu n'as pas installé le package xbase-clients. Celui-ci est suggéré par openssh-client sur ma debian.

Ce package contient la commande xauth qui est nécessaire pour faire du forwarding X11 avec ssh.

Une fois installé, pas besoin de redémarrer le daemon sshd, tu fais simplement une nouvelle connection, et tu auras une valeur pour la variable DISPLAY.

Après, tu vas voir, tout sera magique...

Euh... je ne vois pas vraiment où tu veux en venir?

Pour moi, .Net est le successeur de COM+, mais il ne l'utilise pas.
Le principe de COM+, c'est de faire dialoguer entre eux des objets écrits dans différents langages de programmation (typiquement C++ et VB). Il n'y a pas un serveur COM+, mais des serveurs COM+ (chaque objet COM est un serveur). De plus, tout cela est plus ou moins réimplémenté en libre pour les Unix via Wine.

Maintenant, .Net, c'est une spécification de plateforme (le CLR), d'api (les classes de base), et aussi de différents langages (VB.Net et C# principalement). C'est une technologie comparable à Java de ce point de vue-là (plateforme = JVM, api = les classes de base, langage = Java).
Et rien ne l'empêche d'être portable, puisque les spécifications sont standardisées et ne requièrent nullement une technologie propriétaire comme COM+.

Trois preuves:
- l'implémentation en Shared Source de Microsoft qui tourne sur FreeBSD: Rotor
- l'implémentation de Ximian/Novell qui tourne sur plusieurs Unix et sous Windows (et sur plusieurs architectures): Mono
- l'implémentation GNU (dont je ne connais pas bien les détails, mais qui tournent aussi sur plusieurs OS/archi): DotGNU

De plus, on peut franchement dire que les implémentations libres de .Net font plus que "marchoter" comme tu le laisses sous-entendre. Il suffit d'aller voir sur http://go-mono.com/asp-net.html(...) par exemple pour te rendre compte que leur implémentation d'ASP.Net est parfaitement fonctionnelle.

Donc, non, je ne suis pas d'accord, pour moi Java et .Net sont parfaitement comparables, que ce soit sous Linux ou Windows (ou autre).

Je comprends parfaitement qu'ils n'intègrent pas Mono à cause de l'ombre des brevets logiciels qui planne dessus.

Mais là où je ne comprends pas, c'est pourquoi ils peuvent intégrer un environnement Java libre?
Il n'y a pas de brevets dans son cas? Et l'histoire de Kodak?

Attention, je ne dis pas que c'est une mauvaise chose d'intégrer Java dans Fedora, bien au contraire!
Je ne comprends juste pas pourquoi ce ne serait pas possible pour Mono.

Tu veux peut-être dire GTK en *LGPL* sous windows? C'est ça justement qui fait l'intérêt de ce toolkit pour les gens qui veulent faire du proprio portable.
QT est, lui (ou plutôt sera lorsque la version 4.0 sortira) disponible sous licence GPL pour windows, et donc ne fait pas la joie des gens qui veulent faire du proprio avec un toolkit "gratuit". Par contre, c'est génial pour les gens qui font du libre :)

Tu trouves vraiment qu'elle a de l'humour?
Il est assez bien dissimulé alors...

Bonjour,

Je crois que tu n'as pas compris sa question 1) qui était:

Pourquoi le site conseille-t-il de se connecter en https alors que le rss propose des liens en http ? Existe-t-il un fil rss dont les liens sont en https ?

Je suis moi aussi victime de ce manque de liens https. En effet, j'utilise Akregator pour lire les fils RSS en https. Lorsque je clique sur un lien, il est ouvert en http et utilise les cookies de Konqueror.
Le résultat, c'est que, comme tu le disais à juste titre, quelqu'un de mal intentionné peut usurper mon identité sur le site.

Voilà, tout ça pour dire que je trouve aussi dommage que les flux RSS ne proposent pas les liens en https.

Et si on mettait http --> http://www.w3.org(...) comme d'autres ont déjà fait?

Vu dans les FAQ:

Is Navigator compatible with the most popular browsers?
When Navigator needs to open a browser, it simply instructs your computer to launch your default browser, whatever that might be.

Je me demande vraiment pourquoi ils appellent ça Navigator...