Jeff Forcier ( Bitprophet ) schrieb:

(Beschreibung geändert, sodass Codeblöcke eingerückt wurden :))

am 02.11.2009 um 09:35 Uhr EST

Es wäre genial, wenn Tunnel auch andersherum unterstützen würde. Das bedeutet, auf Remote zu lauschen und es an localhost/anderen lokal verfügbaren Host:Port weiterzuleiten.

@munhitsu Ich bin mir jedoch nicht sicher, wie das speziell für Fabric ein Anwendungsfall ist. Können Sie das näher erläutern?

Stellen Sie sich ein DMZ-Setup vor, das keinen ausgehenden http/Proxy-Zugriff hat.
Die gesamte Bereitstellung durchläuft Fabric.

In einem solchen Fall könnten wir Fabric verwenden, um den lokalen Proxy durch ssh zu tunneln, damit er vorübergehend für den Host zugänglich ist, der gerade in der DMZ bereitgestellt wird. Im Moment öffne ich einen separaten SSH-Tunnel auf der zweiten Konsole, damit Fabric im "Kontext" dieses Tunnels funktioniert.

Beispielverwendung:

with rev_tunnel(local=8080, remote=8080):
    sudo("http_proxy='http://localhost:8080' apt-get install -y puppet")

OK, also ist es doch ein ziemlich standardmäßiges Reverse-Tunnel-Setup, denke ich, und Ihr Wunsch bezüglich: Fabric ist, dass es den Tunnel handhabt, anstatt dass Sie z. B. local(ssh -R ...) ausführen müssen.

Ich habe hin und her überlegt, ob es sich wirklich lohnt, in den Kern zu gehen, aber es wäre wirklich sinnvoll, wenn es in Fabric unterstützt würde. Die anderen Lösungen sind hacky (z. B. ein Thread oder Unterprozess, auf dem ssh ausgeführt wird - wie man das gut macht, stellen Sie sicher, dass es heruntergefahren wird, wenn Fab dies tut usw.), und ich sehe die Gültigkeit des Anwendungsfalls (Sharing local Ressourcen mit dem fernen Ende während der Ausführung.)

Haupthindernis ist, dass ich nicht sicher bin, ob die SSH-Bibliothek dies noch unterstützt; wir müssen das herausfinden und jemand müsste es implementieren, wenn nicht. (Ich denke, das wäre jedoch eine gute Ergänzung zu besagter Bibliothek im Vergleich zur Festigung der oben genannten ssh -R Problemumgehung.)

BEARBEITEN: Nr. 38 behandelt die Implementierung und das Patchen und so weiter. Vielleicht ist es am besten, dies tatsächlich zu schließen und dort einfach zu vermerken, dass es bei der Implementierung möglich sein sollte, wenn möglich mit einem Kontextmanager auszulösen.

Ich stimme voll und ganz zu, dass es schwierig ist, es so zu implementieren, dass wir Kontexte betreten, verlassen oder noch schlimmer, mehrere Ebenen von Kontexten.

In Bezug auf EDIT: Alles, was uns näher an diese Funktionalität hält, ist eine gute Idee.

Im Moment lasse ich das offen, nur um die Dinge granular zu halten. Habe es 1.4 zugewiesen, damit ich es aber nicht vergesse. Die Chancen stehen gut, dass ich versuchen werde, das richtig auszuschalten, während ich # 38 mache. Wird hier aktualisiert, wenn es im Master ist, danke.

Dies hat eigentlich nicht so viel mit #38 zu tun, wie ich dachte, da es bei den Änderungen ausschließlich um das Gatewaying des SSH-Verkehrs selbst geht und nicht um das Tunneln zusätzlicher Ports durch die SSH-Verbindung. Das erfordert eine andere (oder zumindest zusätzliche) Lösung. Vorerst punting, tut mir leid :) (Bedeutung: noch offen, wird nur nicht in 1.5 ankommen.)

Ich habe diese Funktion kürzlich benötigt, um mit einem Remote-rsync-Server zu synchronisieren, dessen Port nicht direkt erreichbar ist, und habe festgestellt, dass der forward.py-Democode von paramiko Beispielcode enthält, den ich verwenden könnte, also habe ich eine Lösung gefunden, die für mich und mich gut funktioniert hat reichte es hier als Patch für forward.py ein: https://github.com/paramiko/paramiko/pull/504/

Wir könnten ForwardServer aus diesem Patch hinzufügen und ein local_tunnel() haben, das einfach eine Instanz von ForwardServer zurückgibt. Gemäß der Empfehlung von @bitprophet zum Pull-Request werde ich an einem Patch für Fabric arbeiten.

Ich habe es eigentlich nicht bemerkt, aber es gibt bereits einen Patch für local_tunnel() , obwohl ich mir über seinen Status nicht ganz sicher bin. Was soll ich machen?

@haridsv Wenn du kannst, würde es helfen, es auszuprobieren und zu erwähnen, dass du es erfolgreich verwendet hast, auf diesem Patch (#939), ansonsten nur Geduld :) Danke!

Gibt es einen Plan, dieses Problem zu lösen? Es gibt zwei ausstehende Pull-Requests, die das Problem zusammen lösen, aber sie wurden nicht überprüft? Können wir das irgendwie beschleunigen?

939, #1218

Ich habe den Code in #1218 ohne Probleme verwendet.

939 befindet sich immer noch in einem Release-Bucket, ich habe es nur aus dem kommenden 1.11 herausgeholt, weil ich _etwas_ Zeug kürzen musste, aber es wird Priorität für den nächsten Feature-Zyklus bekommen. (Und es sieht so aus, als ob # 1218 # 939 ersetzt, also werde ich das wahrscheinlich zusammenführen und # 939 im Änderungsprotokoll gutschreiben.)