El logo es un adorable perrito

Es realmente pequeño, unos 9cm de largo y 5,5 de ancho (un poco más grande que arduino) y cuenta con un lector de trajetas microsd (donde metes el SO y lo que tu quieras), un host USB (para enchufarle camáras, teclados, ratones…), un conector RJ45 y un micro USB para conetarlo al PC.

Bien, no me enrrollo más. Todo esto que cuento ya lo han contado cientos de veces en otras páginas así que vamos al tema. Qué hacer cuando sacas el beaglebone de su caja.

Lo primero que se me ocurre es conectarlo al PC por el microUSB y ver que pasa. Tras unos segundos (recuerda que tiene que iniciar el sistema operativo y eso lleva tiempo) el ordenador detectará un dispositivo de almacenamiento masivo mediante el cual podrás acceder a las particiones que tengas excepto la usada por beaglebone. Recuerda que en esa tarjeta de memoria también están los archivos del sistema operativo. Por defecto la tarjeta trae dos particiones, la que he comentado (que es un Angstrom Linux) y una FAT donde trae unos archivos de manual y drivers para windows y mac. En linux no te hará falta instalar nada.

Bien, ya sabemos que el cacharrito funciona, ahora vamos a hacer algo más divertido. Vamos a conectarnos por consola a nuestro beaglebone y a hozar un poco. Por supuesto también podrías enchufarle un monitor y un teclado pero para conectarle un monitor necesitas una shield (que es carilla) o fabricarla tu mismo.

Para nuestra siguiente labor, en Linux tenemos que cargar un módulo a mano ya que no reconoce las uuid (he leído que en futuras versiones esto lo cambiarán). No es grave, lo hacemos con este comando

sudo modprobe ftdi_sio vendor=0x0403 product=0xa6d0

Sería un rollo poner esto siempre así que creamos un fichero llamado /etc/udev/rules.d/73-beaglebone.rules con el siguiente contenido

ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_interface", 
        ATTRS{idVendor}=="0403", ATTRS{idProduct}=="a6d0", 
        DRIVER=="", RUN+="/sbin/modprobe -b ftdi_sio"

ACTION=="add", SUBSYSTEM=="drivers", 
        ENV{DEVPATH}=="/bus/usb-serial/drivers/ftdi_sio", 
        ATTR{new_id}="0403 a6d0"

ACTION=="add", KERNEL=="ttyUSB*", 
	ATTRS{interface}=="BeagleBone", 
        ATTRS{bInterfaceNumber}=="00", 
	SYMLINK+="beaglebone-jtag"

ACTION=="add", KERNEL=="ttyUSB*", 
	ATTRS{interface}=="BeagleBone", 
        ATTRS{bInterfaceNumber}=="01", 
	SYMLINK+="beaglebone-serial"

Ahora cada vez que enchufemos el beaglebone se detectara sin problema. Esto nos creara una interfaz en /dev/ttyUSBX donde X es un numero que depende de los cacharros que tengas conectados. Ahora ya sólo tenemos que conectarnos, para ello uso el comando screen de esta manera:

screen /dev/ttyUSB1 115200

El número 115200 es la velocidad de transmisión (simula un puerto serie). Si todo va bien, veremos algo como la siguiente imagen.

El login por defecto es root y no tiene contraseña. Una vez dentro puedes manejarlo como un Linux cualquiera!

Ya tenemos control absoluto sobre nuestro aparatito. Sí, podríamos escribir programas en C, compilarlos y ejecutarlos (o pyhton o lo que te de la gana, incluso puedes tener tu servidor apache con php y conectarlo a tu LAN por el RJ45) pero vamos a utilizar una herramienta muy interesante que trae que se llama cloud9. Colud9 es un IDE que se ejecuta en un navegador. Está en el beagle bone y desde nuestro navegador accedemos, compilamos y ejecutamos programas. Todo ello sin instalar ningun software en nuestro ordenador y disponible en cualquier momento. Por defecto programaremos con este IDE como si lo haríamos con javascript (la sintaxis) que para quienes los conozcan se llama Node.js.

Como hemos conectado el beagle bone mediante USB, muchos servicios están desativados e incluso el procesador va a menos ciclos (a 500 en vez de 700). El motivo es que el USB no proporciona la energía necesaría. Para tener funcionando a pleno rendimiento tendríamos que usar la entrada de 5V. Pero queremos algo sencillo y que funcione ya así que crearemos una interfaz ethernet a través de USB. Calma, esto ya viene preparado de serie y es muy sencillo de hacer. Tan sólo tienes que desmontar la unidad de almacenamiento (que se llama BONE nosequé) y automáticamente se iniciará eso del ethernet por usb. Ojo, si te pasa como a mi y no se inicia nada después de desmontar la unidad de almacenamiento ejecuta el comando “eject” para forzarlo. En mi caso es “eject /dev/sdh”. En algunas distribuciones no hace falta, yo uso debian y me llevó un motón de tiempo averiguar por qué narices no funcionaba. Recuerda, si no va usas el comando eject y listo.

Ahora hacemos ifconfig y veremos una interfaz de red nueva. En mi caso se llama eth1 y tiene la IP 192.168.7.1. Esa es la IP que el beagle bone ve. Es una maravilla porque ello sólo se encarga de configurar todo. Si queremos conectarnos al beagle usaremos la dirección ip 192.168.7.2 desde nuestro PC. Si por lo que sea (nunca se sabe) ha cogido otra IP lo que tenemos que hacer es conectarnos por serie al beaglebone (como expliqué antes) y con ifconfig ver qué IP ha cogido. Con esta IP podemos hacer SSH al beagle o lo que queramos, la verdad es que es muy divertido. Ya sea por ssh o por serie nos conectamos al beaglebone y ejecutamos el comando “cloud9″. Tras unos segundos veremos el iconito de la nube con un 9 dentro y debajo pone:

“Project root is: /var/lib/cloud9
Point your browser to http://localhost:3000″

Ya está listo. Vamos a nuestro navegador y accedemos a http://192.168.7.2:3000/ Cargará el IDE que además viene con unos ejemplos y en concreto uno llamado blink.js. Con este ejemplo haremos parpadear a un LED. Beagle bone cuenta con un chorro de pines de entrada/salida (Ojo que funcionan a 3.3V no a 5V así que ni se te ocurra conectarlo directamente a un arduino o aparatos que usen 5V. Si estás interesado busca sobre level shifter o pregúntame a mi )

Los bancos de pines se llaman P8 y P9 (está escrito en un lado). Ese ejemplo usa el pin 3 que está en el banco P8 (bone.P8_3). Si te fijas, en las cuatro esquinas de cada banco aparecen unos numeritos (en caso de P8 pone 2,1   46,45). Eso indica el número del pin. Hay un montón de pines diferentes y para usos diferentes y todo eso viene en la documentación oficial. Para encender un LED conectaremos el polo positivo (patita larga) al pin 3 y el negativo al pin 1 o 2 (son de masa, tierra o ground como quieras llamarlo). Ya sólo nos queda darle a “Run” y veremos como se enciende y apaga el LED. Si! Es la cosa más sencilla del mundo pero esto es sólo el principio! A partir de ahora puedes aplicar todos tus conocimientos para crear todo tipo de robots y autómatas!

Por cierto, te recomendaría que apagues el beaglebone antes de desenchufarlo. Si estás habituado al arduino igual tienes la costumbre de desconectar directamente pero recuerda que esto es como tu ordenador., hay que es apagarlo correctamente (con el comando halt por ejemplo) antes de desenchufar. De la misma manera que con tu ordenador normal, si lo desconectas directamente podrías crear incogruencias en el sistema de ficheros o cortar un proceso importante del sistema operativo (de acuerdo, nunca pasa nada pero cuando pasa, pasa)

Por último, una foto con el arduino (si es necesario es hace una comparativa o algo entre ambas máquinas) o si necesitas más detalles o ayuda con el beagle bone tal vez pueda ayudarte.

En mi caso ejecutaré OpenCV en mi robocoche y algun algoritmo más pesado de toma de decisiones (o una red neuronal). Ya os iré contando novedades

Nos vemos!

Edito par añadir un par de enlaces (en inglés).
Documentación oficial: beagleboard.org/static/BONESRM_latest.pdf

Guía oficial: http://www.beagleboard.org/static/beaglebone/a3/README.htm

Entradas relacionadas.

Antes de nada, os pongo un vídeo del resultado.

Click here to view the video on YouTube.

Sí, ese es el menda jugando. ¿Te interesa saber cómo puedes hacerlo? Si es así sigue leyendo, de lo contrario sólo perderás tu tiempo.

Lo primero y antes de nada tengo que decir que mi código del arduino es una vil copia del proyecto Gamecube-N64-Controller. Ese proyecto permite jugar a la nintendo 64 con un mando de la gamecube. De ahí básicamente saqué el protocolo de comunicación y las funciones para “dialogar” con la n64 (que ya es bastante!!).

También tengo que aclarar que jugar con el wiimote es bastante más complicado. El stick del nunchuk es bastante mediocre comparado con el joystick de la nintendo 64 (para mi uno de los mejores que han existido), de ahí mi manqueo a la hora de apuntar a ganondorf con el arco. El segundo motivo es que el juego está preparado para responder a una única pulsación, entonces responderá sólo cuando hayamos terminado el movimiento lo cual implica movimientos “retardados”. Es mucho más rápido pulsar un botón que hacer el gesto del movimiento de la espada.

Ahora voy a explicar más o menos como funciona la cosa. Tenemos un mando de la wii con nunchuk y queremos jugar a la nintendo 64. El primer problema que se nos plantea es que el mando de la n64 va por cable mientras que el wiimote es inalámbrico. Mi solución ha sido usar el ordenador como pasarela: el wiimote se conecta al ordenador por bluetooth y luego el ordenador mediante usb al arduino, quien simula ser un mando de n64. Si quieres hacer algo más profesional siempre puedes usar el módulo bluetooth para arduino y desarrollar una biblioteca de comunicación. Llegados a este punto vemos que necesitamos dos programas, uno para el arduino y otro para el ordenador. Vamos a ello.

Software para arduino

Nuestro arduino va a ser simplemente un enlace sin ningún tipo de lógica. Nosotros le enviamos los datos y directamente se lo sirve a la consola sin nada de procesamiento (en el proyecto de gamecube que mencioné antes, el arduino realiza las operaciones necesarias para convertir los comandos). El motivo es para que sea más práctico, así sólo es necesario modificar le programa de ordenador si queremos hacer cualquier cambio. La función loop del programa arduino se ha reducido bastante, ya que al recibir los datos preparaditos para enviar no tiene que hacer más que eso (recibir datos del ordenador por el puerto serie y tal cual mandarlos a la consola).

Software para ordenador

Utilizo la biblioteca cwiid desde python y en principio es multiplataforma (aunque sólo lo he probado en Linux). Doy por supuesto que tienes un dispositivo bluetooth funcionando y el software de arduino instalado. Este programa python también es sencillo. Lo que hace es conectarse al mando de la wii (usando cwiid), obtener las pulsaciones de botones y mandarlas al arduino. La verdad es que, sabiendo el protocolo del mando es muy sencillo pero llegar a manejar bien un protocolo cerrado de esos es un infierno. Voy a tratar de explicar (sin detalles técnicos) un poco como funciona.

Funcionamiento del mando de nintendo 64

La consola puede mandar 4 tipos de comandos diferentes al mando. Estos son de identificación, de estado, de lectura y de escritura. Los dos últimos, hasta lo que yo se (recordemos que es un protocolo cerrado y vete tu a saber que más cosas hace) es para gestionar el rumble pack (un aparato que hace al mando vibrar). Cuando encendemos la consola, ésta manda el comando de identificación al que los mandos conectados (en nuestro caso el arduino) y éstos deben responder. Si no, la consola nos mostrará un bonito “NO CONTROLLER”. Por último, la consola nos manda el comando de estado cuando necesita saber que botones estamos pulsando. Cuando la consola nos pregunte por el estado nosotros respondemos. Al contrario de lo que mucha gente pueda pensar, no es el mando quien manda información todo el rato a la consola, sino que es la consola quién pregunta al mando todo el rato que botones hay pulsados. Nuestra labor va a ser que cuando la consola pregunte por esa información el arduino se la entregue.

Ahora veamos qué información es la que mandamos. El paquete con toda la información sobre el estado del mando (los botones pulsados) son 4 Bytes. De estos 4 Bytes, los dos primeros expresan el estado de los botones y los dos últimos la posición del joystick. Para el caso de los botones es bien sencillo, bit a 1 boton pulstado y bit a 0 boton no pulsado. De esta manera con 2 Bytes podemos representar 16 botones y como la consola tiene 14 pues incluso son sobran 2 bits. El contenido exacto de los bytes es este:

Byte 1: A, B, Z, Start, PadArriba, PadAbajo, PadIzquierda, PadDerecha

Entonces si tenemos pulsado el botón A, el primer byte será: 1 0 0 0 0 0 0 0, si pulsamos A y Z será: 1 0 1 0 0 0 0 0. Sencillo de entender, verdad?
El segundo byte contiene: 0, 0, BotonL, BotonR, C-Arriba, C-Debajo, C-Izquierda, C-derecha
Como dije antes nos sobran dos bits, que son esos dos primero bits que siempre valen 0.

Por último nos quedan los bytes para el joystick, el byte 3 contiene la posición X y el byte 4 la posición Y. Para representarlo se utiliza un byte con signo más o menos desde -80 a 80. Esto es muy importante ya que cuando mandemos la información en binario hay que tener muy claro lo que mandamos para que todo funcione bien y de manera sencilla (por eso en el programa python, al empaquetar los bytes los primero con con B, unsigned char, y los dos último son b, signed char). Nosotros generaremos ese paquete de 4Bytes y por el puerto serie se lo mandaremos al arduino.

Ya conocemos la teoría así que a programar. Yo he elegido python pero puedes usar el que te de la gana siempre y cuando generes bien esos 4 Bytes. El programa de arduino te servirá igual.

Obtener el código fuente

El código fuente lo he subido a github y por supuesto con licencia GPL. Puedes clonarlo usando esta dirección https://github.com/maxpowel/Wii-N64-Controller
Si ves algun fallo o quieres compartir una configuración de botones (sobretodo es interesante el tema del acelerómetro del wiiomte) te agradecería que me hicieras un pull request

Montaje

Material:

• Arduino (y su cable USB)
• 2 Cablecitos
• Nintendo 64
• Ordenador
• Bluetooth

Supongo que no tendrás problemas para conectar tu arduino y bluetooth a tu PC. El siguiente paso es conectar el cable de tierra de la conexión del mando a un pin de tierra del arduino usando uno de los cablecitos. El otro cable es para unir el pin 8 (puedes usar el pin que quieras, pero en el código uso el 8 ) con el de datos de la consola. El esquema de pines del mando es el siguiente:

1. +3.3V – Alimentación. No lo usamos ya que el arduino tiene su propia alimentación.
2. Datos – Conectado con el pin digital 8
3. GND – Conectado a un pin de tierra de arduino

Nota: Recuerda que este es el esquema del mando y el de la consola quedará espejado (mirando de frente a la consola se usan los dos pines de la derecha). Espero no haberte líado con esto

Como nota, decir que siempre hay que encender primero el arduino antes que la consola ya que de otra manera no detectará ningún mando. Recuerda lo que dije antes de que la consola cuando se enciende “pregunta” a los mandos para ver qué hay conectado.

Para terminar un pequeño vídeo de como tengo montado el tinglao.

Click here to view the video on YouTube.

Entradas relacionadas.

En bases de datos relacionales (MySQL por ejemplo) una vista  es como un “resumen” de un conjunto de consultas. Un orm es una herramienta de programador que te ayuda a trabajar con bases de datos desde tu aplicación.

Doctrine es el ORM (junto a propel) que trae por defecto el framework php symfony (mi favorito) y como no hay mucha documentación sobre las vistas, y menos en castellano, pues aquí va este pequeño manual.

Mi manera de trabajar es trabajar lo menos posible (vagooo!!). Calma! Lo que quiero decir es que cuanto más trabaje el ordenador por mí, más rápido y mejor se desarrolla una aplicación. Por este motivo yo no me molesto en escribir ni una sóla consulta SQL salvo que sea estrictamente necesario (como veremos que será cuando hagamos las vistas).

Por supuesto no quiere decir que saber SQL sea inútil ni mucho menos. Es más, para trabajar bien (de manera eficiente) con un ORM necesitas saber SQL como el comer.  Este el motivo por el que yo “sólo” hago el diseño de la base de datos y el ordenador genera todo lo demás por mí. Esto tiene muchas ventajas como por ejemplo la independencia del sistema (da igual que uses mysql, postgres…) y reducción de errores (que si se me olvida una foreign key por ahí, que si por qué falla esta consulta si está “perfecta” y después de media hora ves que era una coma, etc).

Además, el ordenador también crea las clases para manipular los datos (geters y seters entre otras muchas cosas).

En concreto con Doctrine (y symfony en general) eso se lo indicamos mediante archivos YML

Hasta aquí todo bien pero… no hay soporte para vistas!! Entonces toca hacerlo a mano… Esto es un problema, porque empiezas a depender de tu SGBD pero por otra parte, es vital si quieres obtener un buen rendimiento para determinadas consultas.

Bien, después de toda esta insustancial parrafada vayamos al turrón

Usaré un ejemplo real, sacado de Wixet.

create or replace view search_profile
as
SELECT user_id,gender,uid,birthday,city_id,country_id,town_id FROM profile

Es simple, verdad? Así nos centraremos en lo importante, la clase Doctrine.

Diferenciamos 2 tipos de clases, las nuestras y las de doctrine. Las “nuestras” están vacías de serie mientras que en las de doctrine es donde está todo el meollo. El motivo es que si añadimos métodos propios, doctrine los machacará. Por eso están diferenciadas. Luego una hereda de otra así que el resultado final es algo totalmente homogéneo.

abstract class BasesearchProfile extends sfDoctrineRecord
{
        //Because profile is acl protected, we use this view to
        //get some data when doing an user search
    public function setTableDefinition()
    {
        $this-\>setTableName('search_profile');
        $this->hasColumn('user_id', 'integer', 4, array(
             'type' => 'integer',
             'primary' => true,
             'length' => 4,
             ));
 
        $this->hasColumn('gender', 'integer', 1, array(
             'type' => 'integer',
             'length' => 1,
             ));
        $this->hasColumn('uid', 'string', 25, array(
             'type' => 'string',
             'unique' => true,
             'length' => 25,
             ));
        $this->hasColumn('birthday', 'date', null, array(
             'type' => 'date',
             ));
        $this->hasColumn('city_id', 'integer', 4, array(
             'type' => 'integer',
             'length' => 4,
             ));
        $this->hasColumn('country_id', 'integer', 4, array(
             'type' => 'integer',
             'length' => 4,
             ));
        $this->hasColumn('town_id', 'integer', 4, array(
             'type' => 'integer',
             'length' => 4,
             ));
    }
 
    public function setUp()
    {
        parent::setUp();
        $this->hasOne('sfGuardUser as user', array(
             'local' => 'user_id',
             'foreign' => 'id',
             'onDelete' => 'CASCADE'));
 
        $this->hasMany('interest as interests', array(
             'local' => 'user_id',
             'foreign' => 'profile_id'));
 
        $this->hasOne('city', array(
             'local' => 'city_id',
             'foreign' => 'city_id',
             'onDelete' => 'SET NULL'));
 
        $this->hasOne('country', array(
             'local' => 'country_id',
             'foreign' => 'country_id',
             'onDelete' => 'SET NULL'));
 
       $this->hasOne('city as town', array(
             'local' => 'town_id',
             'foreign' => 'city_id',
             'onDelete' => 'SET NULL'));
 
       $this->hasMany('place as places', array(
             'refClass' => 'placeUser',
             'local' => 'user_id',
             'foreign' => 'user_id'));
 
        $this->hasMany('workplace as workplaces', array(
             'refClass' => 'workplaceUser',
             'local' => 'user_id',
             'foreign' => 'user_id'));
 
        $this->hasMany('school as schools', array(
             'refClass' => 'schoolUser',
             'local' => 'user_id',
             'foreign' => 'user_id'));
 
        $this->hasMany('city as cityplace', array(
             'refClass' => 'cityUser',
             'local' => 'user_id',
             'foreign' => 'user_id'));
 
        //No full relation to make searches faster
        $this->hasMany('placeUser', array(
             'local' => 'user_id',
             'foreign' => 'user_id'));
        $this->hasMany('workplaceUser', array(
             'local' => 'user_id',
             'foreign' => 'user_id'));
        $this->hasMany('cityUser', array(
             'local' => 'user_id',
             'foreign' => 'user_id'));
        $this->hasMany('schoolUser', array(
             'local' => 'user_id',
             'foreign' => 'user_id'));
 
    }
}

Perdón por los  “> ” pero es que el wordpress insiste en convertir los “>”

El archivo puede ser algo confuso, pero su estructura es sencilla.

//Primero definimos los datos de la tabla
//En el método "setTableDefinition"
$this->setTableName('search_profile'); //Nombre
//Y lo siguiente para cada tipo de dato
        $this->hasColumn('user_id', 'integer', 4, array(
             'type' => 'integer',
             'primary' => true,
             'length' => 4,
             ));
//En el metodo setup
 
<pre lang="php">        parent::setUp();//Ejecutamos el setup de la clase padre, que es la otra que hemos creado
//Las relaciones. La estructura es sencilla si conoces algo de doctrine
        $this-&gt;hasOne('sfGuardUser as user', array(
             'local' =&gt; 'user_id',
             'foreign' =&gt; 'id',
             'onDelete' =&gt; 'CASCADE'));

Ahora metemos esos archivos en sus respectivos directorios (/lib/model/doctrine en el caso de symfony) y ya lo tenemos!

Ahora ya puedes usar la clase pero ojo, es una vista, no intentes cambiar sus datos. Doctrine lanzará una excepción mysql si lo intentas. Para todo lo demás, funciona como una tabla normal.

Nota: si esto te parece muy complicado, otra opcion es crear un archivo yml una tabla equivalente a la vista (en cuanto a datos y relaciones) y posteriormente eliminar la tabla de mysql e insertar tus vista. En este caso, ojo con usar atributos tipo timestamptable o poner ondelete cascade/update en las relaciones porque recuerda que una vista es sólo de lecutra.

Nota2: Cuidado cuando hagas doctrine:clean, como no encontrará un yml correspondiente a esa tabla te dirá que si quieres borrar la clase. Tendrás que responder que no, lógicamente.

Entradas relacionadas:

1. Conoce SQL – VIEWS (vistas) Ahora ya sabemos como hacer consultas bastante completas, pero ademas...
2. Autenticación LDAP en Symfony Buenas, hoy voy a hablaros de autenticación de usuarios usando...

Symfony es un framework PHP, el cual ofrece la posibilidad de usar LDAP para autenticar usuarios. Pero sólo eso, la “posibilidad” nada más (que no es poco). Nosotros tenemos que crear la clase que conecte symfony con el servidor ldap y que modifique, cree y haga todo lo necesario en el mismo. Exactamente eso es lo que tendremos al terminar de leer esta entrada.

¿Por qué usar LDAP?

De esta manera usamos un servicio de autenticación genérico. Imagina que nosotros tenemos nuestra página web con sus usuarios y de repente se nos antoja instalar un foro o un blog o un servidor xmpp… software de terceros que manejan los usuarios como quieren. Con LDAP nos olvidamos de todos los rollos, configuramos todo ese software para que use LDAP y listo.

¿Cómo trabaja Symfony con LDAP?

Es simple. Symfony sigue manteniendo su base de datos pero ademas comprueba que el usuario es válido en el servidor LDAP. Esto es que cuando te autenticas en Symfony, primero mira si el usuario es válido en la base de datos de Symfony y si es válido lo mira en LDAP. Si uno de los dos falla, la autenticación falla. Entendemos entonces que la “dificultad” está en mantener las bases de datos sincronizadas.

¿Qué haremos nosotros?

Lo que haremos será que cada vez que symfony produce un evento (nuevo usuario, usuario eliminado o cambio de contraseña) symfony se lo notificará al servidor LDAP.

Comencemos…

Antes de nada decir que uso sfDoctrineGuardPlugin para la gestión de usuarios y supongo que tienes una instalación de Symfony funcionando. Según el README del plugin tenemos que poner algo así en app.yml

all:
  sf_guard_plugin:
    check_password_callable: [ldapLogin, checkPassword]

Y por requerimientos del plugin ldapLogin (que así he llamado yo a mi clase) tiene que ser una clase estática y tener un método llamado checkPassword que devolverá verdadero o falso. Además los argumentos son usuario y contraseña (en ese orden).
Una vez hemos metido ese parámetro en app.yml creamos en /lib (si, el lib del proyecto así te sirve para todas la aplicaciones) “ldapLogin.class.php”.

Yo he aprovechado y en esa misma clase he metido los métodos de creación de usuario, modificación y borrado. El esqueleto de la clase sería algo así

class LdapLogin {
 
	public static function checkPassword($user,$pass){
		//Devolver verdadero o falso
	}
 
	public static function createUser($user,$pass){
	}
 
	public static function removeUser($user){
	}
 
	public static function updatePassword($user,$pass){
 
	}
 
}

Ya tenemos un poco en mente lo que queremos. Antes de continuar, vamos hacer nuestro sistema un poco más versátil. Como la localización, datos de administrador y todo lo relativo a LDAP puede variar vamos a hacer que esos datos sean leídos de un archivo de configuración.

Yo he utilizado el archivo config/settings.yml del proyecto y la estructura que he elegido es esta:

all:
  ldap:
     admin: uid=admin,ou=system
     password: 123456
     hostname: 127.0.0.1
     suffix: ou=users,ou=system

En admin pones el dn del admin ldap. Suffix es donde se guardan los usuarios. Esta configuración es la que se usaría si tu servidor LDAP es Apache Directory Server.

Para acceder a esa configuración podemos hacerlo de dos maneras, una es directamente a cada valor

sfConfig::get(‘sf_ldap_suffix’)

O cargando el archivo yml en una variable

$settings = sfYaml::load(sfConfig::get(‘sf_root_dir’).”/config/settings.yml”);
$suffix = $settings['all']['ldap']['suffix'];

Estos dos códigos hacen lo mismo. Si sólo vas a coger un dato la primera opción es mejor mientras que para varios yo prefiero la segunda pero para gustos los colores.

Ya sabemos como lo queremos hacer. Ahora queda hacerlo. Lo primero es saber cómo conectarnos a un servidor LDAP mediante php. Este código te ayudará

$ds = ldap_connect($host,$port);//Nos conectamos
if(!$ds) throw new Exception('Cant connect to LDAP host "'.$host.'"');
//Si no se pudo conectar, lazamos una excepción
ldap_set_option($ds, LDAP_OPT_PROTOCOL_VERSION, 3);//Usamos la versión 3, si no lo pones php or defecto usa una version mas vieja
 
if(!ldap_bind($ds, $admin,  $adminPass)) throw new Exception('Cant bind to LDAP host "'.$host.'"');
//Nos autenticamos como administrador. Si todo va bien la conexión esta hecha

Ahora necesitamos saber cómo insertar, modificar y elminar registros en el servidor LDAP.

//Insertar usuario en LDAP
//$user es la variable donde tenemos el nombre de usuario. Tiene que se el mismo que el nombre de usuario de symfony
 
                $info["sn"]= $user;
		$info["uid"]= $user;
		$info["cn"]= $user;
		$info["userPassword"] = "{SHA}". base64_encode(sha1($pass,true));
    	$info["objectclass"][]="person";
    	$info["objectclass"][]="inetOrgPerson";
    	$info["objectclass"][]="top";
    	$info["objectclass"][]="organizationalPerson";
		return ldap_add($ds, "uid=".$user.", ".sfConfig::get('sf_ldap_suffix'), $info);

Vemos que para user password usamos ciertas funciones extra. Eso es porque a mi me gusta cifrar los datos sensibles. Si usas directamente la variable $pass, ésta se guardará en texto plano.

Eliminar el usuario es más sencillo

    ldap_delete($ds, "uid=".$user.", ".sfConfig::get('sf_ldap_suffix'));

Y cambiar la contraseña también es muy fácil

$pass = array("userPassword" => "{SHA}". base64_encode(sha1($pass,true)));
		return ldap_modify ($ds, "uid=".$user.", ".sfConfig::get('sf_ldap_suffix'), $pass);

Si juntamos todo, obtenemos la clase completa

class LdapLogin {
 
	public static function checkPassword($user,$pass){
		$ldapUser = "uid=".$user.",".sfConfig::get('sf_ldap_suffix');		
 
		$ds = ldap_connect(sfConfig::get('sf_ldap_hostname'),10389);
		ldap_set_option($ds, LDAP_OPT_PROTOCOL_VERSION, 3);
		return @ldap_bind($ds, $ldapUser, $pass); //BIND
	}
 
	public static function createUser($user,$pass){
		if(sfConfig::get('sf_ldap_admin') == ""){
			$settings = sfYaml::load(sfConfig::get('sf_root_dir')."/config/settings.yml");
			$admin = $settings['all']['ldap']['admin'];
			$adminPass = $settings['all']['ldap']['password'];
			$host = $settings['all']['ldap']['hostname'];
		}else{
			$admin = sfConfig::get('sf_ldap_admin');
			$adminPass = sfConfig::get('sf_ldap_password');
			$host = sfConfig::get('sf_ldap_hostname');
		}
 
		$ds = ldap_connect($host,10389);
		if(!$ds) throw new Exception('Cant connect to LDAP host "'.$host.'"');
		ldap_set_option($ds, LDAP_OPT_PROTOCOL_VERSION, 3);
 
		if(!ldap_bind($ds, $admin,  $adminPass)) throw new Exception('Cant bind to LDAP host "'.$host.'"');
		$info["sn"]= $user;
		$info["uid"]= $user;
		$info["cn"]= $user;
		$info["userPassword"] = "{SHA}". base64_encode(sha1($pass,true));
    	$info["objectclass"][]="person";
    	$info["objectclass"][]="inetOrgPerson";
    	$info["objectclass"][]="top";
    	$info["objectclass"][]="organizationalPerson";
		return ldap_add($ds, "uid=".$user.", ".sfConfig::get('sf_ldap_suffix'), $info);
	}
 
	public static function removeUser($user){
		if(sfConfig::get('sf_ldap_admin') == ""){
			$settings = sfYaml::load(sfConfig::get('sf_root_dir')."/config/settings.yml");
			$admin = $settings['all']['ldap']['admin'];
			$adminPass = $settings['all']['ldap']['password'];
			$host = $settings['all']['ldap']['hostname'];
		}else{
			$admin = sfConfig::get('sf_ldap_admin');
			$adminPass = sfConfig::get('sf_ldap_password');
			$host = sfConfig::get('sf_ldap_hostname');
		}
 
		$ds = ldap_connect($host,10389);
		if(!$ds) throw new Exception('Cant connect to LDAP host "'.$host.'"');
		ldap_set_option($ds, LDAP_OPT_PROTOCOL_VERSION, 3);
 
		if(!ldap_bind($ds, $admin,  $adminPass)) throw new Exception('Cant bind to LDAP host "'.$host.'"');
		return ldap_delete($ds, "uid=".$user.", ".sfConfig::get('sf_ldap_suffix'));
	}
 
	public static function updatePassword($user,$pass){
		if(sfConfig::get('sf_ldap_admin') == ""){
			$settings = sfYaml::load(sfConfig::get('sf_root_dir')."/config/settings.yml");
			$admin = $settings['all']['ldap']['admin'];
			$adminPass = $settings['all']['ldap']['password'];
			$host = $settings['all']['ldap']['hostname'];
		}else{
			$admin = sfConfig::get('sf_ldap_admin');
			$adminPass = sfConfig::get('sf_ldap_password');
			$host = sfConfig::get('sf_ldap_hostname');
		}
 
		$ds = ldap_connect($host,10389);
		if(!$ds) throw new Exception('Cant connect to LDAP host "'.$host.'"');
		ldap_set_option($ds, LDAP_OPT_PROTOCOL_VERSION, 3);
 
		if(!ldap_bind($ds, $admin,  $adminPass)) throw new Exception('Cant bind to LDAP host "'.$host.'"');
 
		$pass = array("userPassword" => "{SHA}". base64_encode(sha1($pass,true)));
		return ldap_modify ($ds, "uid=".$user.", ".sfConfig::get('sf_ldap_suffix'), $pass);
 
	}
 
}

Desde cualquier parte de symfony podremos usar esta clase.

Para terminar vamos a poner la guinda al pastel. Cuando se cree el usuario en symfony, también haremos que se cree en el sevidor LDAP.

En mi aplicación la creación de un usuario es algo bastante complejo y por ese motivo uso el task create-user de sfGuard. Por supuesto que puedes modificar la clase sfGuardUser para que cuango haga insert o update ejecute el código para insertar el usuario pero yo voy a exponer mi método.

Abrimos el archivo plugins/sfDoctrineGuardPlugin/lib/task/sfGuardCreateUserTask.class.php
En el método execute insertamos justo al principio este código

    if(!LdapLogin::createUser($arguments['username'],$arguments['password']))
        throw new Exception('User already exists in LDAP database');

Creo que estas líneas se explican por sí solas. Intenta crear el usuario en el servidor LDAP. Si ya existe lanza una excepción tirando abajo el proceso de creación del usuario.

Lo ideal es que crees otros task para actualizar y borrar el usuario ya que si te limitas a hacer un delete al user sólo borrarás al usuario de la base de datos de symfony pero no del servidor LDAP. Aunque como dije antes, puedes hacer que las acciones de update y delete de un objeto Doctrine (ORM usado por Symfony) hagan más cosas. Probablemente otro día te diga como hacerlo.

Nos vemos!

Entradas relacionadas:

1. Vistas en Doctrine ORM Saludos! que tal? Espero que bien. Esta vez te voy...

Openfire es un servidor XMPP. El protocolo XMPP es por ejemplo el que usa google para Gtalk. Seguro que con esta información supones para lo que sirve. Sí, Openfire es un servidor de mensajería instántanea libre y que usa un protocolo libre.

De serie openfire trae una herramienta muy potente, que es la consola de administración. Desde ella puedes gestionar absolutamente todo y además de manera visual (se llama consola pero es una interfaz web). Bien, para hacer cosas a mano esta interfaz web está muy bien pero cuando queremos hacer cosas desde una aplicación externa lo más correcto es mediante plugins. También se podría con curl ir navegando por la página pero, creéme, sería una chapuza que no da más que problemas y te lo digo por experiencia Si nuestra aplicación es java, podemos usar directamente el API pero resulta que yo programo las páginas web en PHP. Openfire está hecho en java así que la solución es enviar peticiones al servidor a traves de una conexion http. Un plugin de Openfire recibirá esas peticiones y hará cosas al respecto.

Para comprender fácilmente cómo funcionan estos plugins os pongo mi ejemplo.
En mi página los usuarios pueden hablar entre ellos mediante un chat y un usuario sólo puede hablar con sus amigos. Cuando en la página web dos usuarios se hacen amigos se envía una petición al servidor XMPP para que añada como contactos a los usuarios en sendas cuentas. En mi caso, cuando se hacen amigos se envía una petición del tipo “http://servidor.com:9090/plugins/rosterManager/rostermanager?type=create&username=usuario&jid=amigo@servidor.com&secret=tSLl7i5t”

La petición va al puerto 9090 (es por el que escucha openfire) y el plugin es “rosterManager”. Los parámetros son type, username… esos los he puesto yo porque me ha dado la gana, pueden ser los que tu quieras o necesites. Además el servidor nos responde con los resultados que en mi caso son éxito o no éxito (e indicando el problema) siendo así muy fácil saber si todo ha ido bien.

Después de todo este rollo vamos al tema.

SOFTWARE NECESARIO

• Necesitamos el código fuente de openfire. No es que vayamos a compilar todo openfire, el motivo es que ahí tienen todo preparadito para compilar y empaquetar los plugins. Lo podemos encontrar aquí http://www.igniterealtime.org/downloads/source.jsp
• Ant. Está en los repositorios así que con aptitude lo instalas
• JDK para compilar Java
• Un plugin de ejemplo (para seguir los pasos y tenerlo como base más que nada) http://wixet.googlecode.com/files/rostermanager.tar.gz

Una vez tengas todo esto desempaqueta el código fuente de openfire, entra en el directorio y ejecuta “ant plugins”. Si todo va bien terminará sin errores. Yo tuve un problema y es que el script comprueba tu versión de ant y yo tenía instalada una más nueva. Hay dos opciones, o modificar el script y añadir nuestra version o instalar una versión más vieja. Yo edité el archivo build.xml y por la línea 226 vemos que comprueba las versiones. Añade una línea exactamente igual pero con tu versión. En mi caso metí esta línea

<contains string=”${ant.version}” substring=”1.8″/>

Los plugins compilados y empaquetados se crearán en target/openfire/plugins. El archivo que se genere en este directorio es el que seleccionaremos desde la consola de administración para instalar el plugin. Por último, nuestro código fuente (el que se compilará) lo tenemos en src/plugins.

Si todo ha ido bien ya tenemos todo lo necesario para ponernos picar código.

CREAR EL PLUGIN

Un plugin de openfire está dividido en dos partes:

• Servlet: Es la parte web. Nos sirve para comunicarnos con el plugin tanto directamente (como lo hará nuestra aplicación externa) como dentro de la consola de administración. Sí, crearemos un apartado dentro de la consola para configurar el plugin. Si te fijas en la url que dije antes (http://servidor.com:9090/plugins/rosterManager/rostermanager?type=create&username=usuario&jid=amigo@servidor.com&secret=tSLl7i5t) está el parámetro secret. Esa variable la uso para que sólo quien conozca esa clave pueda mandar órdenes al plugin. Esta clave (así como otras cosas como activar el plugin, direcciones ip admitidas…) se configura desde la sección que crearemos para la consola.
• La otra parte es el programa en sí. El código java que hará las tareas de verdad. Es sin duda la parte más divertida. Ahora que no me oye, diré que el servlet es un coñazo pero es necesario.

La estructura de directorios del plugin es algo así:

En este caso el plugin se llama rostermanager (roster es como se le llama a la lista de contactos). En el raíz (rostermanager) sólo hay archivos de información, el icono del plugin y esas cosas. Luego pongo para descargar un ejemplo de plugin para que lo veas, que tardarás menos en verlo y comprenderlo que en leer (y quizá entender) mi explicación.

En el directorio “web” tenemos todo lo relacionado con lo que se mostrará en la sección de la consola. Es simplemente un jsp (como un php pero de java). Aquí pones las tablas y todas las cosas que quieras que se muestren. No olvides configurar el archivo “WEB-INF/web-custom.xml”. La configuración de ese archivo sirve para indicar a qué plugin manda la información el jsp y cosas así. Si es un plugin sencillo (como el mío) la configuración consiste en cambiar “rostermanager” por el nombre de tu plugin todas las veces que aparezca.

Ahora nos vamos a la carpeta “plugin”. Dentro encontramos el archivo “RosterManagerPlugin.java”. Que bien por fin un archivo java, ya podemos programar!. Si, en este archivo es donde está todo el meollo. Consiste en una clase a la que le añades todos los métodos que quieras. En mi caso se llama “RosterManagerPlugin” y si estás usando mi archivo de configuración de antes, tu clase se llamaría TuClasePlugin. Esta clase implementa las clases Plugin y PropertyEventListener y por este motivo tienes que definir ciertas funciones que son para inicializar el plugin y esas cosas. Sólo me queda por decir que aquí puedes usar el API de openfire (http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/javadoc/index.html). Este api tiene toda tipo de clases para hacer todo lo que quieras con el servidor xmpp.

Por último vamos al directorio rosterManager (que en tu caso será el nombre de tu plugin) dentro del directorio plugin. En él vemos RosterManagerServlet.java que va a ser quien instancie nuestra clase y nos comunique con el exterior. Este archivo recibirá los parametros de las peticiones y las gestionará. En el ejemplo mencionado anteriormente, (http://servidor.com:9090/plugins/rosterManager/rostermanager?type=create&username=usuario&jid=amigo@servidor.com&secret=tSLl7i5t”) a este archivo le llegarán los parámetros type, usuario, jid… y hará lo que tenga que hacer con ellos. Vemos que esta clase tiene un método de inicialización donde obtenemos un objeto que no es más que un objeto de la clase que hemos creado antes.

En mi caso, si el “type” es “create” ejecuto “plugin.createRoster(username,jid);”. El método createRoster(username,jid) está definido en el archivo de antes. Tenemos que pensar que esta clase se ejecutará como una página web. Se hace la petición, se procesan los datos, se muestran y termina. Por este motivo es bueno mostrar datos de lo que ha pasado. En mi caso muestro mensajes en formato json informando de si todo ha ido bien o si ha ocurrido algún problema. Por así decirlo, el metodo doGet sería como el main de una aplicación java normal y el archivo donde creamos la otra clase es una biblioteca.

Y esto es todo. Puede parecer complicado y lioso pero es sencillo. Este tipo de plugin es el básico, una vez cojas práctica puedes liar la madeja todo lo que quieras aunque normalmente los plugin hacen “una cosa y punto”. Recueda que no es bueno hacer “algo” que lo haga todo, sino muchas cosas pequeñas que hagan poco pero que lo hagan bien.

Una plantilla de plugin (que puedes usar y modificar) sería esta http://wixet.googlecode.com/files/rostermanager.tar.gz (la misma que he puesto arriba). Ahora te toca investigar por el API de Openfire para saber cómo usar las clases y todas esas cosas.

Se que este manual no es más que unas pequeñas directrices pero espero que te ayude a asentar una base.

Nos vemos!

Entradas relacionadas:

1. crear USBs con GNU/Linux Los que somos adictos a instalar y probar mil distribuciones...