Preguntas novadas para el pago de SVN y problemas de networking que lo vuelven a

Tenemos un server local con SVN instalado en él que estamos utilizando para fines de desarrollo / testing. Nos gustaría verificar los datos desde el server en vivo que está en algún lugar.

La única forma de hacer eso en lo que pensaba era usar "svn checkout" desde el server en vivo, ¿verdad? De esta forma, no es necesario que enviemos los cambios por FTP, eso puede causar problemas si olvidamos cargar algunos de los cambios. Y si encontramos un problema, siempre podemos volver a la versión estable anterior, ¿verdad? Corrígeme si estoy equivocado sobre alguno de estos.

El problema es que nuestro server local (Ubuntu) no tiene una IP accesible desde el exterior. Tenemos un enrutador desde nuestro ISP, pero no podemos usar eso para acceder al server local desde el directo. Estamos dispuestos a pedirle al proveedor de ISP que configure una segunda IP para el server local, pero por razones de security quieren configurar una máquina separada con Windows y el software de security base de Windows (firewall – http://www.kerio.com/control). / y antivirus) que nos costará mucho. ¿Podemos simplemente configurar un firewall gratis en el server local (Ubuntu como dije) y resolver el problema sin gastar dinero adicional?

Espero haber sido claro.

Si el server remoto tiene un server ssh, entonces puede usar el reenvío ssh.

Desde el server interno svn:

ssh -R 7711:localhost:3690 {REMOTE_SERVER} 
  • 7711 es un puerto arbitrario (puede usar cualquier puerto libre en el sistema remoto) que se reenviará desde el sistema remoto al puerto 3690 (svn) en el server svn.
  • 3690 es el puerto en el server svn interno con el que desea hablar (a través de svn: //).
  • Si está utilizando subversión en http: //, utilice el puerto 80 en lugar de 3690.
  • Si está utilizando subversión sobre https: //, utilice el puerto 443 en lugar de 3690.

Después de configurar el reenvío, puede hacer esto en el sistema remoto:

 svn checkout {SCHEME}://localhost:7711/{PATH} 
  • {SCHEME} es svn, http, https, etc.
  • {PATH} es la ruta de acceso svn normal que deseas verificar.

Notas:

  • el tráfico reenviado se tuneliza a través de la connection ssh (en un "canal" diferente) por lo que también se cifra, lo que es un buen beneficio.

  • de manera pnetworkingeterminada, el extremo remoto del reenvío escuchará en la interfaz loopback, por lo que solo los processs en ese sistema podrán usar el puerto reenviado.

  • Tan pronto como cierre la session ssh, el puerto reenviado también se cerrará. Solo dura la duración de la connection ssh.

  • El reenvío ssh es muy poderoso. Si puede ssh entre dos sistemas, entonces puede evitar cualquier tipo de problema de connection como este.

  • Haga man ssh y lea sobre las opciones -L y -R.

  • Enlaces útiles sobre el reenvío ssh:

Siempre es difícil comentar sin conocer la situación exacta, pero esto suena un poco loco.

Lo que normalmente haría es configurar el reenvío de puertos para un puerto al server local. El server sería accesible (por ejemplo) a través de 123.45.67.89:3690

Esa es una tarea de tres minutos para configurar en un enrutador doméstico normal.

Mientras el server de Ubuntu esté cerrado de lo contrario, y Subversion o lo que sea que esté utilizando para la authentication esté configurado y actualizado correctamente, esto no debería crear problemas de security.

En cualquier caso, poner una máquina Windows en el medio para actuar como un firewall parece realmente innecesario. Ubuntu viene con todo lo necesario para asegurar la configuration correctamente.

compruebe si su enrutador ISP proporciona algunas capacidades de reenvío de puertos. Probablemente deba reenviar el puerto ssh (después de asegurarse de que todas las passwords sean seguras / o forzar el inicio de session con el file ssh keys) y use el protocolo SVN + SSH para acceder a su repository.

Debería poder abrir y reenviar un único puerto (3690 de forma pnetworkingeterminada) en su IP existente al server local, como lo señala Pekka. Esto depende de su enrutador y su capacidad para acceder a la interfaz de configuration en el enrutador.

En lugar de tener que lidiar con SSH y preocuparse por las personas que intentan acceder a su server local desde cualquier lugar, puede configurar un firewall para permitir solo el tráfico entrante desde su único server remoto. Dependiendo de la configuration del enrutador, simplemente podría usar el firewall integrado en el server local. Sin embargo, sería aconsejable tener alguna authentication svn.

El método de reenvío SSH descrito por kanaka evita todo el problema de acceso remoto a la máquina local, pero requiere que ejecute el command de reenvío desde el server local cada vez que necesite acceder a svn en el server remoto.

    Intereting Posts