Utilización de OAuth 1.0 en Google Apps con python bottle

Siguiendo con el uso de OAuth como en la entrada anterior Utilización paso a paso de OAuth 1.0 en twitter con python bottle seguimos con la utilización de este mecanismo de autorización, pero esta vez utilizando Google Apps como proveedor de servicios. Toda la discusión sobre las características principales de OAuth 1.0 está en la entrada anterior, por lo que recomendamos su lectura previa a cualquier lector interesado. Google ya no recomienda utilizar la versión 1.0 de OAuth, que dan por obsoleta (“deprecated”) y recomiendan realizar nuevas aplicaciones utilizando OAuth 2.0, pero en nuestro caso, que se trata principalmente de un ejercicio académico para comprender el funcionamiento de OAuth y puesto que ya tenemos una mini aplicación desarrollada, vamos a reutilizar la mayor parte de este código para interactuar ahora con una de las múltiples APIs de las que dispone Google, en concreto Google Apps Email Settings API Authentication.

Utilización paso a paso de OAuth 1.0 en twitter con python bottle

El objetivo de esta entrada es explicar de la forma más clara posible la manera de utilizar el protocolo OAth 1.0 en la API de twitter, para la que desarrollaremos una sencilla aplicación que nos permitirá escribir un “tweet” en nombre de un usuario cualquiera de twitter que nos autorice. La aplicación la desarrollaremos en Python utilizando el framework bottle y la desplegaremos en la PaaS OpenShift de RedHat.

Uso de APIs web RESTful con Python requests

Uno de los métodos que se están imponiendo en Internet para la comunicación de aplicaciones con servicios web disponibles es una API web tipo RESTful o REST, este método está desplazando paulatinamente a XML-RPC que está en progresivo desuso o SOAP, protocolo que es una recomendación de la W3C para ofrecer servicios web.

Las API REST está imponiéndose a otros métodos por su sencillez, y a pesar de que no son un protocolo bien establecido como SOAP, tienen un conjunto de aspectos que las definen:

• Se utiliza una URI para definir el servicio web
• Los datos se transfieren utilizando un formato como estandarizado (XML y JSON son los dos más extendidos actualmente)
• Se utilizan métodos estándar HTTP: GET, POST, PUT o DELETE

En esta entrada veremos mediante algunos ejemplos la forma de utilizar APIs REST desde una aplicación Python, utilizando la biblioteca requests.

Acceso remoto con ssh utilizando ssh-agent

Esta es una entrada egoísta :-), la escribo para no tener que buscarlo en Internet cuando de vez en vez me hace falta utilizar este tipo de conexión ssh, aunque poniéndola aquí quizás sea útil a alguien más.

ssh es una maravilla de aplicación que permite acceder a sistemas tipo UNIX de forma remota y segura, pudiendo utilizar diferentes mecanismos para autenticar el usuario siendo la contraseña y el par de claves pública/privada los dos mecanismos más usados. En esta entrada explicaremos las diferentes opciones que hay de utilizar acceso con pares de claves pública/privada, terminando con la utilización de ssh-agent que motiva la escritura de esta entrada.

Seminario en eMadrid: Despliegue de un cloud privado de IaaS

Seminario impartido en eMadrid el pasado 18 de Enero en la que explicamos las características del despliegue de OpenStack para uso educativo realizado en nuestro centro.

Seminario eMadrid sobre “Aprender con software libre” – Despliegue de un Cloud privado de IaaS from eMadrid net on Vimeo.

Instalación de Joomla en OpenShift

OpenShift es la Plataforma como servicio (PaaS) de cloud computing de Red Hat. OpenShift puede utilizarse de varias maneras: mediante su cloud público que se denomina OpenShift Online, o bien instalando directamente en un cloud privado el software OpenShift Origin disponible en GitHub.

En esta entrada vamos a explicar los pasos que hay que seguir para desplegar la aplicación web Joomla en OpenShift Online utilizando una cuenta gratuita limitada, lo que OpenShift denomina FreeShift, poniéndo el énfasis en comprender los pasos que damos. En este caso hemos elegido Joomla porque por una parte es una aplicación muy sencilla de instalar y por otro lado porque no está preconfigurada en OpenShift, lo que permite obtener una visión más general del proceso que puede utilizarse de forma muy similar para instalar cualquier otra aplicación web.

Acceso a un sistema UNIX mediante chroot

En algunas ocasiones es necesario acceder con todos los privilegios a un sistema al que no podemos acceder directamente porque tiene algún problema en la configuración, no arranca adecuadamente, hemos olvidado la contraseña de root o alguna situación similar. Para esos casos es muy cómodo y útil utilizar un sistema auxiliar (CD-live, arranque por PXE, etc.) y acceder al otro sistema mediante chroot.

¿Qué es chroot?

En sistemas UNIX, chroot permite cambiar el directorio raíz de un proceso y todos sus hijos. En principio los programas que se ejecuten dentro de este entorno no pueden salir de él, por lo que se denomina habitualmente un entorno “enjaulado” chroot. Para que este procedimiento funcione, es necesario que el directorio destino sea el directorio raíz de un sistema con los mínimos elementos para funcionar, ya que una vez dentro de la jaula chroot no podemos utilizar ningún recurso de fuera de ella.

Utilizar chroot

Para acceder a un entorno enjaulado con chroot, en principio basta con dos simples instrucciones: montarlo y acceder a él con chroot (supongamos que tenemos un sistema diferente al que se ha arrancado en la partición 7 del disco /dev/sdb):

root@equipo:~# mount /dev/sdb7 /mnt
root@equipo:~# chroot /mnt /bin/sh
# pwd
/

La siguiente imagen representa un entorno enjaulado como el anterior, montado en el directorio /mnt:

En algunos casos es suficiente con esto, por ejemplo si queremos modificar un fichero del sistema montado en /mnt o algo similar, sin embargo no es suficiente si necesitamos que el nuevo sistema acceda a los dispositivos del equipo, ya que no tiene acceso a ellos. Para solventar este problema, en caso de que sea necesario que el sistema acceda a los dispositivos del equipo, procederemos de otra manera, antes de ejecutar la instrucción chroot, montaremos los directorios /dev, /dev/pts, /proc y /sys del sistema operativo que se está ejecutando en el directorio /mnt:

root@equipo:~# mount /dev/sdb7 /mnt
root@equipo:~# mount --bind /dev/ /mnt/dev
root@equipo:~# mount --bind /dev/pts /mnt/dev/pts
root@equipo:~# mount --bind /proc /mnt/proc
root@equipo:~# mount --bind /sys /mnt/sys
root@equipo:~# chroot /mnt /bin/sh
#

De esta manera el entorno enjaulado verá como propios estos directorios, tal como se representa en la siguiente imagen:

Ahora el entorno enjaulado tendrá acceso a red, podrá manejar los dispositivos del equipo, etc., por ejemplo podrá instalar su propoi gestor de arranque GRUB en el primer disco del equipo:

# grub-install /dev/sda

que utilizará el ejecutable /usr/sbin/grub-install del sistema enjaulado, pero lo aplicará sobre el disco /dev/sda del equipo al que ahora sí tiene acceso.

Hay una limitación a todo esto: El entorno enjaulado sigue utilizando el kérnel del sistema que se arrancó, por lo que funcionará mejor cuanto más similares sean los dos sistemas.