Jeff Forcier ( bitprophet ) publicó:

(descripción modificada para que los bloques de código tuvieran sangría :))

el 2009-11-02 a las 09:35 a. m. EST

Sería increíble si el túnel también fuera compatible al revés. Lo que significa escuchar en remoto y reenviarlo a localhost/otro host:puerto disponible localmente.

Sin embargo, @munhitsu , no estoy seguro de cómo ese es un caso de uso específico para Fabric. ¿Puedes elaborar?

Imagine una configuración de DMZ que no tenga un acceso http/proxy saliente.
Todo el despliegue pasa por la estructura.

En tal caso, podríamos usar fabric para tunelizar el proxy local a través de ssh, para que sea temporalmente accesible para el host que se acaba de aprovisionar en DMZ. En este momento, estoy abriendo un túnel ssh separado en la segunda consola, de modo que la estructura funcione dentro del "contexto" de este túnel.

ejemplo de uso:

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

De acuerdo, después de todo, supongo que es una configuración de túnel inverso bastante estándar, y su deseo re: Fabric es que maneje hacer el túnel en lugar de tener que ejecutar, por ejemplo local(ssh -R ...) .

Reflexioné sobre si esto realmente valía la pena entrar en el núcleo, pero realmente tendría bastante sentido que fuera compatible con Fabric propiamente dicho; las otras soluciones son hacky (por ejemplo, algún hilo o subproceso que ejecuta ssh -- cómo hacer esto bien, asegúrese de que se apague cuando lo haga Fab, etc.) y veo la validez del caso de uso (compartir local recursos con el extremo remoto durante la ejecución).

El obstáculo principal es que no estoy seguro de que SSH lib admita esto todavía; Tendremos que resolverlo y alguien tendría que implementarlo si no es así. (Sin embargo, creo que sería una buena adición a dicha biblioteca, en lugar de solidificar la solución alternativa ssh -R mencionada anteriormente).

EDITAR: # 38 analiza la implementación y parches y tal. Podría ser mejor cerrar esto y simplemente anotar allí que cuando se implemente, debería ser posible activarlo con un administrador de contexto si es posible.

Estoy totalmente de acuerdo en que tenerlo implementado para que entremos, salgamos de contextos o, peor aún, múltiples niveles de contextos es complicado.

Con respecto a EDITAR: Cualquier cosa que nos mantenga más cerca de tener esta funcionalidad es una buena idea.

Por ahora dejaré esto abierto, solo para mantener las cosas granulares. Sin embargo, lo asigné a 1.4 para que no lo olvide. Lo más probable es que trate de eliminar esto justo mientras hago el n.º 38. Se actualizará aquí cuando esté en maestro, gracias.

En realidad, esto no está tan relacionado con el n. ° 38 como pensaba, ya que sus cambios se refieren únicamente a la puerta de enlace del tráfico SSH en sí, no a la canalización de puertos adicionales a través de la conexión SSH. Eso requerirá una solución diferente (o al menos, adicional). Punting por ahora, lo siento :) (Significado: todavía abierto, simplemente no llegará en 1.5.)

Hace poco necesitaba esta funcionalidad para sincronizar con un servidor rsync remoto cuyo puerto no es accesible directamente y descubrí que el código de demostración de paramiko forward.py tiene un código de muestra que podía usar, así que se me ocurrió una solución que funcionó bien para mí y lo envió como un parche para forward.py aquí: https://github.com/paramiko/paramiko/pull/504/

Podríamos agregar ForwardServer de ese parche y tener un local_tunnel() que simplemente devuelva una instancia de ForwardServer . Según la recomendación de @bitprophet sobre la solicitud de extracción, trabajaré en un parche para Fabric.

De hecho, no me di cuenta, pero ya hay un parche para local_tunnel() , aunque no estoy completamente seguro de su estado. ¿Qué tengo que hacer?

@haridsv Si puede, probarlo y mencionar que lo usó con éxito, en ese parche (# 939), ayudaría, de lo contrario, solo tenga paciencia :) ¡gracias!

¿Hay algún plan para resolver este problema? Hay dos solicitudes de incorporación de cambios pendientes que juntas resuelven esto, pero no se han revisado. ¿Alguna manera de acelerar esto?

939, #1218

He estado usando el código en el #1218 sin problemas.

939 todavía está en un cubo de lanzamiento, lo acabo de eliminar de la próxima versión 1.11 porque necesitaba eliminar _algunas_ cosas, pero tendrá prioridad para el próximo ciclo de funciones. (Y parece que el n.º 1218 reemplaza al n.º 939, así que probablemente terminaré fusionando eso y acreditando el n.º 939 en el registro de cambios).