Como mencionamos anteriormente, Jabberd utiliza una serie de archivos basados en XML para la configuración de cada componente (un archivo por componente) y los servicios que brindan, estos archivos, son auto explicados y de fácil entendimiento haciendo muy intuitiva la comprensión acerca de que se debe modificar para lograr el cambio deseado en el servidor.
A la fecha de hoy Jabberd en su versión 2.0 carece de herramientas administrativas basadas en interfaces gráficas o scripts de administración. (para la versión 2.0 sólo se encontraron frontends php para creación de usuarios , no así su versión previa 1.4, la cual cuenta con scripts de administración más maduros que abarcan más tareas sobre el servidor).
El hecho de que dichos archivos de configuración sean basados en XML y estén especificados y descriptos de una forma muy completa, hace relativamente sencilla la implementación de herramientas administrativas gráficas (probablemente web) por ejemplo basadas en servlets J2EE utilizando parsers de XML como por ejemplo Xerces del proyecto Jakarta o también se puede utilizar PHP o perl (en el caso de este último, actualmente permite el manejo de XML en forma de objetos, lo cual hace la programación y manipulación de los archivos de una manera muy fácil y conveniente).
De la misma forma , dado que el esquema utilizado en la base de Datos es muy sencillo, la implementación de herramientas gráficas para administración de usuarios, manejo de listas de contactos, etc., también se hace relativamente sencilla.
La Herramienta de Registración para Jabber (o JRT por su sigla en Inglés) es una herramienta basada en web para la alta y baja de usuarios en servidores Jabber; así como para la modificación de las claves de acceso de los mismos. Todo lo que se necesita es un web server con soporte para PHP 4.0.1 o posterior y XML Puede obtenerse de jrt.jabberstudio.org. Está licenciado bajo los términos de la licencia GPL.
Bajo la premisa de que “si una persona sabe que sus actividades son públicamente visibles, dicha persona limitará sus actividades a las que el público deba ver”, la auditoría y log de conversaciones son fundamentales dentro de un entorno corporativo para evitar abusos de la tecnología para fines personales, así como también evitar potenciales fugas de información hacia fuera de la empresa o dentro de la misma. Según el estudio presentado en la CSCW mencionado anteriormente, en una implantación de servicio de Mensajería con auditoría y log de conversaciones se encontró que es muy raro que los empleados utilicen este medio para chat sobre cuestiones personales, solo un 13 % de las conversaciones laborales contenían algún asunto personal y un 6.4 % de las conversaciones contenían solo temas personales.
Dentro de los paquetes de Software de logging de conversaciones y auditoría Open/Free para servidores basados en XMPP, el más completo que encontramos fue Bandersnatch
Bandersnatch se conecta al componente router de jabberd2 y captura los paquetes XML que pasan a través del servidor Jabberd y los procesa para luego insertarlos en una base de datos de forma que luego sea sencillo acceder a dichos datos para representarlos de forma estadística, las vistas de los datos se realizan mediante un frontend Web hecho en php. Dicho frontend de acceso web permite acceder públicamente a datos estadísticos de uso del servidor por usuario como ser cantidad de mensajes internos o hacia gateways externos. Para poder visualizar mensajes de usuarios , bandersnatch implementa un usuario administrador que debe acceder mediante autenticación.
Consulta al JID de Bandersnatch
Si se le es enviado un mensaje al JID del componente, este responderá con las estadística de uso del día de el usuario que realizó el pedido. En caso de que el usuario pertenezca a la lista de Administradores definida en Bandersnatch, este enviará información acerca de los 20 usuarios locales y remotos que más han estado utilizando el servicio en el día
Consultas al Frontend
El frontend ofrece información estadística a nivel de servidor y de usuario, registra el total de mensajes locales y remotos por día, total de mensajes hacia gateways externos (por cada gateway) y una lista de usuarios, si se cliquea en uno de los usuarios , se muestran las estadísticas correspondientes a dicho usuario. En caso de que se quiera acceder al registro de conversaciones de un usuario, se debe de ingresar al frontend como Administrador.
La configuración de Bandersnatch consta de un archivo XML para el producto en si y de un archivo php para el frontend. El archivo de configuración es bastante sencillo de entender y contiene varias opciones logrando una flexibilidad bastante buena del componente.
La configuración del componente consta de:
Opciones del servidor :
hostname: nombre del servidor jabber
port : puerto del servidor por el cual se conecta el componente
secret: palabra clave con la cual el componente autentica contra el servidor
connectiontype: tipo de conexión que el componente establecerá con el servidor (por defecto es TCP/IP)
Opciones del componente:
name: es el JID del componente, además este usuario es el que se autentica con el router para proveer el servicio.
MySQL:
server: el nombre del host donde se encuentra el servidor
dbname: el nombre de la Base de Datos que utiliza el componente
user: usuario de la Base de Datos
password: clave del usuario de la Base de Datos
Opciones de debug:
level: nivel de registro de debug en caso de ser necesario
file : archivo de salida de debug
Opciones de logging:
local_server: nombre completo del servidor local , con este valor Bandersnatch discierne acerca de cuales mensajes son remotos y cuales locales y para registrar presencia de los usuarios locales.
local_domains: lista de dominios considerados locales (para poder reflejarlos de ese modo en las estadísticas)
admin_jids: lista de JID los cuales Bandersnatch debe considerarlos como administradores. Normalmente un usuario puede enviar un mensaje a Bandersnatch para ver sus estadísticas del día. Los Administradores pueden recibir información más detallada como por ejemplo un ranking de usuarios y su utilización del chat.
ignore_jids: lista de JID's que Bandersnatch debe ignorar y no registrar información de log y auditoría para ellos.
Privacy: nivel de privacidad (de 0 a 3) implementa la granularidad de lo que se quiere registrar, desde no registrar estadísticas para usuarios remotos o no registrar conversaciones a una registración completa de mensajes y presencia
aggressive_presence: Bandersnatch por defecto solo registra presencia de tipo Offline y Online, para que pueda obtener estadísticas de presencia de forma completa (away, chat, DND) , debe suscribirse en la lista de contactos de un usuario, con presencia agresiva activada, cada vez que un usuario envíe un mensaje, Bandersnatch chequea si esta suscripto en sus contactos, en caso negativo, envía pedido de suscripción.
El producto utiliza MySQL como sistema de Bases de Datos aunque en Internet hemos encontrado que algunas implantaciones se han hecho con PostgreSQL (con modificaciones del código fuente de bandersnatch).
La estructura en la Base de Datos es muy sencilla y solo consiste en 4 tablas :
message
Todos los mensajes son registrados en esta tabla, se registra el texto del mensaje, el timestap del mismo, desde que usuario y hacia que usuario , la misma cuenta con índices sobre estos últimos tres campos.
presence
registra los cambios de presencia de los usuarios
user
Esta tabla mantiene información sobre el estado actual de los usuarios y a cuales están subscritos(para el uso de presencia agresiva)
auth
Esta tabla solo es utilizada por el frontend PHP para determinar que usuarios pueden ingresar al frontend como administradores para poder leer el log de los mensajes.
Los principales problemas encontrados con el producto fueron los siguientes:
Tanto la instalación cono la puesta en marcha del componente no es trivial, la documentación no esta del todo correcta. Los paquetes prerequisitos de Bandersnatch son muchos y todos no están documentados, mediante los errores en la puesta en marcha, se debieron deducir que paquetes prerrequisito faltaban además de los especificados en la documentación.
Se debió modificar el script de generación de la Base de Datos pues no estaba correctamente implementado (ver Apéndice 8.4.2)
Se tuvieron problemas para poder lograr conectar el componente hacia el router ya que la documentación no especifica claramente como hacer este paso y los ejemplos que otorgaba la misma no funcionaron en nuestras implantaciones.
Una vez que se pudo habilitar el servicio, vimos que el componente registraba los mensajes 2 veces en la base de datos, se debieron hacer modificaciones en los fuentes para corregir el problema. Si bien el problema fue corregido en base a una sugerencia que se encontró en la 'mailing list' de Bandersnatch, luego de modificar el fuente, se encontró un upgrade sobre el script de registro en el sitio de Bandersnatch que además arreglaba otro problema similar para los paquetes hacia Gateways de servicios de mensajería externos (ver Apéndices)
El componente a veces no se conecta contra el Router porque da fallo en la autenticación mediante SASL y se debe correr el script de inicio nuevamente.
(Todas las modificaciones y correcciones sobre los fuentes están en el Apéndice 8.4.2)
Si bien se tuvieron bastantes problemas para lograr un correcto comportamiento del componente y existen posibles mejoras al componente como por ejemplo el archivado y depuración automática de la Base de Datos, encontramos que Bandersnatch es capaz de generar un conjunto de estadísticas (útiles para tener una noción sobre la utilización del servicio de Mensajería y de loggeo de conversaciones) adecuado para un ambiente corporativo, se le agrega la facilidad con la cual se pueden acceder a estos datos vía frontend Web.
Si bien se puede suponer que la ventaja única de la multiconferencia dentro de la M.I. empresarial podría ser para discusiones específicas donde se requieran varios integrantes, de todas formas es un requerimiento válido para la empresa disponer de dicho servicio.
Un servicio de multiconferencia podría verse como uno un news board pero en tiempo real y sin datos histórico (se puede implementar datos históricos extrayendo datos de los sistemas de log como el Bandersnatch). Cada usuario podría ingresar (si está autorizado) a distintos chatrooms creados para discutir temas específicos donde se requiere la opinión o desisión de más de dos personas. Las salas de multicinferencia pueden ser públicas o privadas (se acceden con clave).
La especificación de XMPP contempla los mensajes para multiconferencia, pero no especifica en si como debe de implementarse el manejo de las salas multiconferencias (cada servidor lo puede implementar como quiera), sin embargo la comunidad Jabber propone una extensión al XMMP/Jabber de se discute la implementación de un protocolo robusto para conferenciar en base a texto para utilizarse como guía para desarrolladores. Esta extensión es la JEP-0045: Multi-User Chat. (ver apéndice 8.2.1)
Este tipo de componente es uno de los que revisten mayor funcionalidad. Nos permitirá establecer salas de conferencia (salas de chat) las cuales podrán ser tanto públicas como privadas, moderadas o no, etc.
Jbberd2 no dispone nativamente de esta característica, para ello utilizamos el paquete mu-conference. Este componente es uno de los que revisten mayor funcionalidad. Nos permitirá establecer salas de conferencia (salas de chat) las cuales podrán ser tanto públicas como privadas, moderadas o no, etc.
Este componente fue diseñado originalmente para ejecutarse junto a las versiones 1.4x del servidor jabberd. Actualmente puede ejecutarse junto con las versiones 2.0sX del servidor pero necesita unas bibliotecas conocidas como Jabber Component Runtime o JCR para compilarse, hablaremos de esto más adelante.
Según se menciona en el archivo README de la distribución de Mu-Conference actualmente posee las siguientes características
Compatibilidad hacia atrás con Groupchat 1.0
Roles y Afiliación de usuarios
Logging nativo de salas
Configuración dinámica de salas
Salas moderadas
Salas protegidas por clave
Salas no anónimas
Salas exclusivas para miembros
Exclusión de usuarios de las salas en modos Ban y Kick
Salas persistentes reconfigurables
Los requisitos así como los procesos de instalación y configuración se muestran en el apéndice 8.2.2.
En cuanto a la administración, este componente viene con un script PERL que actúa a modo de “wizard” para la creación de salas persistentes, guiando al usuario en la creación de las mismas.
De toda maneras, por experiencia de los integrantes del grupo, la salas persistentes pueden ser generadas manualmente creando los archivos que definen su configuración y el archivo rooms.xml. Esto se traduce en una muy fácil administración ya que scripts o front-end web que faciliten estas tareas pueden ser fácilmente desarrollados.
Los componentes de tipo JUD (Jabber User Directory) proveen de un sistema que permite hallar fácilmente las JID de usuarios los cuales podrán ser buscados por datos personales tales como Nombre, Apellido, eMail, nick, etc. Se detalla en apéndice 8.3 el proceso de instalación de uno de los paquetes que brindan dicho servicio.
Un requerimiento interesante para un servicio de Mensajería Instantánea en una empresa es el de acceso al servicio mediante una interfaz Web. El cliente se puede integrar en la página de la empresa o en un Portal.
Las ventajas más destacables que ofrece un cliente Web son tres :
Incrementa la seguridad en caso de comunicación con Internet ya que no es necesario habilitar los puertos que utiliza Jabber para conexiones desde Internet, todo pasa por los puertos http.
No obliga al usuario a instalar un cliente de XMPP, esto puede ser muy beneficioso y bien visto si la empresa tiene clientes con JID propio en su servicio de Mensajería, la empresa le está brindando servicios de forma personalizada y además no requiere la instalación de ningún paquete extra en el PC del cliente (generalmente los clientes tendrán ya clientes de servicios de mensajería públicos como MS Messenger pero es poco probable que tengan un cliente que soporte el protocolo XMPP)
Web Messenger brinda un cliente Web hecho en PHP completamente funcional exceptuando la transferencia de archivos y las conexiones vía ssh, fue hasta la fecha el más completo y maduro que encontramos, utiliza una base de datos propia (mySQL) para llevar registro de usuarios que utilizan el servicio así como a que Gateways el usuario habilitado vía web. Las desventajas que encontramos son que las conexiones son solo por el puerto no encriptado del servidor, lo que implica un riesgo extra si el servidor HTTP que brinda el servicio no es el mismo que el servidor de Mensajería, y que a Setiembre de 2004 el producto se descontinuó como proyecto Open-Source y paso a ser Comercial.
Si bien la configuración del componente en si mismo es muy sencilla, lo que requiere una dificultad extra es la configuración del entorno donde corre el componente (se requieren conocimientos de administración de servidores HTTP y PHP entre otros). Al testearlo, encontramos que es un producto muy amigable y no requiere de conocimientos extras para ser utilizado por un usuario regular de M.I. acostumbrado a un cliente propio de Mensajería.
Estudio del Open/Free (GNU/Linux) como plataforma de servicios de red en entornos empresariales
Daniel Caraballo - Mario Madera - Marcelo Odin
Tutor: Ariel Sabiguero Yawelak
2004 - 2005.