servidor


6
mar 12

rsync sobre ssh sin utilizar claves

No Gravatar
Server backup transfer

http://www.engadget.com/2006/06/06/how-to-back-up-your-blog/

Hace algunas semanas atrás tuve la oportunidad de sincronizar 2 servidores remotos, se trataba de hacer respaldos en un servidor y enviarlos a otro de manera automática, utilizando ssh y evitando escribir la clave del servidor remoto..

Lo primero que hay que tener en cuenta es que utilizaremos rsync, ssh y necesitaremos generar una clave pública y privada.. entonces empecemos.

Describiré al servidor de donde obtendré como ORIGEN y al servidor donde lo depositaré como DESTINO..

Generar las claves en el servidor ORIGEN:

origen:# ssh-keygen -t rsa -b 2048

Lo que sigue es copiar el archivo id_rsa.pub generado y enviarlo al servidor destino..

origen:# ssh-copy-id -i /home/jack/.ssh/id_rsa.pub jack@servidor-destino.local

En este momento la salida del comando anterior les dirá que hagan una prueba y se conecten al servidor destino.. que en mi caso aparece:

Now try logging into the machine, with "ssh 'jack@servidor-destino.local'", and check in:
 
~/.ssh/authorized_keys
 
to make sure we haven't added extra keys that you weren't expecting.

Y pues vamos a probarlo.. queremos estar seguros de que funciona lo que estamos haciendo.. esto lo hacemos desde el servidor ORIGEN.

origen:# ssh jack@servidor-destino.local

Ahora sin necesidad de escribir la clave del servidor DESTINO tendrán acceso a éste.. y hasta aquí ya esta casi todo el trabajo hecho.. Luego terminan la sesion en el servidor DESTINO para regresar al servidor ORIGEN.. ya casi para terminar lo único que faltaría es tomar el archivo o carpeta que deseamos enviar del servidor ORIGEN al servidor DESTINO.. y para estoy hacemos lo siguiente:

origen# rsync -avz -e ssh /home/jack/respaldos/* jack@servidor-destino.local:/home/respaldos/

Y verán aparecer una lista de todos los archivos que estan en su carpeta de respaldo que de forma equivalente en mi caso es /home/jack/respaldos/

Cualquier error en la transferencia la verán inmediatamente.. pueda que tengan problemas pero creo que sería por cosa de permisos..

Antes de que se me olvide.. les recuerdo de que desde el servidor ORIGEN todos los comandos los deben ejecutar en modo root.

Espero les sirva el tip.

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon

14
feb 12

REST vs SOAP

No Gravatar
REST vs SOAP

REST vs SOAP

Aunque REST y SOAP son arquitecturas muy similares de intercambio de información entre aplicaciones web y de escritorio con servidores, antes de decidirse por uno de ambas es importante tener en cuenta las siguientes consideraciones. Trataré de ser objetivo en este artículo ya que hasta hace poco empecé a utilizar REST (4 meses), todo lo que aprendí sobre websvices esta basado en SOAP.

Primeramente hay que entender que REST esta basado en una arquitectura donde se identifican los recursos claves a consumirse.. veámoslo como una forma semántica de escritura ante la web donde hay métodos que al ser interpretados nos retornan información… Algo como por ejemplo utilizando el método GET del protocolo HTTP (digo GET porque también se puede utilizar POST, PUT, HEAD, DELETE, etc.. ) haría una petición de la siguiente manera: “http://servidor.com/api/proyecto/1/tarea/5″  .. donde api es el contenedor de mi webservice y lo que sigue sería equivalente a decir.. Del proyecto con identificador no. 1 seleccionar la tarea con identificador no. 5 y mostrar el resultado en formato json o xml.

Así de fácil es REST, mientras que SOAP es un poco más complicado por que lo que se consumen son métodos o funciones almacenadas igualmente en un servidor.. entonces si quisiera hacer lo mismo.. en SOAP tendría que escribir algo como lo siguiente: “http://miservidor.com/api/calcula” donde calcula contiene una definición de funciones (sumar y restar) que se pueden implementar mediante la creación de un objeto, un concepto de la programación orientada a objetos .. del uso de alguno de los métodos listados en el servicio calcula como respuesta obtendría una salida en xml con una definición del tipo de datos que respondió el servidor..

Si se fijan ambos tipos de conexión ya sea REST o SOAP se parecen mucho, ya que sirven para solicitar información a un servidor, pero distan de implementarse de una manera similar.. verán que REST es mucho más fácil y SOAP conlleva escribir un poco más de código..

En la actualidad muchos de los servicios que utilizamos a diario como twitter, facebook, fourquare, delicious, flickr, etc.. estan basados en REST por la facilidad de imlementación y la simplesa que se obtiene en los resultados.

SOAP ya que tiene una arquitectura de respuesta más compleja, es utilizado comunmente en corporaciones, hasta me atrevería a decir que la mayoría de empresas que utilizan sistemas basados en .NET o Java tienen sus servicios de comunicación basados en SOAP .. porque ha decir verdad es muy fácil implementar esos objetos y consumir esos métodos.. porque claro!! hay personas que ya hicieron todo el trabajo pesado de crear librerías que se usan casi con un par de líneas. Además que en estos lenguajes se tienen componentes visuales que se conectan casi de manera transparente a webservices basados en SOAP por lo que como dije.. ya todo lo interesante ya se hizo.

Entonces ya que tenemos una mejor idea de que hace REST vs SOAP podemos hacer comparaciones y obtener una conclusión..

REST

En lo que es genial

  • Es muy ligero, sus respuestas contienen exactamente la información que necesitamos.
  • Para los nosotros los humanos es muy fácil y simple de interpretar.
  • Es sencillo de desarrollar y no se necesita mucho código extra.
  • Es flexible en cuanto al tipo de respuesta que se necesita, ya que puede ser xml o json.
En lo que falla
  • Creo que la seguridad es un problema y puede llegar a ser una tarea muy difícil implementarla correctamente.
  • No hay un estándar en sus respuestas por lo que no se definen tipos de datos.
SOAP

En lo que es genial

  • Si trabajas con componentes y utilizas .NET o Java es muy sencillo de consumir.
  • El resultado que siempre es XML contiene una definición específica del tipo de dato, lo que hace del protocolo algo muy estricto.
  • Se dice que es más seguro porque su implementación siempre o la mayoría de las veces se hace del lado del servidor.

En lo que falla

  • Una vez implementado, si se desea cambiar algo en el servidor impacta de forma negativa en los clientes ya que estos tienen que hacer muchas modificaciones al código.
  • Las respuestas son demasiado complejas y difíciles de interpretar si no se tienen las herramientas correctas para hacerlo.

Conclusión

Creo que ambas arquitecturas de intercambio de información tienen sus nichos bien definidos, cuando se trata de aplicaciones públicas refiriéndome a servicios de uso masivo es mucho mejor utilizar REST por la sencillez en su implementación y respuestas, inclusive en clientes móviles es mucho más fácil utilizar REST. Por otro lado si se esta pensando en webservices para corporaciones donde se manejan datos complejos y se necesita una presición detallada en las respuestas se debe de utilizar SOAP, entornos de desarrollo como Visual Studio hacen que el desarrollo e implementación de SOAP sea sumamente sencillo sin tener que escribir código de más para interpretar respuestas.

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon

Qbit Mexhico Blog is using WP-Gravatar