Actas de las III Jornadas de Software Libre de la ...

ii

ii

ii

ii

Actas de las III Jornadas de Software Librede la Universidad de Cádiz

Manuel Palomo DuarteJ. Rafael Rodríguez Galván

Coordinadores

ii

ii

ii

ii

© 2006 Universidad de CádizOficina de Software Librehttp://softwarelibre.uca.es

© 2006 Servicio de Publicaciones de la Universidad de Cádiz© De cada artículo, sus autores

Edita: Servicio de Publicaciones de la Universidad de CádizC / Doctor Marañón, n◦ 3, 11002 Cádizhttp://www.uca.es/publicacionesISBN10: 84-9828-055-9ISBN13: 978-84-9828-055-5

http://softwarelibre.uca.es

http://www.uca.es/publicaciones

ii

ii

ii

ii

Comité organizador

CoordinadoresManuel Palomo Duarte†

J. Rafael Rodríguez Galván�?

SecretarioGerardo Aburruzaga García†?•

ColaboradoresJosé Manuel Frías Carnero•

Juan Carlos González Cerezo?•

Ignacio Montoya García?

Francisco Palomo Lozano†

Comité científico-técnico

Gerardo Aburruzaga García†?•

Maria del Carmen de Castro Cabrera†

Juan José Domínguez Jiménez†

Antonia Estero Botaro†

Fernando Fernández Palacín‡

Israel Herráiz Tabernero∗

Inmaculada Medina Bulo†

Francisco Palomo Lozano†

Manuel Palomo Duarte†

Carlos Rioja del Río†

J. Rafael Rodríguez Galván�?

Mercedes Ruiz Carreira†

† Departamento de Lenguajes y Sistemas Informáticos, Universidad de Cádiz‡ Departamento de Estadística e Investigación Operativa, Universidad de Cádiz∗ Grupo Libresoft, Universidad Rey Juan Carlos� Departamento de Matemáticas, Universidad de Cádiz? Oficina de Software Libre, Universidad de Cádiz• Área de Informática, Universidad de Cádiz

ii

ii

ii

ii

ii

ii

ii

ii

Índice general

I Ponencias 3

1. Software libre para prácticas en la E.S.I. de Sevilla. Una experiencia educativa 5

2. Navegación web Segura 17

3. Implantación de LDAP como sistema de autenticación centralizada 31

4. MOVICUO: Comunicaciones móviles y software libre para la ubicuidad 45

5. Ruby on Rails y otros entornos MVC de licencia libre: Un análisis práctico 59

6. Implantando GNU/Linux: Una visión desde un Ayuntamiento 71

7. TOMAS3: Towards an Open Management Architecture for Systems, Software and Services 81

II Proyectos fin de carrera 97

8. Intérprete de diagramas de flujo. 99

9. Plataforma libre de desarrollo de algoritmos para el proyecto Pelican 105

III Talleres 111

10.Edición de audio digital con Audacity 113

11.Introducción a la creación y tratamiento de imágenes digitales mediante Gimp 119

12.Creación de presentaciones en DVD con dvd-slideshow 127

Índice de Autores 133

ii

ii

ii

ii

ii

ii

ii

ii

Índice de figuras

1.1. Diseño lógico de bloques de CESIUS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2. Ejemplo de ejecución del traductor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3. Aspecto de la pantalla del depurador de CESIUS. . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1. Estructura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2. Pila de protocolos del enlace PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.3. Activación del contexto PDP con comandos AT+ . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.4. Aspecto inicial de GNOME-GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.5. Aspecto al conectarse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.6. Gráfica resultante para el Caso 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.7. Gráfica resultante para el Caso 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.8. QoS solicitada y Qos minima negociadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.9. Gráfica resultante para el Caso 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.10.Gráfica resultante para el Caso 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.1. Esquema típico de MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.2. Ejemplo de recuperación y modificación de datos con ActiveRecord . . . . . . . . . . . . . . . . . 655.3. Formato de URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.4. Ejemplo de definición de acción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.1. Sistema Gestor de Configuraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877.2. Sistema Gestor de Instalaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

8.1. captura de pantalla del intérprete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1028.2. captura con watch(vigía) de variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

9.1. Arquitectura software de la biblioteca paralela integrada para el cálculo numérico científico. . . . 1079.2. Esquema genérico del funcionamiento del servicio web . . . . . . . . . . . . . . . . . . . . . . . 107

10.1.Audacity trabajando en modo multipistas digital. . . . . . . . . . . . . . . . . . . . . . . . . . . 11510.2.Audio antes y después del tratamiento con Audacity. . . . . . . . . . . . . . . . . . . . . . . . . . 115

11.1.Interfaz gráfica de Gimp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

12.1.Ejemplo de código para mostrar una serie de fotos . . . . . . . . . . . . . . . . . . . . . . . . . . 12912.2.Programa Slideshow Creator en funcionamiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

ii

ii

ii

ii

ii

ii

ii

ii

Prólogo

En los últimos años, las universidades españolas (siendo pionera entre ellas la Universidad deCádiz) están tomando conciencia de la importancia de las estrategias relacionadas con el software yel conocimiento libres como medio hacia los fines últimos recogidos en sus estatutos, racionalizandogastos, subrayando aspectos éticos como el conocimiento, la libertad y la colaboración, fomentandoel uso innovador e independiente de las tecnologías de la información y las comunicaciones para laeducación, investigación y gestión y destacando el papel de la universidad como motor de conoci-miento y tecnología en su entorno.

Conscientes de todo ello, la Oficina de Software Libre de la Universidad de Cádiz, con el res-paldo del Área de Informática y el apoyo del Departamento de Lenguajes y Sistemas Informáticos,ha apostado desde sus orígenes por la celebración de estas jornadas anuales, enfatizando su papeldivulgativo y acercando el mundo de la empresa a la comunidad universitaria.

Manteniendo esta filosofía, ha llegado el momento de dar un salto de calidad. Así, en esta terceraedición de las Jornadas se ha realizado un esfuerzo por enriquecerlas, abriéndolas a la participa-ción mediante la posibilidad de presentar ponencias, talleres o proyectos de fin de carrera que, trasun riguroso proceso de revisión, están recogidos en este libro de actas para su distribución a losasistentes.

La organización de las III Jornadas de Software Libre ha supuesto un importante esfuerzo que nohubiera sido posible sin la colaboración de un nutrido grupo de personas, entre las cuales se encuen-tran los miembros del comité organizador y del comité científico-técnico. En especial, nos gustaríaexpresar nuestra gratitud a Gerardo Aburruzaga García, secretario de las mismas. Sin ninguna duda,nada hubiera sido posible sin ellos. Asimismo, nos gustaría expresar nuestro agradecimiento a los au-tores de los trabajos recogidos en las presentes páginas, a las empresas colaboradoras y, en general,a todas aquellas personas que, desarrollando o apoyando el desarrollo de software y conocimientolibres, han hecho posibles estas jornadas.

Manuel Palomo DuarteDepartamento de Lenguajesy Sistemas Informáticosde la Universidad de Cádiz.

J. Rafael Rodríguez Galván.Departamento de Matemáticas.Director de la Oficina de Software Librede la Universidad de Cádiz.

ii

ii

ii

ii

ii

ii

ii

ii

Parte I

Ponencias

3

ii

ii

ii

ii

ii

ii

ii

ii

1Software libre para prácticas en la E.S.I. de Sevilla. Una

experiencia educativa

José Julio Hernández Fernández [email protected]

Dpto. Ing. de Sistemas y Automática. Universidad de Sevilla.

Manuel Ruiz Arahal [email protected]

Dpto. Ing. de Sistemas y Automática. Universidad de Sevilla.

Resumen

En este artículo se muestra una aplica-ción del software libre en la docencia. Setrata de un conjunto de programas que per-miten a los alumnos de Ingeniería Indus-trial realizar prácticas de programación enun nivel bajo próximo al código binario.

CESIUS es una computadora inexistenteque sirve para ilustrar muchos aspectos delas computadoras reales. El diagrama de lamisma es muy simple y ha sido creado apartir del esquema de Von Neumann parala computadora de programa almacenado.Con ella, los alumnos de la asignatura de

"Fundamentos de Informática" pueden fa-miliarizarse con los conceptos básicos delcódigo binario y ensamblador, programan-do, depurando sus propios programas, y si-guiendo la ejecución de los mismos de unamanera gráfica muy didáctica.

1.1. Introducción

En el plan de estudios de la titulación deIngeniería Industrial de la Universidad deSevilla aprobado en el año 1998 apareceen el primer curso la asignatura de "Funda-mentos de Informática", dotada con 9 cré-ditos del total de los 72 de los que consta el

mailto:[email protected]


ii

ii

ii

ii

6 Universidad de Cádiz

Figura 1.1: Diseño lógico de bloques de CESIUS.

primer curso, dentro de los 390 de la carre-ra completa (primer y segundo ciclo).

El bajo número de créditos es una res-tricción muy importante, que obligó en sumomento a realizar un plan docente parala asignatura con un delicado equilibrio. Seoptó por proporcionar una visión lo másamplia posible, abarcando aspectos de bajonivel [1] [2], de algoritmia [3] y de progra-mación [4]. A fin de poder profundizar másen los aspectos considerados más importan-tes ha sido preciso sacrificar la presentaciónde otros. En particular en la programacióndel curso se dedica muy poco tiempo a lasdescripciones de equipos [5] y de los sis-temas [6] pues son conocimientos que seadquieren hoy en día antes de llegar a launiversidad con el uso de equipos domésti-cos o en centros de enseñanza.

La herramienta que se muestra en el pre-sente trabajo es utilizada en la realizaciónde prácticas de laboratorio durante el pri-mer cuatrimestre, el cual se dedica a pre-sentar el funcionamiento básico de la com-putadora digital.

La computadora CESIUS no existe comoun conjunto de circuitos: es una computa-dora virtual, basada como se ha comentadoanteriormente en el modelo de Von Neu-mann. Se puede ver su diseño en la figu-ra 1.1. Existen, en cambio, un conjunto deprogramas capaces de simular el funciona-miento de una computadora CESIUS. Estehecho, en lugar de representar una desven-taja, proporciona la oportunidad de que lamáquina sea usada por cualquier personaen cualquier parte del mundo, sin más con-dición que el disponer de una computadora

http://www.uca.es

ii

ii

ii

ii

III Jornadas del Software Libre 7

tipo PC o de cualquier otro tipo con míni-mos requisitos.

1.2. Visión general

La computadora CESIUS consta de los si-guientes bloques lógicos:

UAL: unidad aritmético-lógica

UC: unidad de control

UM: unidad de memoria

UES: unidad de entrada-salida

y de los siguientes registros:

A: acumulador, 16 celdas

P: contador de pasos del programa,11 celdas

I: registro de instrucción, 16 celdas

S: selector de memoria, 11 celdas

T: tampón de memoria, 16 celdas

E: tampón de entrada-salida. 16 cel-das

El funcionamiento de la máquina quedaperfectamente definido conociendo el jue-go de instrucciones, consistente en las 16operaciones básicas que se indican a conti-nuación:

ALT: Parar

ALM: Almacenar

CAR: Cargar

ESC: Escribir Número

ECA: Escribir Carácter

LEE: Leer Número

LCA: Leer Carácter

SUM: Sumar

RES: Restar

MUL: Multiplicar

DIV: Dividir

MOD: Módulo

SAL: Salto

SAN: Salto si A es negativo

SAC: Salto si A es cero

SAP: Salto si A es positivo

La computadora es capaz de realizaroperaciones directas e indirectas. En el mo-do directo, el operando de la instrucciónes interpretado como la dirección sobre laque se ha de trabajar. En el modo indirectoel operando es tomado como la direcciónque contiene la dirección sobre la que se hade trabajar. La computadora puede progra-marse por medio de un lenguaje ensambla-dor de dos pasos llamado LS-2. Las senten-cias en LS-2 constan de: etiqueta (separa-da por dos puntos), mnemónico de instruc-ción, indicador de modo (letra I) y operan-do. Por ejemplo:

X: ESP 1CAR X

M: LEE I PUN

http://osl.uca.es

ii

ii

ii

ii


Las pseudoinstrucciones son órdenes pa-ra el traductor que facilitan la programa-ción. Éstas son:

ORG: Instrucción (opcional) que in-dica el punto inicial de carga en me-moria del programa.

ESP: Permite dejar espacios vacíosentre instrucciones

CTE: Para definir constantes

DRE: Deja un espacio con el valor re-presentado por la etiqueta

FIN: Indica el fin del programa

El simulador de CESIUS se ha divididoen varios programas con objeto de facilitarsu uso. Cada programa se ocupa de una ta-rea concreta, de forma que entre todos sesatisfagan las necesidades que se plantean.

A continuación se proporciona una brevedescripción de cada uno de los programas.En apartados posteriores se explicará deta-lladamente la forma de uso de cada uno.

Traductor: es un ensamblador de dospasos que produce archivos ejecutables apartir de archivos que contienen el progra-ma en lenguaje simbólico LS2.

Ejecutor: permite simular la ejecuciónde un programa, previamente traducido enCESIUS. Los resultados obtenidos en pan-talla son los que produciría dicha computa-dora si existiese realmente.

Depurador: permite ejecutar los progra-mas instrucción a instrucción, mostrando almismo tiempo el contenido de los registrosy la memoria de CESIUS. De este modo esposible buscar errores de programación.

Los programas están pensados para serusados en entornos no gráficos, esto es, en

línea de órdenes. La salida en pantalla con-siste en texto únicamente. Esta caracterís-tica los convierte en fácilmente transporta-bles.

1.3. El traductor

El traductor es un programa que crea ar-chivos ejecutables de CESIUS a partir de ar-chivos que contienen un programa en LS2.Para ello realiza las mismas operacionesque un ensamblador de dos pasos.

El archivo que contiene el programa enLS2 recibe el nombre de archivo fuente. Elarchivo que contiene el programa traducidoes llamado ejecutable de CESIUS y abrevia-damente archivo ECE. Este archivo ejecuta-ble es posteriormente usado por el ejecutoro por el depurador, que simulan el compor-tamiento de CESIUS.

Para el correcto funcionamiento del tra-ductor es preciso que el archivo fuentecumpla ciertos requisitos que se comentana continuación.

1.3.1. Escritura del fuente

El archivo fuente puede crearse con cual-quier programa de redacción de textos, ob-servando las normas siguientes:

La pseudoinstrucción ORG ha deaparecer en primer lugar o no apa-recer en absoluto.

Las etiquetas se definen situándolasa la izquierda de la sentencia, sepa-radas de los códigos por dos puntos.

Los operandos han de estar separa-dos por espacios o tabulaciones delresto.

http://www.uca.es

ii

ii

ii

ii


El indicador de direccionamiento in-directo ha de estar separado por es-pacios del resto de códigos.

Se pueden introducir comentariosdespués del operando, separados deéste por el signo de apóstrofe.

Ha de existir una pseudoinstrucciónFIN.

Toda etiqueta usada ha de estar defi-nida.

Como se ve, las restricciones son muysuaves, lo cual permite cierta despreocupa-ción a la hora de escribir el código. En elcuadro 1.1 se muestra un programa correc-tamente escrito. Las etiquetas aparecen ali-neadas por comodidad para el lector, peroesto no es necesario.

Se observa que el programa calcula lamedia de dos números que se leen de te-clado. Este ejemplo servirá para ilustrar elmanejo de cada una de las partes del simu-lador de CESIUS, comenzando por el usodel traductor que se comenta a continua-ción.

1.3.2. Modo de uso

Para usar el programa traductor es pre-ciso iniciar una sesión en línea de órdenes,y escribir traducir y a continuación elnombre del archivo fuente.

Es preciso indicar el nombre completodel archivo fuente, incluyendo la exten-sión. Si no se proporciona esta informa-ción el programa pregunta por pantalla di-cho nombre. Si el archivo proporcionadono existe en el directorio actual aparece unmensaje de error.

Si la traducción se realiza sin fallos elprograma traductor muestra en pantallacierta información relativa al programa quese está traduciendo incluyendo la lista deetiquetas y del valor representado. Esta in-formación ayuda a determinar si el progra-ma ha sido correctamente traducido.

1.3.3. Mensajes de error

En la escritura del código fuente puedendeslizarse errores que causarán un mal fun-cionamiento del traductor. El programa tra-ductor detecta los siguientes errores:

Código no reconocido. Aparece cuandose escribe mal una instrucción opseudoinstrucción, como por ejem-plo, escribir SUN en lugar de SUM.También puede deberse a que se ol-viden los dos puntos que separan laetiqueta de la operación.

Etiqueta no definida.

Operando fuera de rango. Se ha utiliza-do un número que CESIUS no pue-de utilizar debido a las limitacionesimpuestas por la memoria y el anchode palabra. También puede deberseel error a utilizar un número negati-vo con ORG o ESP.

Operando no numérico incorrecto. Seha utilizado una etiqueta como ope-rando de ORG, ESP, CTE en lugar deun número.

Falta operando. Indica que se ha olvidadoconsignar el operando en la senten-cia.

No hallado FIN.

http://osl.uca.es

ii

ii

ii

ii


ORG 0SAL INI ’inicio instrucciones

A: ESP 1 ’sumandoB: ESP 1 ’otro sumando

MEDIA: ESP 1 ’mediaDOS: CTE 2 ’constante

INI: LEE A ’lecturasLEE BCAR ASUM B ’operacionesDIV DOSALM MEDIAESC MEDIA ’escritura resultadoALTFIN

Cuadro 1.1: Ejemplo de programa en LS-2.

ORG fuera de sitio. Esta pseudoins-trucción ha de ser la primera en apa-recer o no aparecer en absoluto.

1.3.4. Archivos ECE

El resultado de la traducción es un ar-chivo ejecutable de CESIUS (ECE). Es im-prescindible conocer que este archivo sólopuede ejecutarse a través del simulador deCESIUS, es decir, no es un archivo ejecuta-ble del sistema operativo anfitrión sobre elque se realiza la simulación.

El archivo ECE contiene el programa taly como debe colocarse en la memoria deCESIUS para su ejecución. El archivo es bi-nario, por lo que no es posible interpretarsu contenido a menos que se sepa la formaen que ha sido construido. Esto significa enparticular que no es posible utilizar un edi-tor de textos para modificarlo.

El tamaño del archivo ECE depende de lacantidad de memoria que use el programa

que se ha traducido, siendo el máximo 8.1kilocaracteres.

El programa traductor produce siempreel archivo prog.ece. Si se desea se puederenombrar este archivo, para de este modopoder tener en el mismo directorio variosejecutables de CESIUS.

1.3.5. Ejemplo de uso

Supongamos que el programa del cuadro1.1 ha sido escrito y almacenado en el ar-chivo media.ls2. En la figura 1.2 se mues-tra el resultado de la ejecución de la ordentraducir .

Además, debe aparecer el archivoprog.ece en el directorio de trabajo.

El archivo traducir ha de estar coloca-do en el directorio de trabajo o en algunode los directorios donde el sistema operati-vo busca los programas ejecutables. En casocontrario se producirá un mensaje de error.

http://www.uca.es

ii

ii

ii

ii


Figura 1.2: Ejemplo de ejecución del traductor.

1.4. El ejecutor

El ejecutor es el programa encargado desimular la ejecución de un programa de CE-SIUS, proporcionando los mismos resulta-dos que se obtendrían si se tuviese la má-quina construida realmente.

El ejecutor toma el programa CESIUS delarchivo ECE y realiza las transferencias ele-mentales entre registros correspondientes acada instrucción. De este modo obtiene losresultados a partir de los datos suministra-dos.

Los registros de la UCP son variables in-ternas del programa ejecutor que el usuariono puede conocer. El programa CESIUS seejecuta de forma oculta al usuario, el cualsolo puede introducir por teclado los valo-res correspondientes a las operaciones delectura que el programa realice. La pantallamuestra los valores que el programa escri-

be.

1.4.1. Modo de uso

Para ejecutar un programa CESIUS conel simulador basta con escribir

ejecutar prog.ece

El archivo ejecutar es el programa simu-lador, y debe estar colocado en el directo-rio de trabajo o en alguno de los directo-rios donde el sistema operativo busca losprogramas ejecutables. En caso contrario seproducirá un mensaje de error.

Para ejecutar un programa CESIUS in-cluido en un archivo con otro nombre, co-mo por ejemplo, otro.ece, se escribe

ejecutar otro.ece

http://osl.uca.es

ii

ii

ii

ii



Se pueden presentar errores durante laejecución del programa. Una causa de ellospuede ser el intentar acceder a una zonade memoria de CESIUS que no está en loslímites de la memoria reservada por el pro-grama.

A continuación se muestra la lista demensajes de error que el programa ejecu-tor reconoce:

Desbordamiento en la UAL. Ocurrecuando el resultado de una opera-ción es un número que no puede seralmacenado en el acumulador.

Acceso a memoria fuera de rango. Se haintentado leer o escribir en la memo-ria en una zona no reservada por elprograma.

Instrucción no válida. El contenido delregistro I no es una instrucción. Es-ta situación puede ocurrir cuando elregistro P invade la zona de datos osi se ha escrito un dato sobre una ins-trucción.

Salto no permitido. Se ha intentado reali-zar un salto a una dirección fuera delrango reservado por el programa; esdecir, P ha tomado un valor fuera dedicho rango.

1.4.3. Ejemplo de uso

Continuando con el ejemplo del aparta-do anterior (véase el cuadro 1.1) la ejecu-ción se pone en marcha mediante

ejecutar prog.ece

Se muestra en pantalla el mensaje

introduzca dato:

como consecuencia de haber ejecutado unainstrucción de lectura de CESIUS, corres-pondiente a la sentencia LEE A del códigofuente. Es preciso introducir por teclado unvalor numérico y presionar la tecla Intro.De la misma manera se procede para el da-to B, debiendo el usuario proporcionar unnúmero.

Finalmente aparece en pantalla el re-sultado de una operación de escritura deCESIUS

escritura : 18

y la indicación de que el programa CESIUSha llegado a su final

Fin del programa CESIUS

1.5. El depurador

El programa depurador permite ejecu-tar los programas de CESIUS instrucción ainstrucción, mostrando al mismo tiempo elcontenido de los registros y la memoria deCESIUS. La utilidad del depurador es do-ble: por una parte sirve para buscar erroresen el programa, y por otra ayuda a com-prender el funcionamiento de CESIUS.

El depurador es un programa parecidoal ejecutor, que se ha comentado anterior-mente. Ambos se basan en la misma idea:realizar las transferencias elementales en-tre registros correspondientes a cada ins-trucción del programa CESIUS. El depura-dor, además, permite observar el contenidode tales registros. También incorpora otras

http://www.uca.es

ii

ii

ii

ii


Figura 1.3: Aspecto de la pantalla del depurador de CESIUS.

funciones, como la posibilidad de abortar laejecución o de inspeccionar la memoria deCESIUS.

1.5.1. Información en pantalla

La pantalla del depurador se divide envarias zonas como muestra la figura 1.3. Enla superior se muestran los registros A, I, P,S, T y E y la pantalla de CESIUS. A la de-recha se muestra la memoria en dos partes.Finalmente, en la zona inferior se muestranmensajes del depurador y se piden las op-ciones al usuario.

La pantalla cambia de estado cada vezque se realiza una operación del depura-dor. En particular, cada vez que se ejecutauna instrucción de CESIUS se ha de refres-car el contenido de los registros, la pantallade CESIUS y la memoria. Es preciso teneren cuenta que la actualización de la panta-lla se realiza justo al terminar la ejecuciónde una instrucción, por lo que el registroP apunta a la instrucción siguiente, aunque

ésta no ha sido leída aún de memoria.

La zona de memoria está dividida en dospartes. En la primera de ellas se muestranlos registros que están próximos al apunta-do por P, es decir, la zona cercana a la ins-trucción que se está ejecutando.

La parte inferior muestra la memoriapróxima a un valor seleccionado por elusuario llamado objetivo del visor de me-moria. Cambiando este valor es posible re-correr la memoria entera para su inspec-ción. La posición del objetivo del visor seseñala con un signo >. Las direcciones dememoria se indican en decimal comenzan-do la numeración desde cero de arriba aabajo.

La información contenida en los regis-tros se muestra en forma de números de-cimales para facilitar la observación. Si setrata de una instrucción se muestra el códi-go mnemónico correspondiente.

http://osl.uca.es

ii

ii

ii

ii


1.5.2. Opciones

El depurador funciona interactivamen-te, esto es, solicita a cada paso una op-ción al usuario, realiza la operación corres-pondiente y vuelve a pedir indicaciones alusuario.

Las operaciones que el depurador es ca-paz de realizar son las siguientes:

E. Ejecutar siguiente instrucción

S. Salir del depurador

N. Comenzar de nuevo la ejecución delprograma CESIUS, sin terminar la ac-tual

O. Cambiar objetivo del visor de memoria

B. Cambiar base de representación de bi-nario a decimal y viceversa


Pueden aparecer errores durante la eje-cución del programa ECE, los mensajes deerror que se generan son los mismos queproporciona el ejecutor y que han sido co-mentados anteriormente.

1.6. Acceso al simulador

Los programas necesarios para ejecutarel simulador pueden obtenerse a travésde la red Internet. Los autores (ManuelRuiz Arahal, José Julio Hernández Fernán-dez y Daniel Limón Marruedo) autorizan eluso del programa bajo los términos de laGNU/GPL2.

El manual para el uso del simulador tam-bién está disponible en Internet y puede serreimpreso con fines no comerciales, citando

siempre la fuente de donde ha sido obteni-do.

Existe una página de Internet que contie-ne información actualizada sobre CESIUS yel simulador, cuya dirección es:

http://www.esi2.us.es/∼arahal/CESIUS/cesius.html

1.7. Conclusiones

La programación de una herramientaeducativa como CESIUS en un lenguaje es-tándar como C nos ha permitido disponerde una aplicación fácilmente transportable,ejecutable en entornos muy variados, y sinmás requisitos mínimos que la existenciade un compilador de C. Al haber sido idea-da para su ejecución sobre software libre yen línea de órdenes nos ha permitido unagran flexibilidad en su despliegue a la horade ponerla a disposición de los alumnos, yaque con un simple telnet o SSH a los ser-vidores del Centro de Cálculo disponen detodos los elementos necesarios para reali-zar sus prácticas. El nivel de aceptación dela aplicación por parte de los alumnos queen los últimos años han sido usuarios dela misma nos hace apostar por este tipo dedesarrollos para futuros proyectos educati-vos, y nos permite simultáneamente servir-les a muchos de ellos como primera tomade contacto con el software libre.

http://www.uca.es

ii

ii

ii

ii

Bibliografía

[1] Fernández, G. y Sáez Vacas, F. Funda-mentos de los ordenadores. E.T.S.I. deTelecomunicación, Madrid, 1985.

[2] de Miguel Anasagasti, P. Fundamentosde los computadores. Paraninfo, Ma-

drid, 1990.

[3] Brassard, G. y Bratley, P. Fundamentosde algoritmia. Prentice Hall, 1997.

[4] Prieto, A., Lloris, A. y Torres, J.C. In-troducción a la informática. McGraw-Hill, Madrid, 1995.

[5] Beekman, G. Computación e informá-tica hoy. Addison-Wesley Iberoameri-cana, Wilmington, Delaware, 1995.

[6] Fernández, G. Conceptos básicos de ar-quitectura y sistemas operativos. Cursode ordenadores. Sistemas y serviciosde comunicación, Madrid, 1994.

ii

ii

ii

ii


http://www.uca.es

ii

ii

ii

ii

2Navegación web Segura

Free Security Suite. Una solución basada en software libre1

José Brieba Sánchez [email protected]

Departamento de Informática. Universidad de Extremadura.

Montaña Castuera Toro [email protected]


José Luis Gonzalez Sánchez [email protected]


Palabras Clave: Software Libre, Códigode fuente abierta, Seguridad, Privacidad,Suites.

Resumen

La situación actual de inseguridad en la na-vegación por Red lleva a que los usuariosinexpertos sean blanco perfecto para todotipo de engaños y ataques. FSS proporciona

a los usuarios las herramientas que les per-miten llegar a niveles de seguridad acepta-bles sin tener que invertir grandes cantida-des en soluciones propietarias. El hecho decontar con un desarrollo basado en softwa-re libre hace que sea una solución flexible,renovable y fiable para la comunidad.

1Este proyecto ha sido patrocinado en parte por la Junta de Extremadura (Expediente 2PR03A09)http://gitaca.unex.es/agila




ii

ii

ii

ii


2.1. Antecedentes

En el mundo en que vivimos las comu-nicaciones se están globalizando e Internetha dejado de ser coto privado de expertosinformáticos entrando en el Medio miles,millones, de usuarios inexpertos. El perfildel usuario medio, hoy por hoy, no tienenada que ver con el de hace unos años.En ese tiempo, las conexiones eran másrestringidas y conectarse a la red requeríaunos conocimientos avanzados de los ser-vicios que se fueran a utilizar tales comogopher, ftp, finger, etc. En los últimos añosse han ido perfeccionando los sistemas denavegación web, permitiendo integrar di-ferentes servicios en los mismos programasy haciendo su uso accesible al público engeneral.

La popularización de las conexiones debanda ancha en los hogares ha propiciadoun claro salto cuantitativo de los usuariosque se conectan a la Red. Sin embargo, nose ha producido una concienciación de losusuarios en términos de seguridad, paraenfrentarse a un medio “hostil” como es laRed. El número de usuarios que se han in-corporado al Medio en los últimos tiemposy no sabe a lo que se enfrenta es realmen-te alto. Los profesionales de la informáticadebemos ser capaces de concienciarles dela necesidad de usar una serie de técnicasque les permitan conectarse y navegar porla Red con unos niveles de seguridad altos.

Todos los días aparecen nuevos proble-mas en la Red: virus, phishing, protecciónde menores, acceso ilegítimo a sistemas...Aplicando unas mínimas medidas de se-guridad podrían paliarse muchos de estos

problemas. Protegerse es responsabilidaddel usuario; si él no lo hace difícilmente lopodremos hacer nosotros.

Generalmente, las soluciones integralesde seguridad para la navegación por la Redson propietarias. Este hecho en sí no las ha-ce malas pero les hace estar en desventajafrente a las que están desarrolladas de ma-nera “libre”. Además, están enfocadas a unsector del mercado (el que consume siste-mas operativos propietarios) dejando a unlado a todos los usuarios “libres” del mun-do.

2.2. Incidencias de seguridad en la na-vegación web

El objetivo principal de FSS es que unusuario inexperto pueda controlar, de ma-nera fácil, un sistema de navegación websegura. De esta forma, se proporciona alusuario los instrumentos necesarios paraobtener un sistema “seguro” de una formalibre y, en este caso, gratuita.

La Web esta viva. Cada día surgen nue-vos problemas susceptibles de ser explota-dos por usuarios especialmente “hábiles”en su propio beneficio. Por lo tanto, lossistemas de seguridad deben evolucionarajustándose a la realidad cambiante de laRed. Si la inseguridad crece, nuestras pre-cauciones deben crecer con ella.

En esta sección veremos las diferentes in-cidencias de seguridad más comunes y pos-teriormente veremos qué soluciones propo-ne FSS para cada una ellas. La ISO [2], enla norma 7498, define la seguridad infor-mática como:

http://www.uca.es

ii

ii

ii

ii


«Una serie de mecanismos queminimizan la vulnerabilidad debienes y recursos, donde un biense define como algo de valor y lavulnerabilidad se define como ladebilidad que se puede explotarpara violar un sistema o la in-formación que contiene.»

En España la seguridad informática es-tá legislada a través del Real decreto-Ley14/1999 (17/Sept) [3], por la Orden mi-nisterial 21/Feb/2000 que aprueba el Re-glamento de acreditación de prestadoresde servicios de certificación y algunos pro-ductos de firma, y, además, por otras leyescomo son las del DNI electrónico o la Leyde firma electrónica.

Centrándonos en la suite que nos ocu-pa, veremos cómo FSS va a permitir a unusuario inexperto, siguiendo una serie depautas o pasos, disfrutar de una navega-ción web segura.

En concreto, FSS está desarrollada parausuarios de sistemas operativos basados enGNU/Linux pero los problemas que paliason comunes a otras plataformas.

En los últimos años han proliferado losproblemas relacionados de alguna maneracon la Red. Es el caso de los virus, los cam-bios de tarificación, defensa de los menoresfrente a los contenidos de la web, phishing,spam, uso indebido de contraseñas... Paracada uno de estos problemas existen solu-ciones particulares.

Un dialer es un programa capaz de ha-cer que el sistema se conecte a la Red a tra-

vés de números de tarificación adicional.Estos programas se usan como medio depago en algunos tipos de páginas y su usono es ilegal mientras no se haga de mane-ra “oculta”. Permite a los usuarios efectuarsuscripciones a estas páginas sin necesidadde rellenar complejos formularios ni darnúmeros de tarjeta, de manera que las em-presas propietarias obtienen beneficios porel cobro de las llamadas telefónicas.

Hace unos años, muchos usuarios es-pañoles se enfrentaron a grandes facturastelefónicas por cambios no autorizados enla tarificación de sus conexiones. Hoy porhoy no existen estos problemas debido a lapopularización de las conexiones ADSL y ala modificación de la legislación que regulalos números de tarificación adicional.

El correo electrónico es uno de los ser-vicios más populares vinculados a Internet;en muchos casos incluso reemplazando alcorreo tradicional. El gran problema de esteservicio es que los usuarios creen que, “pordefecto”, sus comunicaciones son privadase inviolables. Sin embargo, los mensajes decorreo electrónico pueden ser intercepta-dos, leídos, cambiados, copiados... y todoellos sin que el usuario emisor ni el desti-natario lo noten.

Lo que evaluamos no es el hecho de quemandemos o no informaciones importan-tes por medio de nuestro correo, sino si seatenta contra nuestro derecho a la intimi-dad en las comunicaciones privadas. Si notomamos las precauciones pertinentes, elderecho a la privacidad en las comunica-ciones es perfectamente violable. Es igualde grave que se haga con datos poco o muy

http://osl.uca.es

ii

ii

ii

ii


importantes, en cuyo caso podría derivaren muchos más problemas.

El abuso de correo electrónico puede de-finirse como las distintas actividades queperjudican a los servicios habituales de losservidores de correo. Podemos encontrarmuchos tipo de abusos: spamming,mailbombing, unsolicited bulk email (UBE), un-solicited comercial email(UCE), junk mail...Para evitar este tipo de problemas existenherramientas de cifrado, remailers, etc.

Otra problemática importante es la quenos plantea el control de los contenidos nodeseados. Los filtros de contenido son ele-mentos que pueden servir, como su propionombre indica, de filtro para que algunoscontenidos, de la naturaleza que sea, nosean accesibles durante la navegación porla Red. De esta manera, podríamos contro-lar los contenidos potencialmente peligro-sos, ya sea desde la perspectiva de la deseguridad informática o desde el punto devista moral.

Los virus y los troyanos son males quehan encontrado en la Red un caldo de culti-vo perfecto. La forma de trabajo del Medioy la gran cantidad de sistemas inseguroshan hecho que éstos proliferen de una ma-nera asombrosa en los últimos años. Pode-mos encontrar backdoors, troyanos, virus,gusanos... y todos ellos evolucionando rá-pidamente. Por lo tanto, es totalmente re-comendable que usemos sistemas antivirusque sean capaces de responder a este siste-ma cambiante con la misma rapidez.

Todo sistema seguro debe ser capaz degestionar y tener un control de accesos

al sistema. Los programas de Firewall sonlos encargados de proteger nuestro siste-ma de entradas ilegítimas ya sean humanaso automáticas (troyanos). Son difíciles deconfigurar adecuadamente, pues el usua-rio debe tener ciertos conocimientos de losservicios que necesita usar, puertos a uti-lizar, controles de acceso... Por lo tanto, siun usuario configura un firewall de mane-ra incorrecta puede tener problemas con elfuncionamiento de muchas de sus aplica-ciones.

Las contraseñas son uno de los pilaresfundamentales de cualquier sistema segu-ro. Teniendo una serie de precauciones enla creación se pueden solucionar bastantesproblemas. La autenticación de usuarios esuna de las bases de los sistemas seguros.Normalmente se basa en mecanismos quepermiten identificar al usuario de una ma-nera única y, habitualmente, hacen uso decontraseñas para la identificación.

El acceso a la Web es ahora más sencilloque hace unos años. En la actualidad, losnavegadores son sencillos de usar y permi-ten que los usuarios controlen muchos ser-vicios de una manera integrada y transpa-rente. Como el instrumento habitual de na-vegación por la Red son los navegadores, elámbito de trabajo en el que se mueve FSSes, precisamente, uno de los navegadoresque existen en el mercado.

2.3. FSS a fondo

FSS es un proyecto que desarrolla to-talmente desde el grupo de investigacióndel proyecto AGILA (Acceso Generaliza-do a Internet desde LinEx Avanzado [1]),

http://www.uca.es

ii

ii

ii

ii


de la Universidad de Extremadura. AGILAes un proyecto de investigación englobadodentro del II PLAN REGIONAL DE INVES-TIGACIÓN, DESARROLLO TECNOLÓGICO EINNOVACIÓN DE EXTREMADURA y ha sidofinanciado, en parte, por la Consejería deEducación, Ciencia y Tecnología de la Jun-ta de Extremadura (Expediente 2PR03A09).

FSS integra soluciones específicas paracada una de las problemáticas planteadasanteriormente. Podría haberse hecho unsistema más completo, pero los mecanis-mos que se han incluido en FSS son sufi-cientes para asegurar unos niveles de se-guridad altos para una navegación “segura”por la Red.

2.3.1. Anti-Dialers

La proliferación en España de las cone-xiones ADSL ha hecho que las conexionesvía módem telefónico vayan desaparecien-do paulatinamente. Aun así, existen mu-chas regiones en las que la conexión víamódem telefónico es la única opción po-sible y, por lo tanto, los usuarios de estaszonas están expuestos al fraude de los cam-bios de tarificación.

FSS integra un programa que controla laposible modificación de archivos, véase Fi-gura 1, que puedan afectar a las conexionesde red. De este modo, si algún programaintentara cambiar estas configuraciones, elanti-dialer registrará esta situación y permi-tirá al usuario reaccionar de manera efecti-va contra este tipo de ataque, restaurandolas configuraciones originales directamen-te.

Figura 1. Pantalla Dialers

2.3.2. Cifrado

Las herramientas de cifrado permitenque un usuario pueda ocultar cierta infor-mación a ojos indiscretos, de manera quesólo el destinatario, mediante los mecanis-mos de descifrado adecuados, sea capaz deobtenerla de manera clara.

El ambiente perfecto de uso de este ti-po de herramientas es el relacionado conlas comunicaciones privadas. FSS lo aplicaa las comunicaciones de correo electróni-co. La herramienta facilitada permite cifrarlos mensajes, de tal manera que podemosgarantizar que, si un mensaje es intercepta-do, será muy difícil, sino imposible, obtenerel contenido de éste. Incluso se podría con-trolar si un mensaje ha sido interceptado,cambiado y reenviado.

http://osl.uca.es

ii

ii

ii

ii


Figura 2. Pantalla de cifrado

FSS ha incluido la herramienta GPA; quees una herramienta de encriptación quepermite a un usuario gestionar, de una ma-nera sencilla, las prestaciones avanzadasque ofrece GNUpg. Esta herramienta secomplementa con el uso de remailers, quegarantizan el anonimato del remitente encaso de que el correo sea interceptado du-rante su envío.

El uso de remailers en combinación conlas herramientas de cifrado nos permitirá,de una manera eficiente, ocultar nuestraidentidad como remitentes de un mensaje,además de la ocultación del contenido delmensaje con el cifrado.

FSS nos permite enviar un mensaje (véa-se Figura 2), cifrado o sin cifrar, a uno delos remailers que tenga establecido en lalista de remailers disponibles, utilizando elcliente de correo que tengamos marcado enla opción de clientes de correo.

2.3.3. AntiSpam

Paralelamente al correo electrónico, sehan desarrollado algunos fenómenos pro-blemáticos. Clara muestra de ello es elSPAM. Muchos usuarios experimentan adiario este problema; reciben correos nodeseados de direcciones que desconocen.Este hecho, en grandes cantidades, afectaal correcto control del correo electrónico ypuede realmente desesperar a un usuarioque se ve desbordado por cientos de co-rreos no deseados.

Figura 3. Pantalla Antivirus y filtrado

FSS nos da la posibilidad de elegir en-tre dos clientes de correo electrónico libre:Sylpheed y Thunderbird. (Véase Figura3)

Ambos clientes tienen herramientas quenos permitirán un filtrado de correo elec-trónico, paliando así los efectos del SPAM.ThunderBird es quizás una solución algomás segura al usar un filtro bayesiano queayuda a gestionar los correos separando lo

http://www.uca.es

ii

ii

ii

ii


que consideraremos correo deseado del nodeseado.

Las dos opciones están basadas en soft-ware libre y se distribuyen bajo las condi-ciones de la licencia GPL. Ambas poseenun entorno gráfico intuitivo y son fáciles deusar e instalar para usuarios no avanzados.

2.3.4. Filtrado de contenido

Mediante los filtros de contenido pode-mos conseguir que un usuario no tenga ac-ceso a páginas que tengan una temática queconsideremos nociva. Por lo tanto el usua-rio puede funcionar como censor cortandoel acceso a páginas de tono sexual, de apo-logía del terrorismo...

Figura 4. Pantalla Antivirus y filtrado.Filtrado

FSS ha optado por usar Dansguardian;que es una herramienta habitualmente usa-da en servidores, pero que puede ser usadaen un pc normal sin problemas. Lo que ha-ce es analizar las páginas y permitir o noel acceso a sus contenidos. FSS sólo gestio-na la puesta en marcha, parada y reiniciode Dansguardian a través de una interfazpropia de FSS, siendo la configuración del

filtro independiente.(Véase Figura 4)

Para su uso doméstico, Dansguardian sedistribuye bajo licencia GPL sin embargo, sise quisiera usar de manera comercial seríanecesario contactar con el desarrollador.

2.3.5. Antivirus

En la actualidad la Red esta totalmenteinundada de virus. Un sistema que no estaprotegido tiene grandes posibilidades de te-ner problemas. Aunque la mayoría de éstosafecta a plataformas propietarias, el restotampoco esta libre de virus. La plataformaelegida en este caso, GNU/Linux, hace queel sistema sea mas seguro frente a los virusque otras opciones de mercado, como pue-dan ser los sistemas Windows.

Figura 5. Pantalla Antivirus y Filtrado.Antivirus

Existen virus, gusanos... que afecta a lossistemas GNU/Linux. Debemos tener encuenta que el funcionamiento de los ataquees siempre el mismo: buscar una debilidady atacarla. Se caería en un error si se dejaseese flanco al descubierto por el mero hechode pensar que hay poca incidencia de virus

http://osl.uca.es

ii

ii

ii

ii


en esta plataforma.

FSS usa Clam, distribuido bajo licenciaGPL, como antivirus. Se trata de un anti-virus que emplea la base de datos de Ope-nAntivirus (también es un proyecto libre).

Clam está desarrollado en C y tienecaracterísticas como: multihebra, soportaAmavis, escanea en archivos comprimidos,se actualiza automáticamente y aporta mu-chas otras atractivas características. Clamfunciona, con las versiones actuales, en lossistemas operativos Linux, Solaris, FreeBSDy Windows (con cygwin).

Para hacer más sencillo el uso de Clam seha desarrollado un entorno visual sencillo yportable, que hace uso de todas las opcio-nes disponibles para el antivirus vía líneade comandos. (Véase Figura 5)

2.3.6. Firewall

Mediante el uso de Firewalls podemoscontrolar el tráfico entrante y saliente deuna máquina. Su uso permitie controlarquién y con quién se establecen conexionesademás de a través por qué puertos se esta-blece la conexión y los protocolos de comu-nicación usados. De esta manera, se puededeterminar qué comunicaciones se deseanpermitir y qué comunicaciones se deseanprohibir. Para esta labor es interesante dis-poner de una herramienta de escaneo depuertos. Dicha herramienta nos permitirácontrolar qué puertos están abiertos y quéprocesos los gobiernan, ayudando así a lalocalización de posibles brechas en el siste-ma.

Los firewalls son útiles, pero requierenalgo de conocimiento de la arquitectura dered y de las formas de trabajo para confi-gurarlos de una manera correcta. Una con-figuración errónea del firewall puede llevara un mal funcionamiento de otros procesosque estén corriendo en la máquina.

FSS ha optado por incluir un firewallmuy sencillo, Firestarter, que se puede eje-cutar tanto en el entorno KDE como enGNOME. Como complemento ha incluidoel mejor escaneador de puertos del merca-do: Nmap [4]. Esta herramienta nos per-mitirá escanear las posibles debilidades dela máquina y el firewall cortar esos flujosde comunicación. (Véase Figura 6)

Las operaciones del firewall son accionesque afectan en gran medida al sistema, porlo tanto se necesitan derechos de adminis-tración para realizarlas. FSS avisa al usua-rio de esa situación.

Figura 6. Pantalla Firewall.

http://www.uca.es

ii

ii

ii

ii


2.3.7. Contraseñas seguras

Las contraseñas son uno de los pilaresde cualquier sistema seguro. Tener con-traseñas débiles puede provocar múltiplesproblemas (p.e. suplantación de identidad)y por lo tanto elegir la clave adecuada esuna labor a tener muy en cuenta. De la mis-ma manera que es importante la creaciónde la clave, es importante su almacenaje,pues de nada vale una clave compleja quese guarda un medio de almacenamientoinseguro (p.e. un post-it pegado en el mo-nitor).

Existen muchos ataques diferentes parala obtención de claves: ataque por fuerzabruta, diccionario, ingeniería social... Hayque tener en cuenta que una clave identifi-can a un usuario unívocamente; si se con-sigue dicha clave se tendrá acceso a lo quese está protegiendo con ella y se podrá su-plantar a ese usuario con todas sus conse-cuencias.

Figura 7. Pantalla creación claves seguras

FSS proporciona un asistente que guía alusuario en la creación de una clave segura.Permite gestionar las claves del sistema delusuario, informándole de si su contraseñatiene unos niveles mínimos de seguridad yqué condiciones tiene una clave “segura”.El usuario no está obligado a generar unaclave segura, si quiere usar una clave inse-gura se le indicará la calidad de esta, perose le permitirá usarla. (Véase Figura 7)

2.3.8. Chequeo

En algunas ocasiones es interesante co-nocer qué aplicaciones están corriendo enla máquina y así hacerse una idea de quépuertos deben estar ocupados y qué puertosdeberían esta libres (p.e. si se está usandoun cliente de correo deben estar abiertoslos puertos estándar de correo).

Para este cometido FSS ofrece una apli-cación que ayudará a controlar si está eje-cutando alguna de las aplicaciones que ha-yamos definido en una lista. De esta ma-nera, el usuario podrá saber si se está o noejecutando las aplicaciones que le interesacontrolar. (Véase Figura 8)

En lo que a navegadores web se refiereexisten varias opciones. En el desarrollo deFSS se hizo un estudio de los navegado-res disponibles basados en licencias libres yse determinó que la opción ideal era Mozi-lla. Debido a su facilidad de uso, además deser un navegador con proyección de futuro,dispone de un conjunto de usuarios amplio.

http://osl.uca.es

ii

ii

ii

ii


Figura 8. Pantalla chequeo de procesos

Mozilla tiene una arquitectura que per-mite añadir fácilmente aplicaciones exter-nas que implementen funcionalidades es-pecíficas. Aprovechando esta característicase desarrolló FSS como un complementoque ayuda a los usuarios a navegar de ma-nera segura.

2.4. ¿Que debemos hacer para usarFSS?

Hay que seguir unos sencillos pasos: bús-queda, instalación y restauración. La insta-lación tiene como requisito tener instaladopreviamente el navegador web Mozilla.

2.4.1. Búsqueda

El primer paso consiste en localizar el fi-chero de instalación: descargando el archi-vo de instalación de la red a una carpetalocal u obteniéndolo de otro medio. El ob-jetivo es localizar la carpeta local en la que

está el fichero de la extensión.(Véase Figu-ra 9)

Figura 9. Pantalla de búsqueda

2.4.2. Instalación

Una vez seleccionado y ejecutado el ar-chivo de instalación, el usuario selecciona-rá la extensión que va a instalar en el nave-gador web, en este caso FSS. (Véase Figura10)

Figura 10. Selección de la extensión

2.4.3. Restauración

Cuando concluya el proceso de instala-ción el usuario debe reiniciar las aplicacio-nes relacionadas con Mozilla.

Una vez reiniciadas, el usuario podrá ac-ceder a la extensión por los métodos nor-males de acceso a cualquier extensión deMozilla: mediante la barra de estado (conun icono) o a través del menú de herra-mientas de Mozilla. (Véase Figura 11)

http://www.uca.es

ii

ii

ii

ii


Figura 11. Acceso a la extensión

2.5. Conclusiones

La seguridad en la navegación web esuna asignatura pendiente tanto para losusuarios domésticos como para las PYMES.FSS aparece en el horizonte como una op-ción libre que permite, de manera gratuita,establecer altos niveles de seguridad en lanavegación web.

Viene a cubrir el déficit de soluciones in-tegrales de seguridad, basadas en softwarelibre, que permitan a los usuarios inex-pertos obtener unos niveles de seguridadsuficientemente altos como para navegarpor la Red sin excesivas preocupaciones. Sesolucionan en gran medida los problemas,relacionados con la navegación web, de losusuarios en la plataforma GNU/Linux, in-dependientemente de la distribución.

FSS es sencillo en instalación y uso. Estarbasado en software libre hace de esta suiteuna solución flexible, ajustable y actuali-zable fácilmente, permitiendo así que losusuarios completen su funcionalidad conajustes personales.

http://osl.uca.es

ii

ii

ii

ii


http://www.uca.es

ii

ii

ii

ii

Bibliografía

[1] Sitio web del proyecto AGILA:http://gitaca.unex.es/agila

[2] Website ISOhttp://www.iso.org

[3] El REAL DECRETO-LEY 14/1999,de 17 de septiembre, sobre firmaelectrónica:http://www.setsi.mcyt.es/legisla/internet/rdley14_99.htm

[4] Howlett, TonySoftware libre. Herramientas de segu-ridadANAYA. ISBN 84-415-1835-1.

http://gitaca.unex.es/agila

http://www.iso.org

http://www.setsi.mcyt.es/legisla/ internet/rdley14_99.htm



ii

ii

ii

ii


http://www.uca.es

ii

ii

ii

ii

3Implantación de LDAP como sistema de autenticación

centralizada

Caso práctico de uso de software libre en la Universidad

Javier Sánchez Monedero [email protected]

Escuela Técnica Superior de Ingeniería Informática. Universidad deGranada

Luis Meléndez Aganzo [email protected]

Área de Sistemas. Servicio de Informática. Universidad de Córdoba.

Sebastián Ventura Soto [email protected]

Departamento de Informática y Análisis Numérico. Universidad deCórdoba.

Resumen

Este artículo constituye una guía para el di-seño e implantación de un sistema de au-tenticación centralizada basado en LDAP enentornos de red típicos de sistemas infor-máticos de universidades o grandes empre-sas. Estos entornos se caracterizan por te-ner un gran número de usuarios a los que

debe dar una serie de servicios de red (co-rreo electrónico, FTP. . . ), así como posibili-tar el acceso identificado a cuentas de usua-rio tradicionales. En concreto, el artículo sebasa en el proyecto de fin de carrera Im-plantación de LDAP como servicio de auten-ticación centralizada [1], que en la actuali-dad se encuentra en funcionamiento en en-torno de producción en el Servicio de Infor-




ii

ii

ii

ii


mática de la Universidad de Córdoba.Así pues, además del diseño del servicio

de directorio, resulta imprescindible ana-lizar los parámetros que afectan al rendi-miento y seguridad del mismo en funcióndel software que utilicemos. En nuestro ca-so, después de evaluar una serie de produc-tos de software privado elegimos OpenL-DAP y justificamos esta elección medianteun análisis de las posibilidades que ofrece ypruebas de rendimiento e integridad diver-sas.

Finalmente, como complemento a esteproyecto se desarrolló una guía comple-ta de migración de NIS a LDAP utilizan-do OpenLDAP como servidor de directo-rio [2].

3.1. Introducción

En los Centros de Informática se propor-cionan una serie de servicios que requie-ren que el usuario que necesita acceder aellos demuestre su identidad, normalmen-te mediante la introducción de un nombrede usuario y una clave secreta. Puede tra-tarse de servicios restringidos a determina-dos colectivos o del acceso a informaciónprivada del propio usuario (como ficheroso mensajes de correo electrónico).

La información que almacena el siste-ma sobre los usuarios y las claves permi-tidas puede estar en el ordenador al quese accede para obtener el servicio, o residiren un sistema distribuido en el cual todoslos sistemas comparten copias de esa mis-ma información; puede existir un reposito-rio central al que los sistemas consulten la

validez de la información de autenticaciónaportada por el usuario, etc..

Con la tendencia actual de que no existaun gran ordenador central que proporcio-ne todos los servicios, sino que estos seanaportados por una serie de ordenadores es-pecializados (por razones de coste, fiabi-lidad al poder replicar los servicios, etc.),así como la variedad de servicios que ac-tualmente se proporcionan (cuentas inte-ractivas en los ordenadores, correo elec-trónico, acceso a páginas web restringidas,etc.), es especialmente importante implan-tar un modelo de información sobre datosde identidad de los usuarios que pueda seraccesible desde todos ellos. Este modelo deinformación deberá tener una gran fiabili-dad y estabilidad y deberá ser fácil de ges-tionar.

El uso de los servidores de directorio apo-yados en la tecnología LDAP1 para cumplirestos objetivos es cada vez más generaliza-do.

3.2. Soluciones al problema

3.2.1. Solución basada en NIS

El sistema actual2, basado en NIS, solu-ciona en parte la descentralización de la au-tenticación haciendo accesibles a una seriede máquinas una serie de ficheros, en lugarde que cada máquina tenga una copia deestos ficheros. Además, generalmente, la fi-losofía al utilizar NIS era asociar el usuariode un servicio al usuario del sistema ope-rativo: antes, un usuario se conectaba a unservidor central para trabajar, leer su correo

1Protocolo Ligero de Acceso a Directorios (Lightweight Directory Access Protocol)2Llamaremos actual al sistema con NIS candidato a ser migrado a LDAP.

http://www.uca.es

ii

ii

ii

ii


y demás; en la actualidad, el usuario utili-za estos recursos a través de procesos ser-vidores independientes, no desde el propiosistema operativo.

Sin embargo, la asociación de usuario deservicio a usuario de sistema operativo origi-na problemas a nivel de información, pues-to que NIS sólo está preparado para alma-cenar información tradicional de sistemasUNIX, y a nivel de seguridad: cada usuariodel sistema operativo es un punto de ata-que potencial.

Además, NIS presenta otros problemas:

Normalmente se necesita al menosun servidor NIS por cada subred.

Existen limitaciones en las modifica-ciones de datos, que sólo se permi-ten desde el servidor principal y exi-gen la reconstrucción completa delos mapas NIS, que se traduce en unaumento de la carta de red y CPU.Por este motivo, las sincronizacionesno pueden ser inmediatas.

No se pueden delegar privilegios deadministración.

3.2.2. Solución basada en LDAP

Frente a los problemas mencionados, eluso de servidores de directorios LDAP paradar solución a estas necesidades es cada vezmás generalizado. En torno a esta soluciónse plantean una serie de objetivos:

Puesta en funcionamiento de variosservidores LDAP fiables mediante laelección, configuración y optimiza-ción de software de servidores de di-rectorio LDAP.

Conseguido lo anterior, se necesitarealizar pruebas de rendimiento e in-tegridad de datos sobre la estructurade servidores implementada.

Respecto a los clientes, es necesarioun estudio para determinar y confi-gurar el software necesario según lasnecesidades de los mismos.

Finalmente debe diseñarse con cau-tela el proceso de migración de latecnología NIS a LDAP de la maneramás transparente y fiable posible.

Por referirse más a cuestiones directasde administración, los dos últimos puntosse desarrollan en un manual de administra-ción [2] que no forma parte de este artícu-lo.

3.2.3. NSS y PAM

Sabiendo que LDAP no es un más que unprotocolo, ¿cómo funciona la autenticaciónbasada en LDAP?

En los sistemas tipo UNIX modernosla autenticación se realiza mediante PAM(Pluggable Authentication Module, módulosde autenticación conectables). La empre-sa PADL ha desarrollado, entre otras he-rramientas de código abierto, el módulopam_ldap , que integra LDAP con sistemasoperativos que tienen soporte para PAM.

En estos sistemas operativos se podránelegir ficheros de texto sencillo, NIS, NIS+o LDAP para cada uno de los orígenes dedatos que un sistema necesita a través delconmutador de los servicios de nombres(NSS, Name Service Switch).

http://osl.uca.es

ii

ii

ii

ii


Será necesario configurar NSS y PAMadecuadamente para que los futuros clien-tes del directorio sepan dónde encontrarqué tipo de información. Como las alterna-tivas no son excluyentes, parece lógico quesiempre se mantengan una serie de usua-rios fuera del directorio en ficheros tradi-cionales. De este modo, si el servidor de di-rectorio cae, siempre será posible acceder alos servidores vitales de la red.

3.3. Restricciones

3.3.1. Factores dato

Concretando ya en nuestro entorno real,identificamos una serie de limitaciones porparte del cliente3:

El sistema operativo en produccióninstalado en los servidores es LinuxRed Hat Enterprise.

Existe una necesidad de economizaren consumo software y hardware.

En todo momento deben tener prefe-rencia los planos de seguridad e inte-gridad de datos aun a costa de perju-dicar otros planos.

Sin que decaigan los aspectos ante-riores, se debe optimizar el rendi-miento del sistema completo.

3.3.2. Factores estratégicos

Identificadas las restricciones de nuestroproyecto debemos tomar ahora una serie de

decisiones que son las que marcarán la evo-lución del trabajo.

En primer lugar, primaremos el uso desoftware libre por una serie de razones es-tratégicas ya identificadas en la bibliogra-fía [4].

Dentro de nuestro sistema de autentica-ción centralizada, la pieza más importanteva a ser el servidor de directorio LDAP. Aun-que no existen unas pautas preestablecidasque organicen la mayor parte de los pa-sos para la implantación del servidor de di-rectorio, en la bibliografía relacionada conel mundo de los servidores de directorioencontramos unas recomendaciones parala implantación de servicios de directorioLDAP. Timothy A. Howes [3] divide el ciclode vida del directorio en las fases de dise-ño, desarrollo y mantenimiento. Estas fasesson las que seguiremos y nos llevan desdela especificación de las necesidades que vaa tener este hasta la elección del softwarede directorio y su puesta en funcionamien-to

Así pues, la elección del software de di-rectorio será fundamental. En nuestro ca-so determinamos como características re-levantes el coste, cumplimiento de están-dares, rendimiento y escalabilidad, herra-mientas de administración disponibles y, fi-nalmente, adopción en RedIris y otras co-munidades4.

Independientemente de la opción elegi-da, será imprescindible someterla a prue-bas de rendimiento y estabilidad que hagantrabajar al servidor, o conjunto de servido-res, en condiciones similares a las del en-

3El Servicio de Informática de la Universidad de Córdoba.4Puesto que el entorno de implantación es universitario, la comunidad RedIris supone un soporte

técnico al que aportar y del que recibir soluciones que no se debe menospreciar.

http://www.uca.es

ii

ii

ii

ii


torno real (o incluso superen con creces ala futura carga real). Encontramos un soft-ware privado para benchmarking de servi-dores LDAP llamado DirectoryMark5 que nose adaptaba a probar los aspectos del ser-vidor que necesitamos evaluar. Así, decidi-mos implementar un conjunto de guionesde Perl que satisfacieran las necesidades delas pruebas.

Respecto a la migración final de NIS aLDAP vamos a utilizar las herramientas li-bres MigrationTools de PADL Software. Parahacer esta migración de manera progresiva,y no dejar sin soporte a las máquinas conversiones de Solaris sin soporte para LDAP,utilizaremos una pasarela NIS/LDAP priva-da y de pago de la misma empresa.

3.4. Diseño del directorio

El primer paso que se debe dar es el di-seño del directorio que va a alojar toda lainformación necesaria para que el sistemaglobal, el conjunto de clientes, funcione co-rrectamente. Así obtendremos una serie derequisitos que describan cómo va a ser eldirectorio.

Aplicaciones que van a acceder al directorio

Identificamos, por un lado, bibliotecas olibrerías del sistema operativo relacionadascon la autenticación y la información parael funcionamiento de los sistemas operati-vos, que hasta ahora se almacenaba en ma-pas NIS, y, por otro, servidores de Telnet,SSH, FTP, Web, Correo electrónico y NFS,además de aplicaciones Web.

Datos

A partir de las aplicaciones que accedenal directorio se identifican una serie de da-tos que almacenar. Prácticamente bastarácon migrar los mapas NIS (aliases, auto-mount, group, hosts, netgroup, passwd. . . )a LDAP.

Esquemas LDAP necesarios

El RFC 2307 [8], An Approach for UsingLDAP as a Network Information Service, de-fine una serie de esquemas LDAP están-dar para sustituir a NIS. Además de las re-comendaciones del RFC 2307 nos intere-sa crear un esquema propio (uco.schema)que nos va a permitir diseñar un controlde acceso a máquinas y privilegios de admi-nistración que hasta ahora eran imposiblescon NIS.

Espacio de nombres

Diseñar cómo se va a distribuir lainformación por el directorio es esen-cial. Lo más adecuado parece seguirla nomenclatura de NIS en las ramasdel árbol LDAP obteniendo ramas de laforma ou=People,dc=uco,dc=es paralos usuarios u ou=Group,dc=uco,dc=espara los grupos. Para las entidades relacio-nadas con la administración, que no coinci-den con usuarios o entidades reales, lo me-jor será construir una rama o ramas especí-ficas.

5http://www.mindcraft.com/directorymark/

http://osl.uca.es

http://www.mindcraft.com/directorymark/

ii

ii

ii

ii


Topología de la red y replicación

Si queremos obtener una mayor garan-tía de estabilidad y escalabilidad de los ser-vidores LDAP es obvio que debemos repli-car la información entre varios. Parece queuna estructura relativamente sencilla, y queproporciona mejoras en cuanto a la seguri-dad, puede ser la de un servidor maestroy dos de réplica en el que sólo se permi-tan operaciones de escritura en el servidormaestro a través de interfaces seguras. Lamayor parte de la carga de trabajo, las lec-turas, se desviará siempre a los servidoresesclavos.

Seguridad

El aspecto de la seguridad en el directo-rio debe abordarse desde dos perspectivas.

En primer lugar, desde la propia segu-ridad del protocolo LDAP y las restriccio-nes de acceso al directorio. Por la sensibili-dad de la información que se transfiere de-be utilizarse LDAP sobre TSL/SSL siempreque sea necesario. Además, la jerarquía deacceso a ramas del árbol y atributos de lasentradas, como la contraseña, debe definir-se claramente con las listas de control deacceso (ACL, Access Control List) de formaadecuada y teniendo en cuenta que un maldiseño de las ACL puede impactar negati-vamente en el rendimiento del servidor.

En segundo lugar, se debe implementarla seguridad en las cuestiones más comunesa cualquier tipo de servicio. La protecciónfrente a ataques de denegación de servicios(DoS) la consideramos a dos niveles: ata-ques DoS directos a través de LDAP (se con-

trolan mediante la configuración del servi-dor LDAP) y ataques DoS indirectos, quedeben evitarse con una auditoría básica deseguridad. Por supuesto, se debe evitar elacceso de usuarios corrientes a ficheros delservidor LDAP. En todas las máquinas no sedebe dejar entrar a todos los usuarios. Unarama LDAP específica o los ficheros tradi-cionales de UNIX pueden ser un buen lugarpara guardar las listas de administradores.

3.5. Elección de software de directoriopara producción

Una vez analizado qué necesitamos a ni-vel de servidor LDAP, debemos decantar-nos por una alternativa. Según fuentes bi-bliográficas [5] y [6] y de la consultoraMETAspectrum6, el software de directorioLDAP más utilizado es OpenLDAP, MicrosoftActive Directory, iSunONE Directory Servery Novell eDirectory. Respecto a temas co-mo el cumplimiento de estándares e intero-peratibilidad encontramos el Directory In-teroperability Forum7 del Open Group queaporta información interesante. Aunque al-gunos de estos estudios están obsoletos oson poco objetivos, nos sirven de base paraexaminar las posibilidades de cada uno deestos productos.

El análisis realizado se ha basado en elexamen y comparación de las prestacionesofrecidas en las respectivas páginas web decada producto para actualizar o completarlos estudios encontrados.

Seguramente OpenLDAP no sea el me-jor software de directorio; no obstante cree-mos que para las necesidades identificadas

6http://www.novell.com/products/edirectory/metaspectrum.html7http://www.opengroup.org/directory/

http://www.uca.es

http://www.novell.com/products/edirectory/metaspectrum.html

http://www.opengroup.org/directory/

ii

ii

ii

ii


en el apartado anterior no notaremos di-ferencia con las otras alternativas. Deter-minadas carencias, como la falta de herra-mientas de administración pueden suplirsecon software de gestión de directorios inde-pendiente del servidor de directorio.

3.6. Parámetros que afectan al rendi-miento y la estabilidad de OpenL-DAP

Elegido OpenLDAP como software deservidor de directorio, pasamos a una se-gunda fase en la que realizamos un examende sus características con el fin de optimizarsu rendimiento.

Parece que el primer estudio debe cen-trarse sobre qué backend de base de datosdebemos elegir. Según la experiencia en Re-dIris y diversas conversaciones en las listasde correo de OpenLDAP8, a primera vista laestabilidad de LDBM (rutinas de bases dedatos del proyecto GNU) es buena. Pode-mos considerar este backend anticuado pe-ro seguro, aunque no muy eficiente compa-rado con BDB. No obstante, los propios de-sarrolladores de OpenLDAP indican en lasmismas listas que ya no trabajan con LDBMy que el proyecto se encamina hacia el usode BDB (Berkeley DB)9. BDB ofrece ciertasmejoras como consistencia en las transac-ciones, durabilidad, bloqueo de granulari-dad fina. . . aunque la experiencia de uso deOpenLDAP con BDB en ciertos entornos esde inestabilidad del servidor, sobre todo enlas escrituras, en comparación con LDBM.Vemos pues que el uso de BDB debemoscomplementarlo con pruebas propias que

nos aseguren su estabilidad y, en caso deresultados negativos, optar por LDBM. A es-to hay que añadir que LDBM es el backendpor defecto en los paquetes de instalaciónde OpenLDAP en varias distribuciones co-mo Red Hat.

Indexar lo necesario partiendo de las fuentesde información

En todo caso, hay muchos parámetrosque afectan al rendimiento de OpenLDAP(y al de otros servidores) con independen-cia del software de gestión de la base dedatos interna, como es el caso de la indexa-ción de atributos. Los servidores de direc-torio trabajan con bases de datos indexa-das para optimizar las lecturas. Está claroque cuantos más atributos indexemos máseficiente será el acceso a entradas del direc-torio a través de estos atributos. Sin embar-go, la indexación de atributos no se puedetomar a la ligera, ya que impacta negativa-mente sobre los tiempos de inserción y mo-dificación de datos, puesto que es necesariala reconstrucción de índices.

La mejor manera de estimar qué atribu-tos indexar, al menos inicialmente, es par-tiendo de la información que nos da el RFC2307, el conjunto de aplicaciones y servi-cios que acceden al directorio y, finalmente,la información almacenada en los archivosde registro de los servidores LDAP. Este úl-timo caso deberá observarse especialmenteen los primeros períodos de implantacióndel sistema. Basta con buscar líneas simila-res a:

bdb_equality_candidates:

8http://www.openldap.org/lists/9http://www.sleepycat.com/

http://osl.uca.es

http://www.openldap.org/lists/

http://www.sleepycat.com/

ii

ii

ii

ii


(homeDirectory) index_param failed

en los ficheros y contar sus ocurrencias paraorientarnos respecto a parámetros no inde-xados que se estén demandando al servidorcon más o menos frecuencia.

Optimización de OpenLDAP y BDB

Respecto al backend de base de datos esconveniente revisar todas directivas de tra-tamiento de transacciones, caché, compro-bación de errores, etc. de OpenLDAP y BDB.En este sentido desecharemos todas las di-rectivas cuyo uso entre en conflicto con laspremisas de seguridad y estabilidad del ser-vidor. Descartadas, pues, las directivas quenos creen estos conflictos, obtenemos las si-guientes:

cachesize/set cachesize : fijatamaño de la base de datos en cachéde memoria en número de entradas.

checkpoint : frecuencia con que sevacían los buffers de los ficheros detransacciones.

dbnosync y dbsync/set (flagsDB_TXN_NOSYNC): opciones de sin-cronización de la memoria y almace-namiento inmediata o no.

dirtyread : lecturas sobre transac-ciones no confirmadas.

set lg regionmax , set lg bsize ,set lg dir : opciones de ficherosde transacciones de la base de datosy su ubicación física.

Uno de los aspectos fundamentales enla optimización va a ser la cantidad (refe-rida en número de entradas o índices) de

la base de datos que se va a alojar en cachéde memoria principal. Al respecto, encon-tramos en la sección de soporte de OpenL-DAP el artículo How do I determine the pro-per BDB/HDB database cache size? [7], enel que se hace una serie de recomendacio-nes para calcular tamaño mínimo de cachépara optimizar OpenLDAP. Entre ese tama-ño mínimo y elegir tamaños de caché mu-cho más grandes, parece ser que no existenapenas diferencias de rendimiento. La justi-ficación a esto se basa en el funcionamientode los árboles B+ en los que están basadostanto LDBM o BDB. En estas estructuras loque lo que realmente importa es encontrarel índice que apunta a una entrada lo másrápido posible, de modo que interesa guar-dar una copia de los índices en memoriaprincipal. Si la cantidad de entradas y losrecursos hardware lo permiten, lo ideal se-ría ubicar toda la base de datos en memoriaprincipal.

Access Control Lists (ACL)

Otro aspecto de la optimización es el re-ferente a las ACL de control de acceso, que,como hemos comentado, deben simplificar-se al máximo.

Name Service Caching Daemon (NSCD)

Finalmente, aunque no forme parte de laoptimización del servidor, que sí del siste-ma global, debemos tener en cuenta la granreducción en la carga de red y del servidorque supone por lo general la instalación deun servidor NSCD en los clientes. El Demo-nio o Servicio de Caché de Servicio de Nom-bres (Name Service Caching Daemon) guar-da durante un tiempo las consultas de de-

http://www.uca.es

ii

ii

ii

ii


terminados datos que le indiquemos en elcliente para evitar que tengan que volver aser solicitadas al servidor.

3.7. Pruebas de rendimiento e integri-dad de OpenLDAP

Con el fin de determinar el efecto que su-ponen los distintos parámetros de OpenL-DAP y BDB que afectan al rendimiento, de-bemos realizar pruebas que nos aseguren elbuen funcionamiento del sistema. Los obje-tivos que perseguimos con las pruebas derendimiento e integridad son comprobar elimpacto de algunas directivas del backendde Berkeley, comprobar la estabilidad de labase de datos ante operaciones de escritu-ras masivas (modificación de atributos e in-serción y borrado de entradas), comprobarel impacto de la indexación de nuevos atri-butos y obtener datos de eficiencia simila-res a los que se esperen en producción.

Después de medir el tamaño total de labase de datos, vemos factible fijar un tama-ño de caché de memoria que pueda alo-jar en un momento dado a todas las en-tradas del directorio en memoria principal.Las pruebas se realizarán con este paráme-tro fijo.

Herramientas para las pruebas

Para la realización de estas pruebas seha desarrollado un conjunto de scripts dePerl utilizando los módulos necesarios parautilizar el protocolo LDAP (Net::LDAP ) ymódulos para mediciones de tiempo de altaprecisión (Time::HiRes ). Estos automati-zan las siguientes operaciones:

Configuración, llenado e indexado

inicial del servidor.

Realizar una cantidad considerablede operaciones de lecturas y escritu-ras por separado.

Simular un conjunto de operacionessimilares a las reales en las que pue-da ajustarse la cantidad, porcentajey contenido de operaciones de cadatipo.

Medida de los tiempos de cada tipode operación y generación de esta-dísticas, tablas y gráficas ilustrativas.

Pruebas de carga masiva de datos

El objetivo de estas pruebas es compro-bar los límites de adición masiva de datoscon el servidor en línea, así como el impac-to de las opciones de configuración del bac-kend BDB en estas operaciones.

Los resultados dieron pie a la apariciónde problemas de integridad de datos al rea-lizar adiciones masivas con el servidor en lí-nea. Con el servidor parado, y configurandoBDB adecuadamente, comprobamos que enpocos segundos se puede poner en marchael servidor a partir de un fichero de textosencillo de copia de seguridad.

Pruebas de operaciones masivas

Estas pruebas tienen como objetivos de-terminar la estabilidad del servidor antecargas de trabajo masivas y comprobar queel servidor OpenLDAP no empeora su ren-dimiento ni consumo de memoria ante car-gas de trabajo superiores a las de produc-ción. En este tipo de pruebas forzamos unnúmero de escrituras superior al normal en

http://osl.uca.es

ii

ii

ii

ii


directorios para tratar de forzar posibles fa-llos del backend, previo conocimiento queestos podían ser los únicos fallos que tuvie-se.

Como batería de pruebas se lanzaron 10clientes durante 20 horas desde los que sehacían operaciones de lectura y modifica-ción de atributos aleatorios. Sin detener es-tos clientes se incrementó el número de en-tradas y posteriormente se borraron aleato-riamente varias de ellas mientras se mante-nían las operaciones incluso sobre entradasya inexistentes. En ningún momento huboproblemas de integridad de datos.

Pruebas de simulación de entorno real

Finalmente lanzamos unas pruebas quese parezcan más a lo que puede ser un en-torno en producción con la intención de ob-tener datos reales sobre el impacto de la in-dexación de atributos para tipo de opera-ciones similares sobre el servidor. Paralela-mente se busca obtener datos del impactodel aumento de entradas en la base de da-tos sobre varios tipos de operaciones distin-tas.

Las pruebas consistieron en probar di-versas configuraciones de OpenLDAP sobretodo en cuanto a indexación de atributos ysus opciones, por ejemplo, algunas de lascombinaciones de índices que se utilizaronse muestran en la tabla siguiente. Duran-te la ejecución de pruebas se fueron dese-chando las combinaciones que obtenían lospeores resultados al aumentar el númerode entradas progresivamente.

Combinación Líneas del fichero slapd.confindex01 index objectClass eq

index02 index objectClass eq

index uid eq


index uid,uidNumber,

gidNumber eq


index uid,uidNumber,

gidNumber eq,pres

Conclusiones generales sobre las pruebas

En primer lugar, se ha comprobado có-mo puede ser interesante activar temporal-mente los parámetros DB_TXN_NOSYNCyDB_TXN_NOT_DURABLEpara las cargas eindexaciones ya que disminuye el tiempode construcción de la base de datos e índi-ces muy considerablemente. En estos casosno se han observado inconsistencias en losdatos.

Tras someter al servidor a cargas de ope-raciones muy superiores a las que tendrá ensu fase de producción, no se han observa-do tampoco ningún tipo de corrupción dedatos, ni siquiera forzando miles de opera-ciones de escritura simultáneas. Parece quela aplicación de los parches oficiales para laversión 4.2.52 de Berkeley DB es suficientepara solventar los problemas de corrupciónde datos de los que se tenían noticias a tra-vés de diversas listas de correo.

Al realizar pruebas con tamaños de ca-ché de memoria pequeños, por ejemplo de10 MB, el proceso de inserción de entradasfalló con el servidor en marcha. Las solucio-nes que se encuentran cuando no se quie-ren utilizar grandes cantidades de caché dememoria pasan por dividir la inserción dedatos en ficheros pequeños, de manera que

http://www.uca.es

ii

ii

ii

ii


la carga de datos se haga de manera gra-dual.

Respecto al uso de herramientas de tra-bajo online de OpenLDAP para cargas masi-vas de datos lo desaconsejamos totalmentepor varios motivos:

El consumo de memoria del servidorcrece hasta incluso duplicar el con-sumo habitual sin que se aprecie unaliberación de la misma a corto plazo,entendiendo por corto plazo el trans-curso de entre 30 minutos y una ho-ra. En estos casos merece la pena rei-niciar el servidor para liberar memo-ria.

Los ficheros de registro de las tran-sacciones ocupan un espacio de discoque supera al tamaño habitual de labase de datos. Se trató de eliminarlos ficheros de registro con las he-rramientas de administración de Ber-keley DB10 sin éxito. Hasta que nose reinició el servidor, los ficheros detransacciones siguieron bloqueados.

En cuanto a la indexación de atributos,para nuestro entorno y el uso que se le va adar al servidor podemos incluir tantos índi-ces como queramos. Las pruebas demues-tran que el tiempo de respuesta del servi-dor para devolver resultados de búsquedasen atributos indexados no empeora aún alincrementar el número de entradas en labase de datos. En este punto recordamosque una copia prácticamente completa denuestra base de datos siempre ha sido alo-jada en la memoria RAM del servidor. Dadoque en nuestro entorno hardware la memo-ria no va a ser un problema para el tama-

ño de la base de datos de OpenLDAP, no sehan realizado pruebas con tamaños inferio-res de caché de memoria. Además, tambiénes conveniente destacar que el tipo de bús-queda que se ha realizado ha sido del tipo“sub”, que es la más corriente en el proto-colo LDAP. Así mismo, como las operacio-nes de escritura reales sobre atributos ca-si siempre se harán sobre el campo de lacontraseña, que no está indexado, el tiem-po de operaciones de modificación generalse mantiene constante independientementedel tamaño de la base de datos.

El tiempo de búsqueda de atributos noindexados crece muy rápidamente confor-me la base de datos tiene más entradas. Portanto debe vigilarse la demanda de atribu-tos no indexados para plantear su indexa-ción, sobre todo cuando estos atributos novayan a ser modificados muy a menudo. Es-to puede hacerse analizando los ficheros deregistro generados por el proceso slapd encasi todos los niveles de depuración.

Los ficheros de índices no ocupan dema-siado. Al indexar uno de los campos de ma-yor tamaño, como por ejemplo el campo cn,el fichero de índices de este campo apenasha sobrepasado 1 MB de tamaño en discopara una base de datos de 70 MB con uncampo cn en todas o casi todas sus entra-das. Estos datos se refieren siempre al tipode índices utilizados en las pruebas, eq ypres.

3.8. Conclusiones

A partir de los resultados de las prue-bas, concluimos que se ha acertado al elegir

10Estas herramientas comprueban qué ficheros de transacciones se pueden borrar y cuáles no.

http://osl.uca.es

ii

ii

ii

ii


OpenLDAP como software servidor de di-rectorio. En conjunto, se ha creado un siste-ma de alta disponibilidad, fiabilidad y ren-dimiento junto con una guía completa demigración de NIS a LDAP desde la instala-ción de los servidores LDAP hasta el reem-plazo progresivo de LDAP con NIS apoyán-dose en la pasarela NIS/LDAP.

Como futuro trabajo sería interesantecomprobar el impacto de la encriptación decomunicaciones sobre el rendimiento glo-bal del sistema. También como trabajo futu-ro, y según se vayan definiendo directricesy acuerdos en RedIris será necesario adap-tar los esquemas utilizados o cualquier otroaspecto del directorio.

http://www.uca.es

ii

ii

ii

ii

Bibliografía

[1] Javier Sánchez Monedero, Implanta-ción de LDAP como sistema de auten-ticación centralizada. Manual Técni-co., Directores: Sebastián Ventura So-to. Universidad de Córdoba. Departa-mento de Informática y Análisis Nu-mérico, Luis Meléndez Aganzo. Uni-versidad de Córdoba. Servicio de In-formática. Área de Sistemas, 2004.

[2] Javier Sánchez Monedero, Implanta-ción de LDAP como sistema de autenti-cación centralizada. Manual de Admi-nistrador., Directores: Sebastián Ven-tura Soto. Universidad de Córdoba.Departamento de Informática y Aná-lisis Numérico, Luis Meléndez Agan-zo. Universidad de Córdoba. Servi-cio de Informática. Área de Sistemas,2004.

[3] Timothy A. Howes Ph.D., Mark C.Smith, Gordon S. Good, Unders-tanding and Deploying LDAP Direc-tory Services, AddisonWesley, Segun-

da edición 2003, ISBN: 0-672-32316-8

[4] Monera Daroqui, Modelos de ne-gocio basados en software libre,http://www.opensistemas.com/Articulo_completo.644+M54a708de802.0.html , Pro-pietario: OpenSistemas. Fecha deConsulta: octubre 2004

[5] Brian Arkills, LDAP Directories Ex-plained: An Introduction and Analysis,Addison Wesley, 2003, ISBN: 0-201-78792-X

[6] Norbert Klasen, A ComparativePerformance Analysis of 7 Light-weight Directory Access Protocol,http://www.daasi.de/staff/norbert/thesis/ , Propieta-rio: DAASI International. Fecha deConsulta: octubre 2004

[7] Kurt Zeilenga, How do I determinethe proper BDB/HDB database cachesize?, http://www.openldap.org/faq/index.cgi?_recurse=1&file=190 , Propietario: TheOpenLDAP Foundation. Fecha deConsulta: octubre 2004

[8] L. Howard, RFC 2307:“An Approachfor Using LDAP as a Network Informa-tion Service”, http://www.ietf.org/rfc/rfc2307.txt , Propieta-rio: The Internet Society. Fecha deConsulta: octubre 2004

http://www.opensistemas.com/Articulo_completo.644+M54a708de802.0.html



http://www.daasi.de/staff/norbert/thesis/

http://www.daasi.de/staff/norbert/thesis/

http://www.openldap.org/faq/index.cgi?_recurse=1&file=190



http://www.ietf.org/rfc/rfc2307.txt

http://www.ietf.org/rfc/rfc2307.txt

ii

ii

ii

ii


http://www.uca.es

ii

ii

ii

ii

4MOVICUO: Comunicaciones móviles y software libre para la

ubicuidad

Javier Domingo Carmona Murillo [email protected]

Depto. Informática. Universidad de Extremadura.

José Luis González Sánchez [email protected]


Alfonso Gazo Cervero [email protected]


Lorenzo Martínez Bravo [email protected]


Resumen

Las comunicaciones móviles se encuentranen un proceso de evolución constante. Des-de la aparición de GSM (2G), que ofreceservicios de voz a través de una red de cir-cuitos conmutados, distintos cambios en latecnología han permitido adaptarse a las

necesidades de los usuarios. GPRS (2.5G)complementa el diseño de GSM con unared de conmutación de paquetes para eltráfico de datos, además de aportar QoS.Sin embargo, las tasas de velocidad alcan-zadas en GPRS (171,2 kbps en situacio-nes ideales) no son adecuadas para deter-minados servicios como el tráfico multime-





ii

ii

ii

ii


dia. UMTS (3G) utiliza un nuevo métodode acceso al medio, CDMA (Code DivisionMultiple Access), que añade complejidadpero permite velocidades más altas (hasta2Mbps).

Partiendo de esta situación surge MOVI-CUO1, un proyecto de investigación centra-do en el estudio de las tecnologías de comu-nicaciones móviles más utilizadas (GSM,GPRS y UMTS), y su posible desarrollo ensistemas libres como GNU/LinEx. El resul-tado de este desarrollo es la aplicación libreGNOME-GPRS, una herramienta que solu-ciona el vacío de conectividad a Internet através de GPRS.

4.1. Introducción

Más de mil millones de personas en elmundo (uno de cada cinco habitantes) ymás de 200 países, utilizan teléfonos móvi-les GSM (Global System for Mobile commu-nications). Esto ha supuesto que sea la tec-nología de referencia para la telefonía mó-vil al ser la elección de más del 80 % de losnuevos clientes, haciendo que la cantidadde terminales móviles superen a las líneastelefónicas fijas.

A pesar de estas cifras, ya han apareci-do varias tecnologías que ofrecen otro tipode servicios que GSM no permite por suscaracterísticas de diseño. Evoluciones comoGPRS (General Packet Radio Service), quepermiten el acceso a redes de datos, en lu-gar de las tradicionales redes de voz, han

supuesto que el acceso a Internet tenga otralanzadera con millones de usuarios poten-ciales, que cada vez demandan tecnologíasque ofrezcan más movilidad.

Considerando este proceso de evolución,Movicuo es una base en la que apoyarsepara el desarrollo de sistemas de comuni-caciones móviles de última generación, yaque en este proyecto se detallan todos losaspectos tecnológicos principales de las tec-nologías GSM, GPRS y UMTS (UniversalMobile Telecommunications System), ade-más de aportar una solución libre para laimplantación de GPRS en un sistema comoGNU/LinEx. Los avances del proyecto pue-den consultarse desde su página web [1].

4.2. Desarrollo e implementación deconexiones GPRS en GNU/LinEx

4.2.1. Introducción

Para el desarrollo de conexiones GPRSen GNU/LinEx, nos hemos basado en lasrecomendaciones de los estándares publi-cados por la 3GPP [2], lo que permite lacompatibilidad del desarrollo con todos losdispositivos que sigan esta filosofía. La ve-locidad máxima alcanzada de GPRS es, teó-ricamente, 171,2 Kbps. Este valor es una re-ferencia, ya que se alcanzarían si un mismousuario utilizara los ocho time-slots 2 o ra-nuras de tiempo del canal, si ningún otrousuario estuviera compartiéndolo, y si no

1Este proyecto ha sido patrocinado en parte por la Junta de Extremadura a través de los proyec-tos siguientes: Proyecto Agila (Expediente 2PR03A090) y Campus Ubicuo (Expediente PDT05A041)http://gitaca.unex.es/agila

2Cada una de las 8 franjas de tiempo en el que TDMA (Time Division Multiple Access) divide uncanal de 200 Khz de frecuencia.

http://www.uca.es


ii

ii

ii

ii


Figura 4.1: Estructura del sistema

existieran códigos de protección 3. En rea-lidad, el terminal también limitará esta ve-locidad. Hay definidas 29 configuracionesque indican cuantas ranuras de tiempo pue-den usarse para subida y bajada. La capaci-dad de cada una de estas franjas de tiem-po varía (de 9 a 20 Kbps) dependiendo dela codificación que se utilice. Para los telé-fonos GPRS, donde la limitación de consu-mo de potencia es un factor clave, las confi-guraciones más comunes son del tipo 4+1,que significa que se usan cuatro ranuras detiempo para la bajada y una para la subi-da. Los dispositivos consumen más energíacuanto mayor sea el bit rate, aunque mu-cha de la energía generada por la bateríaes perdida en forma de calor. Por eso, es di-fícil construir un terminal que utilice las 8rodajas de tiempo para la subida y las 8 pa-ra la bajada, ya que el consumo de energíasería enorme y el calor desprendido inso-portable. También hay otros tipos de limi-taciones físicas debido al uso de los trans-ceiver 4, pero la explicada anteriormente esla más importante. [3]

4.2.2. Componentes de un sistema móvil

En el proyecto Movicuo, el acceso a In-ternet a través de GPRS se realiza utilizan-do el teléfono móvil como módem, mien-tras que el sistema GNU/LinEx es el sistemafinal que actúa de interfaz con el usuario.Siguiendo la nomenclatura utilizada por la3GPP [2], los elementos que componen elsistema son [4]:

TE (Terminal Equipment): Dispositi-vo en el que están las aplicacionesy el interfaz con el usuario (ordena-dor).

MT (Mobile Terminal): Es la parteque conecta a la red (teléfono mó-vil).

A la hora de establecer una conexión, loprimero que tendremos que hacer es conec-tar los dispositivos en la capa física. Estaconexión puede realizarse bien con un ca-ble USB, cable serie, Bluetooth, Infrarrojos,etc. Será necesario tener instalado el mó-dulo que el sistema operativo (en nuestrocaso GNU/LinEx) tiene que cargar para re-

3El interfaz aéreo introduce muchos errores, por esto, se definen cuatro códigos de protección quelimitan la velocidad.

4En comunicaciones se define como un transmisor/receptor de señales de radio frecuencia. Seutiliza conectar dispositivos por enlaces inalámbricos.

http://osl.uca.es

ii

ii

ii

ii


conocer dicha conexión física entre el TE yel MT.

El siguiente paso consiste en estableceruna conexión punto a punto (PPP - Point toPoint Protocol) entre los dispositivos. PPPestá implementado en la mayoría de lossistemas operativos, entre ellos Debian (yGNU/LinEx). PPP crea un interfaz de comu-nicación hacia las capas inferiores y permi-te a la capa IP comunicarse con la red deforma transparente. Además realiza otrasoptimizaciones, como evitar el envío de in-formación redundante. En la figura 4.2,aparece la pila de protocolos resultante trasla activación de PPP. [5]

4.2.3. Acceso a capas inferiores. ComandosAT+

Una de las características más interesan-tes en la comunicación entre el MT y elTE, es el acceso a las capas inferiores me-diante los comandos AT. Para proporcionara los desarrolladores el acceso al hardwa-re del terminal GPRS y a las propiedadesde la red directamente, el estándar GPRSdefine una serie de comandos AT (ATten-tion commands). Los comandos AT han si-do (y son) desarrollados con la recomenda-ción ITU-T 5 V.25ter (Serial asynchronousautomatic dialing and control), con el obje-tivo de dar un conjunto de comandos queel sistema de comunicaciones debe ofrecera las capas superiores.

Por lo tanto, muchos de los comandos ATson también usados en GSM y UMTS, asícomo en los módems tradicionales. El con-junto de comandos AT que se han añadidoal de comandos tradicionales de control de

módem, se denominan AT+ o comandos ATextendidos. El estándar [6] describe el con-junto de comandos AT+ para los terminalesGSM, incluyendo GPRS.

4.2.4. Conexión a la red

Veamos que ocurre cuando un teléfonomóvil (GSM con funcionalidad GPRS), seconecta a la red. En primer lugar, el dispo-sitivo necesita decirle a la red que puedehacer y recibir tanto conexiones GSM comoGPRS. Este procedimiento se llama Attachy es similar para GSM y GPRS. Lo contrariode un Attach GPRS lo llamaremos DetachGPRS, que elimina el terminal GPRS de lared. Esto ocurre cuando se apaga el teléfo-no, al igual que el Attach se produce al en-cenderlo. Para ejecutar el Attach (o detach)a la red, se utiliza el comando AT+CGATT.

Una vez realizado el Attach, el móvil ne-cesita una dirección IP y otros parámetrosde conexión. Esta tarea es realizada me-diante la activación del contexto PDP (Pac-ket Data Protocol). El contexto PDP pue-de ser visto como un registro software quemantiene parámetros que son relevantespara una conexión concreta. Esta informa-ción incluye los protocolos que serán utili-zados (IP,X25, PPP,etc), la dirección IP (sise usa el protocolo IP), la QoS [7] (o me-jor dicho, su perfil), e información de com-presión de datos. La activación del contextoPDP hace que el dispositivo GPRS sea visi-ble para el GGSN (GPRS Gateway SupportNode), que hace posible conexiones con re-des externas a GPRS.

Para activar el contexto PDP, el estándarGPRS define el comando AT+CGDCONT.

5Unión Internacional de Telecomunicaciones. ITU es un organismo de las Naciones Unidas encar-gado de regular las telecomunicaciones, entre las distintas administraciones y empresas operadoras.

http://www.uca.es

ii

ii

ii

ii


Figura 4.2: Pila de protocolos del enlace PPP

Este comando permite indicarle a la red losvalores utilizados para establecer un con-texto PDP. En la figura 4.3 se muestra la se-cuencia de mensajes AT del Attach, seguidopor la activación del contexto PDP. Ahora elusuario GPRS estará preparado para enviary recibir paquetes [8].

Esta primera parte ha dado un conoci-miento general de cómo activar una co-nexión GPRS a través de comandos AT+.En el proyecto Movicuo, esta activaciónse ha realizado desde el sistema operativoGNU/LinEx, aunque la metodología segui-da es similar para el resto de sistemas Li-nux. Los comandos AT extendidos utiliza-dos en el proyecto, aparecen en los están-dares del 3GPP [6].

4.3. Solución de conexión GPRS sobreGNU/LinEx. GNOME-GPRS

4.3.1. Introducción

Partiendo de la investigación presentadaen los puntos anteriores, desde el proyec-to Movicuo quisimos plasmar este esfuerzoen un desarrollo que fuera útil a los usua-rios de Linux y que siguiera los objetivos deaccesibilidad propuestos en el proyecto.

Este desarrollo es la herramien-ta GNOME-GPRS, una aplicación paraGNU/LinEx (y otros sistemas Linux) quepermite realizar conexiones a Internet através de GPRS usando como módem unteléfono móvil. GNOME-GPRS se ha imple-mentado utilizando programación GNOME[9], por lo que la aplicación tendrá el mis-mo aspecto que el resto del sistema.

http://osl.uca.es

ii

ii

ii

ii


Figura 4.3: Activación del contexto PDP con comandos AT+

Ventana principal de la aplicación

La ventana principal del programa tieneun aspecto sencillo (ver Figura 4.4). Trasejecutar el programa por primera vez, oen general cuando GNOME-GPRS no estecorrectamente configurado, muchos de suscomponentes estarán desactivados, lo quesignifica que el programa no conoce su va-lor. Así, los componentes Proveedor y Puer-to, que son entradas de texto no modifica-bles, estarán desactivadas hasta que no seconfigure el programa. De la misma forma,los botones Conectar y Analizar gráficas es-tán también desactivados. En la parte infe-rior de la ventana, aparecen tres botones,que sí están activados, éstos son: Ayuda,Configuración y Salir. En este documentotan sólo vamos a explicar la opción de con-figuración de la aplicación, ya que los otrosdos botones tienen funciones obvias.

Configuración

Al pulsar sobre el botón Configuraciónen la pantalla principal, accederemos a unade las partes fundamentales de GNOME-

GPRS, ya que para poder realizar la cone-xión, es necesario establecer algunas opcio-nes. Lo primero que veremos al acceder aesta sección del programa será una venta-na con cuatro pestañas, que definen cuatrotipos de opciones bien diferenciadas. Vea-mos cada una de ellas por separado.

PARÁMETROS OBLIGATORIOS: Per-mite establecer las opciones mínimassin las cuales no se puede conec-tar. Además, tan sólo configurandocorrectamente estas opciones la co-nexión se puede realizar sin ningúnproblema, aunque si hacemos eso,no estaremos aprovechando todas lasposibilidades que permite GNOME-GPRS. Esta ventana se divide en dospartes, la parte superior en la quese configura el dispositivo que tene-mos conectado, y la parte inferior enla que se configura el operador conel que se va a conectar. Para confi-gurar el teléfono, debemos rellenartres campos, que pueden ser configu-rados automáticamente por GNOME-GPRS utilizando el botón Detectar.

http://www.uca.es

ii

ii

ii

ii


Una vez configurada la parte del dis-positivo en los parámetros obligato-rios, es necesario que se den valo-res relacionados con el proveedor delservicio al que se está suscrito, y queofrece el servicio GPRS.

PARÁMETROS AVANZADOS: Tras re-llenar los parámetros obligatorios,las siguientes opciones a configurarson los parámetros avanzados. Laventana ahora se divide en cinco par-tes (DNS, Aspecto al conectar, QoS,Opciones de las gráficas y Otros pa-rámetros). En la parte superior de laventana está el apartado de configu-ración de los servidores DNS. Aspec-to al conectar contiene dos casillas deactivación, que establece el compor-tamiento de GNOME-GPRS una vezque se conecta. Integrar en el área denotificación permite que al conectar,las ventanas de GNOME-GPRS desa-parezcan, quedando únicamente unpequeño icono en el área de notifica-ción del panel del escritorio de GNO-ME. De esta forma, no queda ningu-na ventana abierta de la aplicación,y tan sólo tendremos un pequeño bo-tón que irá cambiando según este-mos enviando datos, recibiéndolos oambas cosas a la vez. Una vez con-figurado el aspecto, aparece el apar-tado dedicado a la calidad del ser-vicio (QoS). Únicamente tendremosque decirle al programa si queremosactivar la QoS o no. Si decidimos ac-tivarla, tendremos que configurar lasúltimas dos pestañas de la ventana:QoS solicitada y QoS mínima. Si no,los valores de estas dos últimas pes-

tañas serán ignorados. Tras la QoS,GNOME-GPRS nos da la posibilidadde configurar las Opciones de las grá-ficas. La aplicación nos permite vergráficamente la velocidad de subiday bajada en cada momento.

QoS SOLICITADA: La QoS en GPRSse define a través de cinco pará-metros: Prioridad, retardo, fiabili-dad, throughput máximo y throug-hput medio. Tanto en este apartadocomo en el de QoS mínima, se pue-den elegir varios valores para cadauno de los parámetros.

QoS MÍNIMA: Con la QoS solicitada,le indicamos a la red cuales son losvalores de QoS que nos gustaría te-ner. Luego la red puede darnos o noesos valores requeridos en función dela disponibilidad de recursos que ten-ga, del número de usuarios conecta-dos y muchos factores más de los quedepende la negociación. Sin embar-go, la QoS mínima va un paso másallá y establece los cinco valores deQoS mínimos sin los cuales no se po-drá realizar la conexión.

Conectar

El botón Conectar inicialmente se en-cuentra deshabilitado, y no se puede pulsar.Se mantendrá así hasta que GNOME-GPRSesté configurado correctamente. Cuando sepulsa el botón, comienza el proceso de co-nexión. El programa negocia con la redla configuración elegida para llegar a unacuerdo. Podemos conocer el estado en elque se encuentra GNOME-GPRS a través delos mensajes que se muestran en la ventana

http://osl.uca.es

ii

ii

ii

ii


Figura 4.4: Aspecto inicial de GNOME-GPRS

Figura 4.5: Aspecto al conectarse

Conectando. Si la negociación ha sido satis-factoria, desaparece Conectando y aparecela ventana Conectado (figura 4.5). A travésde ella, podemos dar por finalizada la cone-xión y salir, o bien acceder a la informaciónde la actual conexión (Situación de la co-nexión, Velocidad de bajada, velocidad desubida, dirección IP, datos recibidos, datosenviados, etc). Si se ha elegido el soportede gráficas, en Información aparece un grá-fico que indica constantemente la velocidadde la conexión.

4.4. Estudio práctico. Resultados

La aplicación GNOME-GPRS ha sido di-señada no sólo para ofrecer una soluciónpara los usuarios finales, sino también paraevaluar la red GPRS. Así, las pruebas eva-lúan tanto la aplicación, como la propia redGPRS.

El módem (teléfono) utilizado para laspruebas es un Motorola c353, un teléfonomultislot clase 8 (4+1), por lo que utiliza 4ranuras de tiempo del canal para la de ba-jada y una para la subida. Los dispositivosque se comercializan en la actualidad sonde este tipo. A continuación se explica ca-da una de las cuatro pruebas y el resultado

obtenido en cada una de ellas.

4.4.1. Caso 1. Tráfico constante sin QoS

El primer caso que se plantea en este es-tudio práctico es el análisis de una conexióncon un tráfico lo más invariable posible. Enprincipio, la transferencia de un fichero degran tamaño, es uno de los casos en losque la velocidad se muestra más constan-te. En esta conexión, se ha descargado unfichero, con un tamaño aproximado de 1MB. La gráfica resultante de esta conexiónse muestra en la figura 4.6. El eje Y indi-ca el valor de la velocidad medida en kbps,mientras que el eje X es el tiempo. La ve-locidad de bajada mantiene una situaciónmás o menos estable alrededor de los 45kbps, con subidas hasta los 56 kbps, mien-tras que la velocidad de subida se mantienedurante toda la conexión por debajo de los5 kbps.

Nos fijaremos primero en la velocidad desubida que es mucho menor con respecto ala de bajada. Por las características del ter-minal, esto es lógico, ya que el teléfono quese utiliza para las pruebas utiliza tan sólouna rodaja de tiempo en la subida frente acuatro en la bajada.

http://www.uca.es

ii

ii

ii

ii


Con respecto a la velocidad de descarga,las variaciones que se observan, son propiasdel tráfico a ráfagas de Internet, que tam-bién se verán acentuadas al transmitir so-bre una red GPRS, veamos porqué. Las ca-racterísticas del interfaz aéreo de GPRS ha-cen que el tráfico de varios usuarios puedancompartir los recursos de una misma ranu-ra de tiempo del canal, algo que no ocurreen GSM. Además, el tráfico generado porlas llamadas (GSM) es priorizado frente alde datos GPRS, en el sentido de que ocupaen primer lugar los recursos a menos queestos estén reservados explícitamente paraGPRS.

Para los usuarios de GPRS, las rodajasde tiempo del canal que no estén siendoutilizadas por conexiones GSM, son recur-sos disponibles que podrán compartir. Es-to hace que la velocidad alcanzada por unasesión de datos GPRS dependa mucho delresto de usuarios que tienen necesidad detransmitir en la misma célula de cobertu-ra, sobre todo los que lo hacen a través deGSM. La velocidad puede variar mucho enconexiones GPRS, ya que en un momen-to dado, cuando hay muchos usuarios deGSM conectados, la velocidad que alcanza-remos será baja debido a que las ranurasde tiempo del canal están ocupadas en esasllamadas. Sin embargo, en un momento in-mediatamente posterior, una de esas llama-das termina liberando así una de las ranu-ras ocupadas, que será utilizada por la co-nexión de datos GPRS que podrá aumentarla velocidad, hasta que se produce otra lla-mada GSM, que coge de nuevo la ranura detiempo del canal, reduciendo otra vez la ve-locidad de GPRS, y produciendo la mismasituación.

La velocidad alcanzada en esta prueba,

está en torno a los 45 kbps (con picos hastalos 56 kbps). Antes se comentó que GPRSpodía llegar a los 171,2 kbps. Esta veloci-dad se consigue si no hubiera otros usua-rios en la misma célula con necesidades deconexión, si las 8 rodajas de tiempo del ca-nal son monopolizadas por el mismo usua-rio, y si no se usa un esquema demasiadoprotector.

Esquema Bit Rate Datos usuarioCS-1 9,05 kbps 8 kbpsCS-2 13,4 kbps 12 kbpsCS-3 15,6 kbps 14,4 kbpsCS-4 21,4 kbps 20 kbps

Para el terminal que se está utilizando, cadaranura de tiempo del canal tiene una capa-cidad aproximada de 14,4 kbps ya que seestá utilizando el esquema CS3. Así, la má-xima capacidad del dispositivo es de 57,6kbps de bajada y 14,4 kbps de subida. Se-gún la gráfica alcanzamos una velocidad de56 kbps, por lo que se puede decir que laaplicación realiza bien su trabajo y que lared nos ofrece el servicio que se esperaba.

4.4.2. Caso 2. Tráfico constante con QoS

Veamos si la activación de la QoS [10]influye para mejorar las prestaciones de laconexión comparando los resultados con elcaso anterior. La situación es similar, es de-cir, se realiza la descarga del mismo ficheroy la configuración únicamente cambia conla activación de la QoS. En la la tabla 4.8 seindican la QoS solicitada y la QoS mínimanegociadas.

La gráfica obtenida en este caso (figura4.7) es similar a la del caso anterior, con la

http://osl.uca.es

ii

ii

ii

ii


Figura 4.6: Gráfica resultante para el Caso 1 Figura 4.7: Gráfica resultante para el Caso 2

QoS mínima QoS solicitadaPrioridad Clase1 Clase1Retardo Clase3 Clase1Fiabilidad Clase3 Clase1Thr. máximo Max 256 kbps Max 2048 kbpsThr. medio 111 kbps 111 kbps

Figura 4.8: QoS solicitada y Qos minima negociadas

http://www.uca.es

ii

ii

ii

ii


diferencia de que los picos bajos se redu-cen. Esto es lógico, ya que según la QoS ne-gociada, la red nos puede ofrecer una velo-cidad media de 111 kbps, por lo que duran-te la conexión, tendremos los recursos delcanal necesarios para alcanzar esta veloci-dad. Aunque se ha negociado un through-put medio de 111 kbps y una velocidad depico de hasta 256 kbps, el dispositivo nopermite alcanzar esa velocidad. Esto haceque no se pueda llegar a ninguna conclu-sión acerca del efecto de la QoS en la ve-locidad, ya que por mucho que la red nosofrezca, no pasaremos de los 57,2 kbps quetiene de límite el móvil. El límite de la ve-locidad viene impuesto por el dispositivo yno por la red GPRS.

4.4.3. Caso 3. Tráfico a ráfagas sin QoS

Una vez analizado el caso de una cone-xión con tráfico constante, veamos que ocu-rre el tráfico a ráfagas típico de Internet. Lagráfica obtenida aparece en la figura 4.9.Esta es distinta a las anteriores, ya que tan-to el tráfico de bajada como el de subida,se muestran muy cambiantes, teniendo lospicos en los momentos en los que se cargala página web, y descansando en los mo-mentos siguientes, para volver a otro picoque significa que otra web es solicitada. Lavelocidad de subida es mucho más alta queen los dos primeros casos. Esto es porqueentonces, tan sólo había que enviar a la redasentimientos y algún mensaje de control.En este caso transmitimos otros datos comolos nombres de usuario y contraseñas delcorreo electrónico (que si van cifradas ocu-pan más tamaño), mensajes que se escribenen foros, datos de formularios, juegos onli-ne, etc. Es decir, al tener que interactuar en

muchas páginas web, la información que seenvía a la red es mayor que en los casosanteriores.

4.4.4. Caso 4. Tráfico a ráfagas con QoS

Ahora se genera el mismo tráfico que enel caso anterior, pero se activa la QoS conlos valores de la tabla del caso 2.

La gráfica que se muestra en la figura4.10 es muy similar a la anterior (figura4.9). Después de varias pruebas con estaconfiguración se ha comprobado que los pi-cos altos suelen ser más frecuentes. Esto eslógico ya que al tener activada la QoS, lared nos debe asegurar los recursos suficien-tes (ranuras de tiempo del canal) para al-canzar la velocidad media y de pico nego-ciada, que son de 111 y 256 kbps respecti-vamente. Aún así, como tan sólo podemosalcanzar 57,2 kbps (como se ha ido expli-cando), las diferencias con el caso anteriorno son muy significativas.

4.5. Conclusiones

Desde la aparición de GSM, y el poste-rior desarrollo de GPRS y UMTS, las tecno-logías móviles han ido integrando nuevosservicios a medida que se han ido necesi-tando, partiendo de la infraestructura exis-tente. Debemos ver el avance en el campode las comunicaciones móviles como unaevolución y no revolución.

Desde el punto de vista práctico, al nopoder explotar todas las capacidades de lared, por no existir dispositivos lo suficien-temente potentes, no se ha podido compro-bar cual es el límite real que pone la redGPRS.

http://osl.uca.es

ii

ii

ii

ii


Figura 4.9: Gráfica resultante para el Caso 3 Figura 4.10: Gráfica resultante para el Caso 4

El dispositivo que tenemos, permite unthroughput máximo de 57,2 kbps según seexplicó en el caso 1 del estudio de resul-tados. Esta velocidad no permite que expri-mamos las capacidades de la red GPRS paraver cuando comienza a flaquear, que hubie-ra sido lo deseable, pero se han llegado aunas conclusiones que coinciden totalmen-te con los aspectos teóricos de la tecnolo-gía, y que de alguna forma, han validado laaplicación desarrollada ya que genera losresultados esperados.

A pesar de estos resultados, hay que te-ner en cuenta la complejidad de la tecno-logía con la que GNOME-GPRS realiza laconexión a Internet. GPRS depende de mu-chos factores que dificultan la interpreta-ción de los resultados, y la mayoría de ellosson externos e imposibles de controlar pornosotros. Número de usuarios que están re-gistrados en la misma célula, número derecursos del canal asignados en cada mo-mento, efecto que se produce en los pará-metros de la QoS al ir conectándose nue-vos usuarios, y otras situaciones incontrola-bles durante la realización de este proyecto,

permitirían que el análisis de los resultadosfuera mucho más completo.

Esta complejidad hace que un proyectode este tipo ayude a los desarrolladores ainvestigar las tecnologías de última gene-ración de comunicaciones móviles. Un pro-yecto basado en estos sistemas no debe te-ner fin, ya que estas tecnologías no deja-rán de evolucionar, y los sistemas Linux,deben estar dotados de estas posibilidades.Así, tanto la investigación realizada como eldesarrollo (GNOME-GPRS) completan unproyecto que puede y debe ser la base pa-ra otros estudios posteriores encaminadosa UMTS. Como trabajo futuro también sepropone realizar nuevos experimentos quepuedan aportar diferencias entre el uso deconexiones con y sin QoS, apoyadas con unestudio estadístico de los resultados.

http://www.uca.es

ii

ii

ii

ii

Bibliografía

[1] Web del proyecto AGILA: http://gitaca.unex.es/agila . Pági-na del Grupo de Ingeniería Telemáti-ca Aplicada y Comunicaciones Avan-zadas de la Universidad de Extrema-dura.

[2] 3GPP (3rd Generation PartnershipProject) es una organización encar-gada del mantenimiento y el desa-rrollo de las especificaciones técnicasde los sistemas de tercera generación(3G) basados en el núcleo de red deGSM y en su sistema de radio enlace.http://www.3gpp.org/

[3] J. Bannister, P. Mather, S. CoopeConvergence Technologies for 3G Net-works: IP, UMTS, EGPRS and ATMJohn Wiley & Sons (2004)

[4] ETSI TS 27.007 Digital cellular te-lecommunications system (Phase 2+);Universal Mobile Telecommunications

System (UMTS); AT command set forUser Equipment (UE).

[5] C. Bettstetter, H-J Vögel, J. Eberspä-cher. GSM Phase 2+. General PacketRadio Service. GPRS: Architecture, Pro-tocols, and Air Interface. Universidadde Munich. 1999.

[6] ETSI TS 07.07 Digital cellular telecom-munications system (Phase 2+); ATCommand set for GSM Mobile Equip-ment (ME).

[7] ETSI TS 27.107 3rd Generation Part-nership Project; Technical SpecificationGroup Services and System Aspects;Quality of Service (QoS) concept andarchitecture.

[8] C. Anderson GPRS and 3G Wíre-less Applications John Wiley & Sons(2001)

[9] R.Moya, A. Del Castillo, R. Majadas,G. Oriol, G. Robles, Y. Moreno, A. Ca-zorla, G. Poo-Caamaño, A. SánchezAcosta, R. Pérez Cubero, C. Garna-cho, J. Pereira, A.Santiago, A.Valdés,C. Saavedra. Programación en el en-torno GNOME The GNOME founda-tion. (2002)

[10] D. Staehle, K. Leibnitz, K. Tsipotis.QoS of Internet Access with GPRS. Uni-versidad de Wurzburg. 2002.



http://www.3gpp.org/

ii

ii

ii

ii


http://www.uca.es

ii

ii

ii

ii

5Ruby on Rails y otros entornos MVC de licencia libre: Un

análisis práctico

Carlos Alberto Paramio Danta [email protected]

Asociación Campogibraltareños Entusiastas del Software Libre

Resumen

Este artículo pretende ser un análisis com-parativo de los distintos entornos de pro-gramación de licencia libre disponibles quesiguen el patrón de diseño MVC (Modelo-Vista-Controlador), y que facilitan el desa-rrollo de aplicaciones web.

Dicho patrón se ha venido utilizandodesde 1979, pero tras la aparición del co-nocido entorno Ruby on Rails se ha popu-larizado enormemente, originando el desa-rrollo de alternativas que se fundamentanen otros lenguajes distintos a Ruby, así co-mo promoviendo indirectamente el uso deotros ya existentes.

5.1. Introducción: El patrón MVC

El patrón de diseño Modelo-Vista-Controlador [1] fue descrito por primeravez en el año 1979 por Trygve Reenskaug,de los laboratorios de I+D de Xerox. Su ca-racterística primordial es la separación dela aplicación en tres componentes distin-tos, a saber: el modelo de datos, la interfazdel usuario, y la lógica de control de laaplicación. De esta manera, un cambio encualquiera de estos componentes (como,por ejemplo, una nueva interfaz) no afectademasiado al resto de código que conformala aplicación.

El desarrollo de una aplicación medianteMVC implica por tanto definir tres compo-nentes interconexos:

Modelo: Representa el estado de la


ii

ii

ii

ii


aplicación, tanto el temporal como elpermanente. No incluye sólo los da-tos, sino que también guarda infor-mación acerca de las reglas a cum-plir por dichos datos, para que losotros componentes no puedan inva-lidarlos. Por ejemplo, si en la imple-mentación de una tienda virtual loscostes de envío no son aplicables pa-ra los artículos en promoción, será elmodelo el que contenga esta restric-ción.

Vista: Genera la interfaz de usuario.Esta interfaz usa normalmente datosdel modelo, como por ejemplo la listade artículos pendientes de envío quepuede verse desde una página de lainterfaz administrativa de una tien-da virtual. La vista carga los datos delmodelo y los muestra con el formatodefinitivo al usuario de la aplicación.

Controlador: Contienen la lógica dela aplicación. Actúan recibiendo lasórdenes del usuario (normalmentea través de una vista), interactúancon el modelo de datos, y respondenmostrando un resultado concreto através de una vista.

Las ventajas de este diseño frente a lamuy usada programación monolítica son:

La separación en componentes nospermite su implementación por se-parado, de manera que el produc-to final es más sencillo de elaborarpor un equipo de desarrollo al divi-dir plenamente las tareas necesariaspara llevarlo a cabo.

La conexión entre componentes serealiza mediante un API (ApplicationProgramming Interface) bien defini-do, siendo posible el reemplazo decualquiera de ellos sin que afecte alresto.

El esquema más típico de una aplicacióndiseñada con MVC es el que se observa enla figura 5.1. Varios controladores accedeny manipulan un mismo modelo de datos, yexisten varias vistas para los datos del mo-delo que cambian cuando lo hace el estadodel modelo.

Conocidos ya los fundamentos de estepatrón de diseño, en las siguientes seccio-nes se hará un brevísimo recorrido por al-gunos entornos de desarrollo MVC de licen-cia libre para el desarrollo de aplicacionesweb, terminando con la revisión técnica deuno de los más populares en la actualidad:Ruby on Rails.

5.2. Apache Struts

Uno de los entornos más veteranos esStruts. Forma parte del colectivo de pro-yectos de la Apache Software Foundation,y tiene más de siete años de desarrollo ymantenimiento bajo sus espaldas. Su arqui-tectura está basada en Model 2, una varian-te del patrón MVC. En julio del 2005 habíaalgo más de 2800 personas suscritas a lalista de correo de usuarios de Struts, lo queda una idea bastante buena de su grado deutilización. Está desarrollado en Java, sien-do la lógica de la aplicación escrita en unservlet y las vistas en JSP (Java Server Pa-ges).

En la actualidad, Apache Struts estácompuesto en realidad de dos entornos de

http://www.uca.es

ii

ii

ii

ii


Figura 5.1: Esquema típico de MVC

programación y algunos otros subproyec-tos: Struts Action Framework y Struts ShaleFramework, siendo el primero el que deri-va del proyecto original, con una lógica decontrol basada en las peticiones del usua-rio; y el segundo una variante que usa Ja-vaServer Faces para construir la interfaz dela aplicación, convirtiéndose en un entornoorientado a la definición de componentesreutilizables. Es conveniente destacar que,efectivamente, son dos entornos separados,cada uno con su propio ciclo de desarro-llo, y por tanto no tiene sentido considerara Shale como una nueva versión de Strutsque viene a reemplazarlo.

Al estar escrito en Java, es posible usarcualquier motor de base de datos al quepueda accederse desde JDBC para el alma-cenamiento del estado permanente del mo-delo de datos.

Existen varias herramientas de modela-do visual para Struts, tales como VisualS-truts, Camino, StrutsConsole, etc., que faci-litan aún más el desarrollo rápido de apli-caciones.

Por último, comentar que hay disponiblemuchísima documentación para el desarro-llo con Struts, así como publicaciones espe-cíficas sobre el tema.

Se puede encontrar mucha más informa-ción en la página del proyecto [2].

5.3. Symfony

Este entorno MVC está escrito en PHP5,y es ya lo suficientemente maduro como pa-ra considerarlo una alternativa eficaz. Usafragmentos de código de Mojavi, otro en-torno MVC escrito en PHP. Entre sus mu-chas características destacan la automatiza-ción de procesos como la internacionaliza-ción, la validación de formularios, la admi-nistración de la caché, scaffolding (genera-ción automática del modelo y un controla-dor con las operaciones básicas para ope-rar con el mismo, a partir de un esquemade definición de datos), administración deun carrito de la compra, interacciones conla aplicación mediante AJAX (AsynchronousJavaScript And XML [3]), tests de unidad(porciones de código que comprueban elbuen funcionamiento de los modelos), testsfuncionales (porciones de código que com-prueban el buen funcionamiento de loscontroladores) y muchas otras.

El esquema de datos del modelo se des-cribe en lenguaje XML, y se dispone de he-

http://osl.uca.es

ii

ii

ii

ii


rramientas para generar las clases corres-pondientes a ese modelo, así como un fi-chero con las sentencias SQL necesarias pa-ra construir las tablas donde se almace-narán los datos permanentes del modelo.Symfony es compatible con la mayoría delos principales motores de bases de datos(MySQL, PostgreSQL, Oracle, MSSQL, SQ-LITE, y otras compatibles para Creole, la ca-pa de abstracción de la base de datos).

Los archivos de configuración del entor-no están escritos en YAML, un lenguaje demarcas mucho más simple que XML, senci-llo de escribir y de analizar sintácticamen-te.

Es posible definir diferentes entornos deejecución, de modo que pueden distinguir-se las distintas configuraciones según este-mos usando la aplicación durante el desa-rrollo, o bien cuando ya esté en producción,o cuando se están ejecutando los tests deunidad. Cada uno de estos entornos pue-den usar, por ejemplo, una conexión a unabase de datos concreta, distinta para cadauno de ellos.

Más información en la página del pro-yecto [4].

5.4. Django

Como no podía ser de otra forma, tam-bién existe ya un entorno MVC para ellenguaje de programación Python. Djangocomparte muchas de las características pre-sentes en Ruby on Rails, tales como scaffol-ding, un vinculador de objetos con la ba-se de datos relacional (ORM), un sistemade plantillas, convención frente a configu-ración, un pequeño servidor web integra-do para probar código durante el desarro-llo, etc. Estas características serán descritas

convenientemente en la siguiente sección.El modelo se describe en su totalidad en

Python, y gracias a esto y al ORM, se pue-den escribir porciones completas de códigosin utilizar una sola sentencia de SQL parael acceso a los datos.

Con el entorno de desarrollo dispone-mos también de una shell interactiva desdela que invocar funciones del mismo, crearnuevas instancias de alguno de nuestrosmodelos, y en general poder probar el APIde nuestra aplicación.

Posee una comunidad de usuarios bas-tante holgada, y una excelente documenta-ción.

Una vez más, información completa enla página del proyecto [5].

5.5. Ruby on Rails

Rails se ha convertido en poco tiempo enel entorno MVC que más está llamando laatención de los desarrolladores de aplica-ciones web de todo el planeta. El lenguajede programación en el que se escriben di-chas aplicaciones en este caso es Ruby, unmoderno lenguaje de scripting orientado aobjetos. El código escrito en Ruby suele serconciso y próximo al lenguaje natural, locual facilita tanto su escritura como su lec-tura posterior (por el mismo desarrolladoro por otros que conforman el grupo de tra-bajo).

El diseño de Rails se ha basado principal-mente en dos conceptos, a saber:

DRY, o Don’t Repeat Yourself: no ne-cesitamos especificar más de una vezun mismo concepto del sistema, co-mo por ejemplo la definición de da-tos del modelo que se usará tanto en

http://www.uca.es

ii

ii

ii

ii


las instancias de la clase como en latabla de la base de datos.

Convención por encima de configu-ración. Es decir, existe un comporta-miento por defecto para muchas delas características a tener en cuentadurante el desarrollo de nuestra apli-cación, de manera que no es nece-sario especificar dicha configuraciónen un fichero aparte (si bien es posi-ble hacerlo en caso de querer obviardichas convenciones para usar unaspropias).

Otras características interesantes deRails son los generadores de código, el so-porte integrado para servicios web (web ser-vices), la mejora de la interacción medianteAJAX, o los tests funcionales y de unidad. Y,en general, es posible tratar con las tareasmás típicas en el desarrollo de una aplica-ción web de una manera muy directa, per-mitiendo que nos concentremos en la lógicaprincipal de la aplicación.

La bibliografía sobre Rails es, por el mo-mento, escasa, aunque ya se ha publicadoun libro [6] dedicado exclusicamente a estetema, y en breve aparecerán al menos otrosdos títulos.

Veamos algunos de los componentes deRuby on Rails que hacen posible esto últi-mo.

5.5.1. Active Record

Como se ha visto, lo normal en un entor-no MVC es que los datos permanentes delestado del modelo se almacenen en una ba-se de datos relacional. Los modelos usadosen la aplicación están escritos en un lengua-je de programación orientado a objetos, y la

conversión de un modelo relacional a otroorientado a objetos (y viceversa) no es enabsoluto directa. La manera tradicional deoperar con la base de datos es usar funcio-nes de acceso a la misma, utilizando SQLcomo lenguaje de operaciones. A veces, seusa un envoltorio para el acceso a la basede datos, de manera que la aplicación pue-da hacerse independiente del motor de ba-se de datos utilizado en la implementación.Existe, no obstante, una solución mejor, queconsiste en proveer de un mecanismo pa-ra vincular las tablas de la base de datos aclases en el lenguaje usado. Este mecanis-mo se denomina Object/Relational Mapping(ORM), y es justo lo que utiliza Ruby onRails.

Supongamos que estamos generandouna aplicación con Ruby on Rails para laadministración de un blog o bitácora per-sonal. En la base de datos, habremos defi-nido una tabla para almacenar los envíos,llamada posts. En nuestra aplicación, tene-mos una clase que define el modelo de da-tos llamado Post. Pues bien, cada una delas entradas (filas) de la tabla correspon-de con una instancia de nuestra clase Post.Las propiedades del objeto Post correspon-den con las columnas de la tabla posts. Parapoder operar con cada una de estas instan-cias, y así modificar su estado (o lo que eslo mismo, alterar el contenido de la base dedatos), dispondremos de una serie de mé-todos para obtener y modificar las propie-dades de las mismas. Incluso estarán dispo-nibles algunos métodos para operar con latabla, como puede ser el método find parabuscar un registro dentro de la tabla. Es-te método nos devolvería un objeto o ungrupo de objetos de tipo Post. O el méto-do save para guardar los cambios en la fi-

http://osl.uca.es

ii

ii

ii

ii


la correspondiente de la tabla. Por ejemplo,podríamos usar las líneas de código que seobservan en la figura 5.2 para mostrar losenvíos realizados por Pedro, al mismo tiem-po que cambiamos el autor de dichos en-víos a Ana.

Otra característica importante de Active-Record es un soporte sofisticado para la va-lidación de datos provenientes de los for-mularios. Basta con agregar una línea a ladescripción del modelo en cuestión pararealizar las comprobaciones más comunes.Algunas de ellas son, por ejemplo:

validates_presence_ofvalidates_numericality_ofvalidates_uniqueness_ofvalidates_format_ofvalidates_lenght_ofvalidates_inclusion_ofvalidates_each

Como muestra, si por ejemplo quisiése-mos añadir la restricción al modelo ante-rior Post de que no sea posible guardar unenvío con los campos title o body vacíos, yque además los envíos tengan forzosamen-te un título único, añadiríamos las siguien-tes sentencias a la clase:

class Post < ActiveRecord::Basevalidates_presence_of :title, :bodyvalidates_uniqueness_of :title

end

5.5.2. Action Pack

Este componente se encarga del soportepara las vistas y los controladores en Rails.

Las vistas no son más que plantillasHTML con porciones de código dinámicasescritas en Embedded Ruby (ERb). Para noromper con el modelo MVC, es convenien-te poner atención en no incluir código en

Ruby dentro de la plantilla que forme partede la lógica de la aplicación. La extensiónde los ficheros plantilla es rhtml. Las eti-quetas usadas para marcar código en Rubydentro de las plantillas son:

< % %> : Ejecuta el bloque de código si-tuado entre las etiquetas.

< %= %> : Ejecuta el bloque de códigosituado entre las etiquetas, e inser-ta el resultado de la ejecución en esaposición.

Los controladores contienen la lógica dela aplicación. Sirven los datos necesarios alas vistas, y reciben los eventos de las pági-nas generadas por las vistas. Son por tantoel centro neurálgico del programa, e inter-conectan al usuario, al modelo y a las vis-tas. Las acciones definidas por un controla-dor se vinculan facilmente con una direc-ción web, de manera que el usuario puedeinvocarlas simplemente escribiendo la di-rección correspondiente. El formato de di-rección típico con el comportamiento pordefecto de Action Pack es el que se muestraen la figura 5.3.

El nombre de la acción corresponde conel nombre de un método definido en la cla-se controlador. En el caso de la URL de lafigura, Rails buscaría un método denomi-nado edit_post definido en la clase admin,que hereda de ApplicationControler. El có-digo correspondiente se puede observar enla figura 5.4.

5.5.3. Creando un blog

Veamos un pequeño ejemplo al comple-to de una aplicación sencilla con Ruby on

http://www.uca.es

ii

ii

ii

ii


class Post < ActiveRecord::Baseend

Post.find(:all, :conditions => "name=’Pedro’") do |post|puts post.titleputs post.bodypost.author = "Ana"post.save

end

Figura 5.2: Ejemplo de recuperación y modificación de datos con ActiveRecord

Figura 5.3: Formato de URL

class AdminController < ApplicationController{

def edit_post# Código correspondiente a la acción

end}

Figura 5.4: Ejemplo de definición de acción

http://osl.uca.es

ii

ii

ii

ii


Rails. El objetivo es obtener la interfaz ad-ministrativa de un blog o bitácora, que de-berá permitir la introducción de noticiasdesde un formulario con algunas restriccio-nes.

Lo primero es generar el esqueleto de laaplicación. Rails dispone de un script paracrear la estructura de directorios donde sealmacenarán los componentes de nuestroprograma, así como la inicialización de al-gunos archivos (como la configuración deacceso al motor de la base de datos, o elcontrolador principal de la aplicación). Bas-ta con ejecutar dicho script pasando comoparámetro el nombre de la aplicación, y ob-tendremos el esqueleto:

$ rails blogcreatecreate app/controllerscreate app/helperscreate app/modelscreate app/views/layoutscreate config/environments...

A continuación, vamos a crear una ta-bla en nuestro motor de base de da-tos que contendrá los envíos que se rea-licen al blog. Llamaremos a esta tablaposts. Guardaremos las instrucciones SQLen db/create.sql.

drop table if exists posts;create table posts (

id int not null auto_increment,title varchar(255) not null,body text not null,primary key (id)

);

Pasamos este fichero SQL a nuestra ba-se de datos, y editamos el fichero con-fig/database.yml para modificar los pará-metros necesarios: adaptador, base de da-tos, nombre de usuario para acceder a la

misma, y contraseña. Como se podrá ob-servar, existen tres entornos de ejecucióndistintos: development, test y production. Elprimero es el que usaremos en el ejemplo, yes utilizado durante el desarrollo para com-probar el funcionamiento de la aplicación;el entorno test es usado por los tests fun-cionales y de unidad, porciones de códigoque realizan comprobaciones con los mode-los y controladores de nuestra aplicación; yel entorno production es, como su propionombre indica, el usado durante la explo-tación del programa.

A continuación, vamos a pedir a Railsque genere para nosotros un modelo con elque vincular la tabla posts. Además, apro-vecharemos para pedir a Rails que nos ge-nere un controlador para realizar las opera-ciones básicas con dicho modelo de datos,es decir, CRUD (Create, Recover, Uptate andDelete). Usaremos un script generado con elesqueleto de la aplicación para tal fin:

$ script/generate scaffold Post Blog

Si ahora utilizamos el servidor web in-corporado por Rails, WEBrick, para acce-der a nuestra aplicación, podremos obser-var toda una interfaz para comenzar a crearnuestras primeras entradas de blog. Arran-camos el servidor web:

$ script/server

Y accedemos con un navegador a la URLhttp://localhost:3000/blog para ejecutar laacción por defecto del controlador denomi-nado blog que acabamos de crear.

Podemos personalizar las vistas genera-das por Rails para modificar el aspecto

http://www.uca.es

ii

ii

ii

ii


de la aplicación. Al generar el controladorBlog, Rails nos habrá creado una carpetaen app/views con el nombre del mismo,y dentro de ella encontraremos una seriede plantillas de extensión rhtml que contie-nen las etiquetas HTML con código ERb queconforman las vistas de las distintas accio-nes del controlador. Modificando las planti-llas, cambiamos la interfaz del usuario.

5.6. Conclusiones

Definitivamente, el patrón de diseñoMVC está bastante extendido, y son mu-chos los entornos de desarrollo que han idoapareciendo basados en el mismo. Ruby onRails se ha convertido en poco tiempo enuno de los entornos más populares debidoa su excelente comportamiento, y a que ha-ce que el desarrollo se agilice muchísimogracias a sus características de convenciónfrente a configuración, a su ORB, y a susnumerosas funciones de ayuda. Esto permi-te que pueda emplearse mucho más tiempode programación a la implementación detests funcionales y de unidad, por ejemplo,que aseguren un mínimo de calidad en ca-da uno de los componentes del programa.

Para más información, se puede consul-tar la página del proyecto [7].

http://osl.uca.es

ii

ii

ii

ii


http://www.uca.es

ii

ii

ii

ii

Bibliografía

[1] Modelo Vista Controladorhttp://es.wikipedia.org/wiki/MVCEdición en español de Wikipedia, laenciclopedia libre.

[2] Apache Struts Project.

http://struts.apache.org/

[3] Asynchronous JavaScript And XML.http://es.wikipedia.org/wiki/AJAX

[4] Symfony project.http://www.symfony-project.com/

[5] Django project.http://www.djangoproject.com/

[6] Dave Thomas. David HeinemeierHansson. Agile Web Development WithRails. The Pragmatic ProgrammersLLC. (2005)

[7] Ruby on Rails Framework.http://www.rubyonrails.org/

ii

ii

ii

ii


http://www.uca.es

ii

ii

ii

ii

6Implantando GNU/Linux: Una visión desde un

Ayuntamiento

Juan Fernando Fernando Sánchez [email protected]

Departamento de Informática (CPD). Ayuntamiento de San Roque.

Resumen

El Ilustre Ayuntamiento de San Roque to-mó la decisión en la legislatura del 2005de impulsar el Software Libre [1]. Entre lasdiversas iniciativas, un punto fundamentales la implantación de sistemas GNU/Linuxen las dependencias del Ayuntamiento. Es-te artículo explica las diversas solucionesempleadas y los problemas encontrados du-rante la implantación.

6.1. Usando GNU/Linux

A la hora de buscar alternativas viablesbasadas en GNU/Linux, hay que distinguirdos bloques fundamentales. El lado servi-dor y el lado cliente. Mientras que en el pri-mer caso, los productos están muy evolu-

cionados, en el segundo se está empezadoa encontrar soluciones parcialmente opera-tivas para el usuario final.

6.1.1. Lado Servidor

En este apartado, el Ayuntamiento tie-ne completamente funcionales diversas so-luciones y con otro pequeño grupo se estánrealizando pruebas finales para la puesta enmarcha en entornos de producción. En con-creto, se han implantado servidores de ar-chivos, autenticación centralizada, SGDB,web corporativas, servidores de correo, cor-tafuegos, proxys y vpns.


ii

ii

ii

ii


6.1.2. Lado Cliente

De cara al usuario final, el funcionario dela administración local en nuestro caso, elperfil estándar en su relación con los proce-sos informáticos es el siguiente:

Aplicaciones ofimáticas (MicrosoftOffice y Corel Wordperfect). En esteapartado la mayoría de los documen-tos son escritos realizados en Wordaunque también se encuentran hojasde cálculos y bases de datos access.

Navegador de internet (Microsoft In-ternet Explorer)

Lector de correo (Microsoft OutlookExpress)

Cliente de Terminal Server para ac-ceso al servidor central donde a efec-tos prácticos para el usuario se traba-ja como si fuera localmente con lasaplicaciones de gestión: Padrón, Re-gistro de E/S, Contabilidad, etc.

En este perfil estándar se encuentran ex-cepciones con aplicaciones específicas co-mo pueden ser programas de banca elec-trónica, diseño asistido por ordenador, etc.El planteamiento de trabajo en el CPD hasido buscar alternativas a los tres primerospuntos.

La migración de la aplicaciones de ges-tión accedidas a través de Terminal Server,no es viable porque no existen en el mer-cado alternativas válidas y fiables destina-das a GNU/Linux. En este sentido los Or-ganismos y Administraciones Públicas de-berían establecer mecanismos y directricespara promover y fomentar la aparición enel mercado tecnológico de alternativas, no

solamente que funcionen en la plataformaGNU/Linux sino que además posean licen-cias GPL [3].

6.2. Servidor de archivos. Samba [3]

El objetivo es tener centralizados los do-cumentos de usuarios en una máquina do-tada con la capacidad hardware para tole-rancia de fallos (sistemas RAID) y copiasde seguridad en cinta. El acceso al siste-ma de archivos desde los puestos clientesdebe ser independiente de plataforma (Mi-crosoft Windows/Unix). El protocolo CIFS(antes denominado SMB) de archivos com-partidos de Microsoft Windows es una solu-ción estándar bastante simple de implantar.Samba [3] es una implementación robustay de alto rendimiento para Unix de ese pro-tocolo. La gestión avanzada de los permi-sos para los usuarios puede realizarse usan-do la capacidad de permisos extendidos conACLs (listas de control de acceso) cuyo so-porte para el sistema de archivos ext3 yaviene incluido en el núcleo 2.6.

El sistema centralizado es un paso im-portante para lograr la movilidad de losusuarios, es decir, que un usuario puedausar cualquier equipo de la red para traba-jar con sus documentos.

No hay que ignorar los posibles proble-mas relacionados con puntos únicos de fa-llo (SPOF) y los cuellos de botella al estarlos documentos ubicados en una máquinaindividual. Cualquier disfunción relativa aesa máquina afectará a todos los usuariosde la red. La infraestructura de red y loscomponentes redundantes deben ser anali-zados para minimizar los riesgos. Los siste-mas distribuidos basados en clusters de al-ta disponibilidad también deberían ser es-

http://www.uca.es

ii

ii

ii

ii


tudiados en profundidad.

6.3. Autenticación de usuarios centrali-zada. OpenLdap [4]

La autenticación de los usuarios en la reddebe ser común a los usuarios de MicrosoftWindows y GNU/Linux para evitar dupli-cidad de trabajos y posibles problemas deintegridad con la gestión de los usuarios(altas / bajas / modificaciones). Esta cen-tralización está ligada fuertemente con elacceso a los archivos de red para compar-tir también los permisos de accesos a esoselementos. OpenLdap [4] es una soluciónque permite la integración de la gestión deusuarios y la comunicación con Samba. Decara al uso en sistemas clientes MicrosoftWindows se plantearon dos posibilidades.

Instalar Samba como un controladorde dominio principal para resolverlas peticiones de los usuarios a la ho-ra de acceder al sistema desde lospuestos clientes.

Usar el módulo pGina [5] que se in-serta dentro de la autenticación es-tándar de Microsoft Windows parapermitir la consulta a un servidorOpenLdap centralizado.

La opción seleccionada y actualmente enfase de pruebas es la primera. El motivode esta elección es que era menos intrusivaen los equipos clientes de Microsoft Win-dows y la ausencia de dificultades impor-tantes durante las pruebas.

6.4. Sistema gestor de bases de datos.PostgreSql [6]

Idénticos motivos que aconsejan la cen-tralización de los documentos son los queconducen a una gestión centralizada de losdatos de las aplicaciones de bases de da-tos. Toda esa información debe estar alo-jada en un sistema gestor de base de da-tos que se haga responsable de mantenerla seguridad, integridad y coherencia inter-na. Se logra, por tanto, un mayor controly seguridad sobre la información, así comofacilitar las tareas de copias de seguridad eintegridad de datos. Las elección de Post-greSql como SGDB se debe a que es un pro-yecto con gran respaldo en la comunidadOpen Source y que uno de sus principalesobjetivos es la fiabilidad de los datos.

6.5. Web, correo, cortafuegos, proxy yvpn

6.5.1. Web departamental

El servidor Apache [7] es utilizado paraofrecer una web en la intranet con las si-guientes características:

Desarrollo de aplicaciones web enPhp 5 [8] y Java (Tomcat [9] +Springframework [10]).

Noticias, wiki, foros y entornos cola-borativos.

6.5.2. Correo corporativo

Qmail [11] fue la opción elegida a la ho-ra de implementar el correo corporativo.Seguridad, fiabilidad y rendimiento fueronlas razones principales para esa decisión.

http://osl.uca.es

ii

ii

ii

ii


Se han adoptados mecanismo para evitarel envío de spam. También se ha integra-do con un antivirus (F-prot) mediante elQmail-scanner [12]. No se ha llegado a po-ner en marcha ninguna solución para la re-cepción de spam por el problema de los fal-sos positivos.

6.5.3. Cortafuegos y proxy

El mecanismo provisto por el núcleo pa-ra el filtrado de paquetes Iptables [13] esuna herramienta de gran potencia y fiabili-dad a la hora de crear un cortafuegos. Porotro lado, Squid [14] es un proxy que per-mite aumentar el rendimiento almacenan-do en caché las páginas solicitadas y ade-más activar el filtrado a nivel de url de laspeticiones de los usuarios. Combinando losdos mecanismos se consiguen sistemas bas-tante robustos respecto a ataques remotosy de gran rendimiento.

6.5.4. Redes privadas virtuales

Como respuesta a la necesidad de co-nectar diferentes sedes con el edificioprincipal y disponiendo de conexiones debanda ancha a Internet se ha utilizadoOpenVpn [15] para unirlas de forma segu-ra estableciendo redes privadas virtuales.

6.6. El lado cliente. Software de Inter-net

Tanto para navegar como para leer el co-rreo se ha optado por los productos de Mo-zilla [16], Mozilla Firefox y Mozilla Thun-derbird. Entre los motivos para esta elec-ción cabe destacar la existencia de versio-nes tanto para Microsoft Windows como

GNU/Linux y que son productos sencillosy ágiles. La seguridad aportada por una al-ternativa en Microsoft Windows al InternetExplorer y Outlook Express es ya un factorque no se puede ignorar.

6.7. Paquete ofimático. OpenOffice1.1.x [17]

Actualmente ya está disponible la ver-sión 2.0 que mejora las características demuchos puntos, aunque la implantacióninicial se realizó con la 1.1.x.

Ventajas

• Hay versiones multiplataformaque se pueden utilizar en Mi-crosoft Windows y GNU/Linux.

• El formato OpenDocument [9]permite que los documentosno están vinculados a ningunaaplicación propietaria.

• Su funcionalidad es muy si-milar a productos propietariosexistentes.

• Puede importar documentos deotros productos propietarios.

Inconvenientes

• Parecido pero no igual. Requie-re formación para el usuario fi-nal. Además los documentos detexto importados necesitan re-toques más o menos importan-tes. Esto puede convertirse enuna ventaja añadida al aprove-char la migración para normali-zar los diseños de los diferentesdepartamentos.

http://www.uca.es

ii

ii

ii

ii


• El módulo de BD en la ver-sión 1.1.x no implementa unSGDB. Esto se soluciona a par-tir de la versión 2.0, pero detodas formas se prefiere conec-tar el interfaz mediante ODBCal PostgreSql centralizado. Elproblema fundamental es quea la hora de importar sólo sepuede trabajar con los datos.El resto (formularios, informes)hay que recrearlo desde ce-ro. También podría ser consi-derado como una ventaja pa-ra promover una depuración delas aplicaciones y estructurasde datos creados por los usua-rios sin formación en Ingenie-ría del Software. De todas for-mas, los informes y los formu-larios avanzados requieren unamejora significativa en un futu-ro próximo.

6.8. GNU/Linux de escritorio

Surge el mismo problema de ’parecidopero no igual’ lo que impone la necesidadde formación. El diseño del escritorio de-ber ser ’bonito’ y fácil de usar, pero la usa-bilidad no debe entrar en conflicto con lasprestaciones o la comodidad. Tras analizarlas impresiones iniciales de los usuarios seconstató que el entorno aportado por Kdees mucho más agradable para estos usua-rios que el de Gnome.

6.8.1. Hardware a nivel de usuario

El usuario debe poder tratar con disque-teras, CDs y memorias USB. Kde responde

bastante bien en este sentido.

6.8.2. Tareas del administrador

Administración del hardware:

• Impresoras locales y en red(cups)

• Escaneres

• Dispositivos inalámbricos

Administración del software:

• Integración con OpenLdap [4]y Samba [3]

• Conexión via ODBC con elSGDB centralizado.

6.9. Fases de implantación

Formación en Guadalinex 2004 [20]y OpenOffice 1.1 [17]

Reemplazo de Internet Explorer, Out-look Express y Microsof Office porMozilla Firefox, Mozilla Thunderbirdy OpenOffice.

Instalación de GNU/Linux e inte-gración con el servidor de archivosy OpenLdap. Se realiza puesto porpuesto, primero con los equipos queno usan access ni otras aplicacionesespecíficas.

6.9.1. Escollos en la migración

Navegador de internet

http://osl.uca.es

ii

ii

ii

ii


• Se encuentran algunos sitiosdonde el diseño de las páginasno es compatible ya que estánbasado en etiquetas y opcionesno estandarizados.

Bases de datos de clientes

• Es necesario establecer un pro-tocolo de migración. Normali-zar la nomenclatura para loscampos, y estructuras de da-tos. También hay que normali-zar los tipos de datos.

• Al importar los datos en brutohay que tener en cuenta el jue-go de caracteres.

• Las consultas, formularios e in-formes deben ser creadas desdecero. Falta documentación paraformularios avanzados con ta-blas relacionadas y documentosvinculados y/o generados me-diante fusión.

En algunos puestos clientes existenaplicaciones propietarias específicaspara Microsoft Windows

• Banca electrónica• Diseño asistido por ordenador• Servicios Sociales

6.10. Distribución LinRoque [1]

GNU/Linux es un sistema operati-vo que combina el núcleo Linux conaplicaciones del proyecto Gnu

Debian [19] puede ser considera-da como la principal distribuciónGNU/Linux

Guadalinex 2004 [20]. Metadistroelaborada por la Junta de Andalu-cía y basada en Debian GNU/Linux.Tiene un mecanismo dual (Metadis-tros [21]) para ejecutarse en modoLive o instalarse en el equipo delusuario.

LinRoque es una personalización deGuadalinex 2004 con Kde como es-critorio por omisión, drivers wirelesspara algunos dispositivos USB, driverODBC para PostgreSql, soporte SATA,eliminación de los paquetes lúdicos yde software p2p y algunos otros cam-bios menores.

6.11. Otras ideas

Entre otros puntos interesantes a estu-diar a medio plazo citamos:

Aulas y sitios públicos

• Modo kiosko

• Clusters y clientes ligeros

Groupware

Mensajería instantánea (Jabber)

6.12. Consideraciones legales

Todo administrador de sistemas en la ad-ministración pública española debe teneren mente el marco legislativo vigente y enconcreto dos puntos fundamentales:

http://www.uca.es

ii

ii

ii

ii


Ley Orgánica de Protección de Datosde carácter personal (LOPD [22]). Lainformación debe estar perfectamen-te localizada y el acceso a ella de-be cumplir unos requisitos de segu-ridad.

Ley de Propiedad Intelectual(LPI [23]). No se puede tener nin-gún software sin licencia.

El proceso de migración e implantaciónes una gran oportunidad para realizar unaauditoría exhaustiva tanto de los datos sen-sibles a la LOPD como de los productosafectados por la LPI.

6.13. Conclusiones

El proyecto de implantar GNU/Linux enun entorno real de producción en la admi-nistración local no es una tarea imposiblepero, sobre todo a nivel de usuario final, seencuentran obstáculos que requieren unaimportante inversión en recursos humanospara la migración completa de la funciona-lidad. Durante bastante tiempo se manten-drán instalaciones parciales Microsoft Win-dows y GNU/Linux.

La Administración y Organismos Públi-cos deben apostar fuertemente en el desa-rrollo y promoción de aplicaciones con li-cencia GPL [3] que presenten alternativasa las aplicaciones propietarias y específicas.De igual forma toda administración públi-ca debería asegurarse que el diseño web desus portales sea independiente del navega-dor.

También son necesarias herramientasque faciliten la migración e importación de

las funcionalidades de bases de datos deAccess.

http://osl.uca.es

ii

ii

ii

ii


http://www.uca.es

ii

ii

ii

ii

Bibliografía

[1] Iniciativas del Ayuntamiento de SanRoque Información sobre las diver-sas medidas emprendidas para fo-mentar el uso del Software Libre,http://cpd.sanroque.es/SL/

[2] GPL Licencia para crear apli-caciones de Software Libre conlos cuatro grados de libertad.http://www.gnu.org/licenses/gpl.html

[3] Samba Sistema de archivosen red mediante protocolo CIFS.http://www.samba.org/

[4] OpenLdap Autenticación centralizadahttp://www.openldap.org/

[5] pGina Integración de la autentica-ción de Microsoft Windows con Ldap.http://pgina.xpasystems.com/

[6] PostgreSql Sistema Gestorde Base de Datos Relacional.http://www.postgresql.org

[7] Apache Uno de los servidoresweb más potentes disponibles.http://httpd.apache.org/

[8] Php 5 Lenguaje de programaciónorientado a la programación Web.http://www.php.net/

[9] Tomcat Componente independizadodel proyecto jakarta de Apache pa-ra ejecutar aplicaciones java via Web.http://tomcat.apache.org/

[10] Spring Framework Librerías ja-va interrelacionadas para facilitar eldesarrollo de aplicaciones siguien-do el paradigma MVC (Modelo-Vista-Controlador) y la inversiónde control (IoC). Posee un mó-dulo orientado al desarrollo web.http://www.springframework.org/

[11] Qmail Servidor smtp y pop3de gran seguridad y fiabilidad.http://www.qmail.org/

[12] Qmail-scanner Interceptor paraqmail que permite ejecutar unprograma por cada mensaje decorreo procesado. http://qmail-scanner.sourceforge.net/

[13] Netfilter / Iptables Herramientas delnúcleo para implementar cortafuegosrobustos. http://www.netfilter.org/

[14] Squid Proxy-caché para optimizarel rendimiento y filtrar direcciones.http://www.squid-cache.org/

[15] OpenVpn Aplicación para estable-cer redes privadas virtuales tanto des-de Microsoft Windows como desdeGNU/Linux. http://openvpn.net/

[16] Mozilla Sitio web de la organizaciónMozilla. http://www.mozilla.org/

http://cpd.sanroque.es/SL/

http://www.gnu.org/licenses/gpl.html

http://www.samba.org/

http://www.openldap.org/

http://pgina.xpasystems.com/

http://www.postgresql.org

http://httpd.apache.org/

http://www.php.net/

http://tomcat.apache.org/

http://www.springframework.org/

http://www.qmail.org/

http://qmail-scanner.sourceforge.net/

http://qmail-scanner.sourceforge.net/

http://www.netfilter.org/

http://www.squid-cache.org/

http://openvpn.net/

http://www.mozilla.org/

ii

ii

ii

ii


[17] OpenOffice Paquete ofi-mático altamante funcional.http://www.openoffice.org/

[18] OpenDocument Estándar de OASISpara especificar un formato públicobasado en XML de documentos ofi-máticos. http://tinyurl.com/qutk

[19] Debian Distribución GNU/Linux con-siderada paradigma del OpenSource.http://www.debian.org/

[20] Guadalinex 2004 MetaDistribu-ción basada en Debian y desarro-llada por la Junta de Andalucía.http://www.guadalinex.org/

[21] MetaDistros Proyecto español pa-ra la generación de distribucionesque pueden ejecutarse en modo Li-ve y/o instalarse en el disco duro.http://metadistros.hispalinux.org/

[22] LOPD Ley Orgánica 15/1999, de Pro-tección de Datos de Carácter Perso-nal. http://tinyurl.com/dsrye (pdf)

[23] Reforma del Código Penal Ley Orgá-nica 15/2003, de 25 de noviembre,que reforma el código penal y endu-rece las penas relacionadas con de-litos sobre la Propiedad Intelectual.http://tinyurl.com/dwfda

http://www.uca.es

http://www.openoffice.org/

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office

http://www.debian.org/

http://www.guadalinex.org/

http://metadistros.hispalinux.org/

http://www.csi.map.es/csi/pdf/ley_15_99.pdf

http://www.igsap.map.es/cia/dispo/27892.htm

ii

ii

ii

ii

7TOMAS3: Towards an Open Management Architecture for

Systems, Software and Services

TOMAS3: Hacia una arquitectura abierta para sistemas, software y servicios

Ismael Herrero Rodríguez [email protected]

María Isabel Martín

José Gato

Álvaro del Castillo

Rafael García Leiva

Ándago Ingeniería

Marta Patiño

Ricardo Jimenez-Peris

Álvaro Orús Cacho

José Antonio Sánchez

Universidad Politécnica de Madrid.

Resumen

En el presente documento se describeTOMAS3, un estándar de código abier-

to para el despliegue, instalación, confi-


mailto:

mailto:

mailto:

mailto:

mailto:

mailto:

mailto:

mailto:

ii

ii

ii

ii


guración, administración, monitorización ymantenimiento de medianas y grandes re-des de ordenadores bajo el sistema operati-vo GNU/Linux. Las herramientas descritaspermiten la total administración y opera-ción de una red de ordenadores reduciendosustancialmente los costes de operación.

7.1. Introducción

Ándago Ingeniería es una empresa delgrupo Talde dedicada a servicios de consul-toría que trabaja en proyectos de gran en-vergadura, utilizando para ello tecnologíasde Software Libre.

Recientemente Ándago Ingeniería ha de-cidido dotarse de un departamento de In-vestigación, Desarrollo e Innovación, quejunto con la colaboración de varias empre-sas privadas e instituciones universitariasinvestiga en nuevas tecnologías para avan-zar en el desarrollo del software y ofrecerproductos punteros y de valor añadido asus actuales y futuros clientes.

Uno de esos proyectos es la creaciónde un estándar y una solución completay abierta para la gestión efectiva de gran-des redes de ordenadores corriendo siste-mas operativos *nix, principalmente Linux.Se trata del proyecto TOMAS3: Towards AnOpen Management Arquitecture for Systems,Software and Services.

El proyecto TOMAS3 pretende fomentarel uso del software libre de dos formas: pri-mero integrando en su arquitectura solu-ciones de código abierto, aunque no limi-tándose a éstas, y segundo basando la ges-tión del proyecto en herramientas de desa-rrollo colaborativo que permiten una libre yefectiva diseminación del conocimiento ad-

quirido durante el desarrollo del proyecto atoda la comunidad.

Asimismo se pretende avanzar en el de-sarrollo de estándares utilizándolos para eldiseño de la arquitectura de TOMAS3, co-mo la modelización por medio de CIM [7]del DMTF [6] y la aplicación de serviciosweb via WSDM [8] de OASIS [9] entre va-rios otros estándares.

Además de ello la intención de Ándagorespecto a TOMAS3 es la de liberar el resul-tado del proyecto en el dominio público afin de implicar en su desarrollo a una co-munidad de desarrolladores y usuarios in-teresados en el mismo para su permanen-te soporte, extensión y mejora, haciendo elresultado del proyecto útil y duradero en eltiempo. Actualmente tanto las fuentes co-mo la documentación del proyecto son deacceso público, pero no está permitida sumodificación. El equipo de TOMAS3 preten-de presentar a la comunidad un proyectoterminado y utilizable antes de comenzarsu distribución.

TOMAS3 es un proyecto PROFIT [4] delMinisterio de industria, turismo y comercio[2] y del Ministerio de educación y ciencia[3].

Conjuntamente a Ándago están partici-pando en el desarrollo de TOMAS3 las si-guientes entidades:

el Centro de Referencia Linux [1] dela Universidad Autónoma de Madrid

el Laboratorio de Sistemas Distribui-dos [5] de la Universidad Politécnicade Madrid

que unen a los aportados por Ándago re-cursos de investigación. Algunas empresas

http://www.uca.es

ii

ii

ii

ii


privadas también han mostrado su interésen el proyecto.

En este artículo se presentan los requisi-tos establecidos por el equipo de TOMAS3

para ser cumplidos por la aplicación.Una red de ordenadores tipo cluster pue-

de contener una gran variedad de equipos,con distintas características hardware y confunciones muy dispares. Ejemplos de losequipos que podemos encontrar en este ti-po de redes son:

Servidores de ficheros.

Servidores de correo.

Nodos de cálculo donde se ejecutantrabajos.

Nodos maestro que coordinan el tra-bajo de dichos nodos.

Servidores de almacenamiento dedatos, como servidores de disco(NFS, AFS, GridFTP, etc.), o equiposde almacenamiento en cinta.

Servidores de instalación y reposito-rios de software.

Servidores de información, como porejemplo gestores de bases de datos.

Equipos de infraestructura de red, ta-les como servidores DNS o servidoresDHCP.

Otros muchos tipos de servidores, co-mo equipos de sincronización hora-ria, gestores de claves y credenciales,etc.

Gestionar una red de ordenadores de es-ta complejidad es una tarea ardua y difícil.El mantenimiento de la red no sólo implicala gestión de los componentes individuales(actualizaciones, parches, etc.), sino tam-bién la gestión de las interdependencias en-tre los distintos componentes, lo que exigeun orden preciso de las tareas a realizar. Porejemplo, parar un servidor NFS para man-tenimiento implica una modificación previade la configuración de todos los clientes pa-ra que utilicen un servidor alternativo. Estecaso tan trivial implica la necesidad de mo-delar las dependencias entre los distintoselementos de la red, en concreto, la depen-dencia entre los clientes y el servidor NFS.

También es importante que la ejecuciónde las tareas de administración tenga encuenta la integridad de los trabajos. Porejemplo, una operación de administraciónno debería abortar un trabajo o su entor-no de ejecución a menos que haya buenasrazones para ello (como por ejemplo unaemergencia debido a un incidente de segu-ridad).

Distribuir la configuración entre las má-quinas que componen una red también esun trabajo laborioso y delicado ya que pue-de ser diferente de una máquina a otra enun gran número de máquinas, y un mínimoerror en una de ellas puede suponer unagran degradación o incluso la caída de to-do el sistema. Por ello se hace necesario unsistema de gestión de la configuración quepermita llevar un control preciso del estadode cada máquina.

Otra función compleja de administraciónes la monitorización de los equipos de lared, que debe ofrecer la posibilidad de esco-ger las métricas necesarias para poder ob-tener conocimiento del estado de la red y a

http://osl.uca.es

ii

ii

ii

ii


su vez agrupar la información de varios or-denadores para tener una visión global delconjunto.

Una vez establecido un sistema fiable demonitorización también es deseable un sis-tema de alarmas que permitan la localiza-ción rápida de problemas, y más aún unsistema de tolerancia a fallos que permitaejecutar acciones que solucionen los pro-blemas localizados de forma automática.

Normalmente, estas complejas operacio-nes de administración se realizan de mane-ra manual, aunque se trata de procedimien-tos difíciles, caros, y muy propensos a erro-res, sobre todo en redes de gran tamaño.TOMAS3 viene a subsanar esta carencia.

Herramientas de Administración de Sistemas

Existen numerosas herramientas de ayu-da para la instalación, configuración y man-tenimiento de una red de ordenadores ba-jo Linux. En [15] podemos encontrar unacomparativa de las principales herramien-tas existentes, y en [16] un análisis más de-tallado de aquellas herramientas que hansido específicamente diseñadas para la ins-talación y gestión de clusters bajo Linux. Al-gunas de ellas son muy potentes pero noofrecen soluciones completas sino parcialespara las múltiples tareas de administracióndescritas. Otras son suficientemente gene-rales, pero son productos propietarios y ce-rrados que no permiten auditorías, amplia-ción ni mejoras de su código. Por todo elloes deseable una solución de código abierto.

Entre las herramientas de software libreque proporcionan soluciones integradas deadministración se encuentra Quattor [10].Quattor proporciona un sistema de confi-guración de las máquinas centralizado, un

repositorio de software común y un siste-ma de despliegue automático, cumpliendovarios de los requisitos especificados paraTOMAS3. Por ello el desarrollo de TOMAS3

partirá de los elementos proporcionadospor Quattor adaptandolos a las nuevas ne-cesidades y añadiéndole todo el resto defuncionalidades especificadas usando otrassoluciones.

7.2. Descripción General del SistemaTOMAS3

TOMAS3 es tanto una aplicación middle-ware para la administración de medianos ygrandes sistemas informáticos como la de-finición del conjunto de requisitos que esesistema de administración centralizada de-be cumplir. Además proporciona un frame-work para integrar las soluciones que ofrez-can las funcionalidades que cumplan di-chos requisitos.

Por tanto TOMAS3 no es una aplicaciónmonolítica sino una infraestructura dondese integran diversas soluciones. Además dedicho framework el proyecto TOMAS3 pro-porcionará un entorno completo que inte-grará un conjunto de soluciones selecciona-das y será perfectamente funcional.

La arquitectura global de TOMAS3 ofre-ce las siguientes funcionalidades:

configuración: gestión y almacena-miento centralizado de la informa-ción de configuración de los equiposde la red, incluye información sobreel hardware, configuración del siste-ma y configuración de las aplicacio-nes,

instalación: instalación inicial de losequipos, distribución e instalación de

http://www.uca.es

ii

ii

ii

ii


paquetes de software, y configura-ción y mantenimiento de los equiposde acuerdo a la información propor-cionada por el subsistema de confi-guración,

monitorización: recopilación, alma-cenamiento y consulta de la infor-mación sobre el estado actual de losequipos,

tolerancia a fallos: correlación dela información proporcionada por elsubsistema de monitorización conuna información patrón, y ejecuciónde acciones correctoras en caso deser necesario,

gestión de recursos: gestión de ladistribución de la carga entre los ele-mentos de computación de la red,proporcionando una capa de abstrac-ción sobre los gestores locales.

administración de servicios: Posibi-lidad de desplegar, arrancar, reiniciary parar servicios de forma controladay remota en una o múltiples máqui-nas simultáneamente.

administración de software: Con-trol del software desplegado en unao varias máquinas y la posibilidadde instalar o desinstalar software deforma remota llevando un inventariopreciso del software contenido en ca-da máquina.

administración de hardware: In-ventario preciso y actualizado de loscomponentes hardware de una red oun cluster.

administración de usuarios: Ges-tión de usuarios del sistema tanto pa-ra los sistemas administrados comopara los propios recursos de adminis-tración de TOMAS3

Consideraciones Generales de Diseño

Las características más importantes deldiseño de las herramientas de instalación yconfiguración de TOMAS3 son:

Se trata de un sistema no intrusivo,es decir, no se sustituye ninguno delos elementos de instalación y confi-guración de Linux, sino que éstos sonampliados.

Está diseñado para ser escalable, pu-diendo administrar desde redes depocos nodos hasta redes de decenasde miles. La optimización y distri-bución en el uso de los recursos esun pilar fundamental en el diseño deTOMAS3.

Es un sistema altamente modular,con unos interfaces entre módulosbien definidos, lo que facilita la susti-tución o actualización de módulos in-dividuales, y el desarrollo de nuevasversiones del sistema para distintasdistribuciones Linux, e incluso paraotras versiones de Unix.

Se reutilizan tantos componentes ex-ternos como ha sido posible, lo quefacilita el mantenimiento del softwa-re.

http://osl.uca.es

ii

ii

ii

ii


Estándares de facto de la industriason integrados y reutilizados en laarquitectura, por ejemplo, protocolosestándares como HTTP, servicios webSOA y formatos como XML, son utili-zados siempre que es posible.

Se ha optado por un diseño distribui-do donde la autonomía de los equi-pos de la red se mantiene tanto co-mo sea posible, existiendo instanciaslocales en los equipos cliente de casitodos los subsistemas, realizando lo-calmente todas las operaciones siem-pre que sea posible, asegurándose deesta manera la escalabilidad del sis-tema.

Se proporciona un conjunto de libre-rías de base para acceder a cada sub-sistema vía funciones de control, yuna librería de métodos comunes atodos los subsistemas.

Estado actual del proyecto

La primera versión utilizable de TOMAS3

está planificada para el 1 de junio de 2006.Actualmente las funcionalidades más de-sarrolladas son el sistema gestor de confi-guraciones y el de instalaciones, que com-prende la instalación manual o automáticade máquinas enteras y la instalación y ac-tualización de paquetes de software. Dadoque la incorporación de estas funcionalida-des está más avanzada éstas se explicaránen más detalle, mientras que el resto, debi-do a que podrían sufrir ligeras modificacio-nes en sus requisitos, se explican de formamás breve.

7.3. Sistema gestor de configuraciones

El Sistema Gestor de Configuraciones pro-porciona un entorno para la gestión de lainformación de configuración de los equi-pos de una red. Por información de con-figuración entendemos cualquiera de loselementos de información necesarios paraconfigurar de manera estática un equipo.No se incluye aquella información que esdinámica o que cambia, por ejemplo el con-tenido de una base de datos residente en elequipo, ni aquella información que es ge-nerada por la propia máquina, como porejemplo la carga del sistema.

El Sistema Gestor de Configuraciones secompone de los siguientes elementos (véa-se la Figura 7.1):

un servidor central donde se almace-nan todos los elementos de configu-ración de los equipos de la red, juntocon un lenguaje de alto nivel especí-ficamente diseñado para describir es-tos elementos de configuración,

un gestor local de configuraciones re-sidente en los equipos cliente, juntoa una librería que permite a las apli-caciones acceder a su información deconfiguración, y

un conjunto de módulos de acceso,que nos facilitan la consulta de la in-formación almacenada en el servidorcentral.

A continuación se describe cada uno de es-tos elementos.

http://www.uca.es

ii

ii

ii

ii


Figura 7.1: Sistema Gestor de Configuraciones

7.3.1. Servidor CDB

La información sobre la configuración delos equipos de la red se almacena de mane-ra centralizada en una base de datos llama-da CDB (del inglés Configuration DataBa-se). Los elementos de configuración de losclientes están organizados en esta base dedatos en forma de perfiles. Por cada equi-po cliente a instalar debe existir en el servi-dor CDB el correspondiente perfil que nosdescriba la configuración final deseada pa-ra el equipo. Los perfiles de configuraciónson escritos por el administrador de siste-mas utilizando para ello un nuevo lenguajellamado Pan, y a continuación son compila-dos a ficheros XML.

Pan (véanse [17] y [18]) es un lengua-je de alto nivel específicamente diseñadopara escribir perfiles de configuración. Pannos proporciona una vista de la informa-ción de configuración optimizada para rea-lizar tareas de alto nivel, tales como la ges-tión de un gran número de equipos clien-te. Por ejemplo, con Pan podemos agruparlos elementos de configuración comunes delos equipos de un mismo entorno de traba-

jo, describir la configuración de un deter-minado tipo de servicio, o caracterizar loselementos hardware de los clientes.

Los perfiles de configuración en formatoXML están optimizados para realizar opera-ciones de instalación y configuración de losequipos cliente, por lo que contienen sóloaquella información que es relevante paraestas tareas. Los perfiles XML, generados apartir de los correspondientes perfiles Pan,son descargados por el subsistema de confi-guración de los clientes (descrito en la sec-ción 7.3.2) para su propio uso. La informa-ción contenida en los perfiles XML es trans-formada por los clientes en información deconfiguración que pueda ser entendida porel sistema operativo y las aplicaciones, co-mo por ejemplo, en un fichero de configu-ración de sendmail /etc/sendmail.cf ,o en el fichero /etc/xinetd.conf .

CDB dispone de dos interfaces públicospara gestionar la información de configura-ción:

una interfaz de lectura/escritura pa-ra mantener la información de confi-guración expresada en lenguaje Pan,

http://osl.uca.es

ii

ii

ii

ii


que es accesible a través de una he-rramienta en línea de órdenes, o deuna interfaz gráfica, y

una interfaz de sólo lectura para quelos clientes recuperen su informaciónde configuración en forma de perfilesXML.

El servidor CDB no es sólo un lugar de al-macenamiento y gestión de perfiles de con-figuración, sino que además, también nosproporciona mecanismos para validar la in-formación introducida. CDB trabaja en mo-do transaccional: una vez que la validacióny la compilación han sido realizadas conéxito, los cambios introducidos por el usua-rio son almacenados en la base de datos,y publicados para que sean accesibles a losclientes.

7.3.2. Clientes CCM

El Gestor de Configuración de Clientes oCCM (del inglés Configuration Client Ma-nager) reside en cada uno de los clientesa configurar, y es el responsable del alma-cenamiento y la gestión de la informaciónde configuración del cliente.

Los clientes acceden a su información deconfiguración descargándose desde el ser-vidor CDB su perfil en formato XML. La co-municación entre el servidor y el cliente serealiza mediante un protocolo de distribu-ción de perfiles basado en HTTP. Una vezdescargado el perfil y almacenado local-mente, CCM ejecuta el Sistema Gestor deInstalaciones (descrito en la sección 7.4),que es el encargado de hacer efectiva lanueva configuración. El servidor CDB en-vía una notificación de actualización (basa-da en UDP) a los equipos cliente cada vez

que el administrador de sistemas modificasu perfil de configuración. Cuando se reci-be una notificación de actualización, CCMprocede a la descarga del perfil actualiza-do.

El Sistema Gestor de Instalaciones puedeacceder a los diferentes elementos de con-figuración del equipo cliente utilizando lalibrería NVA-API. Esta librería proporcionaun acceso fácil y transparente a la informa-ción contenida en los perfiles.

7.4. Sistema Gestor de Instalaciones

El Sistema Gestor de Instalaciones o IMS(del inglés Installation Management Subsys-tem) proporciona las herramientas necesa-rias para instalar y configurar el sistemaoperativo y las aplicaciones en los equiposde la red. IMS nos permite gestionar la ins-talación y la actualización del sistema ope-rativo y del software de aplicaciones, con-figurar correctamente los parámetros delsistema, y aplicar todas aquellas políticasy restricciones que hayamos definido paranuestra red.

En la figura 7.2 podemos ver un esque-ma simplificado de la arquitectura internade IMS. Básicamente, el sistema se compo-ne de los siguientes elementos:

un gestor de la configuración de losequipos cliente, que se encarga dehacer efectivos los perfiles de confi-guración definidos en CDB,

un repositorio de paquetes de softwa-re, que contiene todos los paquetesde software necesarios para instalarel sistema operativo y las aplicacio-nes,

http://www.uca.es

ii

ii

ii

ii


componentecomponente

componente

cdispd

ncd

http

nfs

ftp

APIPaquetes

Software

API

KickStart

Gestor

DHCP

Gestor

GestorPXE

PXE

DHCP

KickStart

Instalacion

Equipo Cliente

Repositorio de Software

Servidor de Instalaciones (AII)

SPM

Figura 7.2: Sistema Gestor de Instalaciones

un gestor y distribuidor de paquetesde software, encargado de descargardel repositorio software los paquetesa instalar, y de instalarlos en el equi-po, y

un conjunto de herramientas para lainstalación inicial y desatendida delos equipos.

Nótese que la configuración de los elemen-tos que forman IMS también es gestionadapor el Sistema Gestor de Configuraciones.A continuación se describen los elementosque forman IMS.

7.4.1. Configuración de los Equipos

El Sistema Gestor de la Configuración delos Equipos o NCM (del inglés Node Confi-

guration Manager) es el responsable de ha-cer efectiva en los equipos la informaciónde configuración proporcionada por CDB.NCM proporciona un entorno de trabajopara adaptar la configuración actual de unequipo a su configuración deseada, tal y co-mo está descrita en el perfil del equipo re-sidente en CDB.

NCM se basa en un conjunto de módu-los software responsables de configurar lo-calmente los servicios y las aplicaciones. Es-tos módulos, llamados componentes, son losencargados de mantener la correcta con-figuración de los equipos. Para ello acce-den a la información contenida en los per-files de configuración, utilizando la libre-ría NVA-API, y crean, borran o actualizanlos ficheros de configuración de los servi-cios y las aplicaciones locales. Cada com-ponente contiene el conocimiento necesa-

http://osl.uca.es

ii

ii

ii

ii


rio para trasladar la información contenidaen los perfiles, a la sintaxis específica de ca-da fichero de configuración. En caso de quela configuración del equipo se ajuste a ladescrita por su perfil, los componentes nomodifican ningún fichero. Los componen-tes también son responsables de notificara los servicios la existencia de cambios ensu configuración (por ejemplo, ejecutandola orden restart de un guión de inicio deSystem V).

Nótese que los componentes no se en-cargan de realizar tareas de administraciónrepetitivas, tales como limpiar el directorio/tmp , que han de ser realizadas medianteotras utilidades (por ejemplo con la herra-mienta tmpwatch ).

Los componentes pueden ser ejecutadosde múltiples maneras:

por un demonio local, cada vez quecambie alguno de los elementos deconfiguración que les afectan,

bajo demanda, por ejemplo manual-mente por el administrador del siste-ma, o mediante algún mecanismo deejecución remota, o

a intervalos regulares, por ejemploutilizando la herramienta cron .

Ejemplos de componentes son: un com-ponente que se encargue de gestionar laconfiguración del programa sendmail , uncomponente para gestionar todos los pa-rámetros de red (TCP/IP, DNS, etc.), o uncomponente para configurar el propio sis-tema NCM.

Además de los mencionados componen-tes, el sistema NCM incluye los siguienteselementos:

ncd : (del inglés Node ConfigurationDeployer) es el entorno de trabajo ba-jo el cual se ejecutan los componen-tes,

cdispd : (del inglés ConfigurationDispatch Daemon) está encargado demonitorizar los perfiles de configura-ción del equipo, y en caso de modifi-cación del perfil, ejecutar (vía ncd )aquellos componentes que se veanafectados,

librerías de soporte para componen-tes, proporcionan ayuda para las ta-reas de gestión rutinarias (informa-ción del sistema, interfaces a servi-cios del sistema, edición de ficheros),manejo de ficheros de registro, etc.

7.4.2. Distribución e Instalación de Paque-tes de Software

El Sistema Gestor de Paquetes de Softwa-re o SPM (del inglés Software Package Ma-nagement) es el responsable del almacena-miento y la gestión de los paquetes de soft-ware, así como de la distribución e instala-ción de los mismos en los equipos cliente.

El sistema SPM se compone de los si-guientes elementos:

un repositorio de software: donde sealmacenan todos los paquetes de soft-ware a instalar en los clientes, tantolos paquetes correspondientes al sis-tema operativo, como aquellos quecorrespondan al software de aplica-ción,

http://www.uca.es

ii

ii

ii

ii


un gestor avanzado de paquetes(rpmt ): una aplicación construidasobre la utilidad rpm, y que le aña-de la capacidad de realizar múlti-ples operaciones en múltiples paque-tes de software en una única transac-ción,

herramienta SPMA: (del inglés SPMAgent) encargada de calcular la lis-ta de operaciones de instalación, de-sinstalación o actualización de pa-quetes necesarias para actualizar elequipo,

componente SPM: integrado dentrodel sistema NCM, se encarga de con-figurar y ejecutar la herramienta SP-MA con la lista de paquetes a instalaren el equipo en base al contenido desu perfil,

procedimientos CDB: un conjuntode procedimientos del lenguaje Panpensados para facilitar la definicióny validación de listas de paquetes.

Todos los paquetes de software a instalar enlos equipos cliente son almacenados de ma-nera centralizada en un repositorio de soft-ware. Este repositorio cuenta con una in-terfaz de usuario para facilitar su gestión,permitiendo a los administradores del sis-tema añadir, borrar, y consultar los paque-tes disponibles. Los clientes pueden accederal contenido del repositorio utilizando losprotocolos HTTP o FTP, o también median-te algún sistema de ficheros compartidos,como por ejemplo NFS. Los clientes puedenincluso almacenar localmente los paquetesa instalar, asegurándonos de esta manera laescalabilidad del sistema.

La lista de paquetes que han de ser insta-lados en cada equipo viene dada por su per-fil de configuración. El componente SPM esel encargado de extraer esta lista de pa-quetes, con la ayuda de la librería NVA-API, y de crear un fichero de configuraciónlocal para la utilidad SPMA. A continua-ción, el componente SPM ejecuta la aplica-ción SPMA, que lee el fichero de configu-ración con los paquetes objetivo a instalaren el equipo, los compara con la lista depaquetes actualmente instalados, y calculalas operaciones de instalación, desinstala-ción o actualización necesarias para actua-lizar el equipo. Finalmente, SPMA ejecutala herramienta avanzada de instalación depaquetes rpmt , que se encarga de llevara cabo la transacción necesaria para hacerefectiva la nueva lista de paquetes.

La herramienta SPMA puede ser utiliza-da para instalar la totalidad de los paquetesde los equipos clientes, o sólo un subgrupode ellos, dependiendo si se trata de equipossobre los que tenemos un control total, o silo que se quiere es garantizar que los equi-pos disponen de un grupo de aplicacionesdeterminado.

7.4.3. Instalación Automática de Equipos

El Subsistema de Instalación Automáti-ca de Equipos o AII (del inglés Automa-ted Installation Infrastructure) proporcionaun conjunto de herramientas para la insta-lación inicial del sistema operativo en losequipos cliente. Esta primera instalación serealiza de manera automática y desatendi-da, a través de la propia red, y mediante eluso de servicios y herramientas estándarescomo son PXE, DHCP o TFTP.

Para poder llevar a cabo la instalación

http://osl.uca.es

ii

ii

ii

ii


inicial de un equipo de manera remota, hayque realizar previamente los siguientes pa-sos:

configurar los servicios de red ne-cesarios, como añadir las correspon-dientes entradas en el servidor DNSy en el servidor DHCP para cada unode los equipos a instalar,

configurar el programa cargador, losequipos descargan desde la red unprograma cargador o NBP (NetworkBootstrap Program), que basado enun fichero de configuración, decidirála manera de arrancar el equipo (des-de disco local, o iniciar la instalacióna través de la red), y

configurar el programa de instala-ción del sistema operativo: si el pro-grama NBP decide que hay que ini-ciar la instalación del sistema ope-rativo, el programa instalador nece-sita de un fichero que contenga to-dos los datos básicos de configura-ción del sistema, tales como el esque-ma de particiones, el software iniciala instalar, los detalles del hardware,etc.

AII proporciona las herramientas necesa-rias para simplificar las tareas descritas. Es-tas herramientas están totalmente integra-das con el sistema CDB, desde donde re-cuperan todos los datos de configuraciónque son necesarios, aunque también po-drían ser utilizadas de manera aislada.

El sistema AII se compone de los siguien-tes módulos:

aii-dhcp : que gestiona la parte deconfiguración del servidor DHCP pa-ra cada nodo (añadir, modificar o bo-rrar una entrada correspondiente aun nodo),

aii-nbp : encargado de gestionarla configuración de NBP para cadaequipo (arrancar desde disco local,o iniciar un proceso de re-instalaciónremota desde red), y

aii-osintall : que gestiona los fi-cheros de configuración del instala-dor del sistema operativo.

Mientras que para redes del orden de varioscentenares de equipos, los servicios involu-crados (DHCP, TFTP, instalador del sistemaoperativo) pueden ejecutarse en una únicamáquina sin que ésta se sobrecargue, en re-des de mayor tamaño es esencial que losequipos a instalar puedan ser particiona-dos, debido a problemas de escalabilidad.Por esta razón, es posible instalar los tresmódulos en máquinas diferentes. E incluso,para proporcionar redundancia al sistema,es también posible instalar el mismo módu-lo en más de una máquina (por ejemplo,tener dos servidores de DHCP, o tres de ins-talación del SO). La elección de qué servi-dores son utilizados por los clientes se rea-liza mediante los perfiles de configuraciónalmacenados en CDB.

7.4.4. Administración de servicios

El subsistema de administración de ser-vicios proporciona un conjunto de herra-mientas para la administración de los servi-cios ofrecidos por los nodos de la red. Des-de la consola de administración se podrá

http://www.uca.es

ii

ii

ii

ii


monitorizar el estado de un servicio, arran-carlo, pararlo, etc. El subsistema estará do-tado de una cierta inteligencia para resol-ver contingencias sencillas, como por ejem-plo las dependencias entre servicios, de for-ma que será capaz de arrancarlos o pararlosen un orden concreto si fuera necesario.

7.4.5. Administración de hardware

El sistema de administración de hardwa-re permite llevar un inventario actualizadodel hardware que constituye el sistema, tan-to a nivel de nodos como al de hardware in-cluido en esos nodos, así como de todos loselementos configurables susceptibles de serincluidos en el ámbito de administración deTOMAS3, que será el de aquellos ordena-dores donde corra el cliente de TOMAS3 ylos dispositivos que ofrezcan una interfazde administración WSDM.

El sistema de administración consiste enun repositorio de información sobre hard-ware y los servicios de almacenamiento yrecuperación de información que actúansobre ese repositorio. Además ofrecerá ser-vicios de información sobre hardware deforma que será posible crear perfiles conunos determinados requisitos de hardwareen función de su uso, y así consultar al sis-tema de administración de hardware si cier-tas máquinas cumplen con esos perfiles.

7.4.6. Monitorización y alarmas

El sistema de monitorización permite sa-ber en tiempo real el estado del sistema deforma visual. Permite agrupar la informa-ción de forma que se puede tener una vi-sión global de un conjunto de nodos o unaparticular y específica de uno solo de ellos.

Los grupos de nodos a monitorizar puedenser configurados por el usuario según la ar-quitectura que desee, así como las métricasque desee obtener. También se guardará unhistórico de los datos para poder realizarestudios estadísticos (datawarehouse).

Es posible determinar límites para lasmétricas monitorizadas de máquinas o gru-pos concretos y activar alarmas en base aéstos. Estas alarmas se visualizarán en laconsola de administración y se notificará aladministrador de diversas formas configu-rables.

7.4.7. Tolerancia a fallos

Utilizando el subsistema de monitoriza-ción y alarmas se podrán detectar proble-mas y se permitirá lanzar automáticamentey de forma desatendida procesos que solu-cionen los problemas detectados. Estas ac-ciones podrán ser tan sencillas como rea-rrancar un servicio o tan complejas comobalancear la carga de un servicio instalan-do desde cero una máquina, el software yla configuración necesaria y añadiéndolo alservicio. Estos procesos pueden ser deter-minados por el usuario.

7.4.8. Administración de usuarios

TOMAS3 proporcionará una interfaz pa-ra administrar de forma centralizada usua-rios tanto para los sistemas administradospor TOMAS3 como para la administraciónde sus propias funcionalidades. La principalnovedad aportada por el sistema de admi-nistración de usuarios de TOMAS3 es quese trata un punto único para múltiples clus-ters.

http://osl.uca.es

ii

ii

ii

ii


7.5. Conclusiones

La arquitectura de TOMAS3 definida porÁndago y el middleware resultante de im-plementarla permite incrementar significa-tivamente la automatización de las tareasde instalación y mantenimiento de una redde ordenadores Linux, simplificando las ta-reas de administración y por tanto, re-duciendo los costes. Además, el sistemaTOMAS3 permite mantener el control ab-soluto desde el punto de vista global delsistema y desde el particular de los nodosy la supervisión de las tareas resulta simpley rápida en las manos de un administradorde sistemas experto.

http://www.uca.es

ii

ii

ii

ii

Bibliografía

[1] Universidad autónoma de Madrid,http://150.244.56.228

[2] Ministerio de turismo, industria y co-mercio, http://www2.mityc.es

[3] Ministerios de educación y ciencia,http://www.mec.es

[4] Programa de Fomento de la in-vestigación Técnica (PROFIT)http://www2.mityc.es/Profit/Profit//Guia/Index.htm

[5] Universidad politécnica de Madrid,http://internetng.dit.upm.es

[6] Distributed Management Task Force,http://www.dtmf.org

[7] Common Information Model,http://www.dtmf.org/standards/cim

[8] Web Services Distributed Ma-nagement, http://www.oasis-open.org/commitees/tc_home.php?wg_abbrev=wsdm

[9] OASIS, http://www.oasis-open.org

[10] Quattor, http://www.quattor.org

[11] European Union DataGrid Project,http://www.eu-datagrid.org.

[12] Foster, Ian, The Grid: Blueprint fora New Computing Infrastructure,Morgan-Kaufmann, Julio 1998.

[13] CERN: European Organization for Nu-clear Research, http://www.cern.ch.

[14] EU DataGrid Fabric Managementworkpackage, http://hep-proj-grid-fabric.web.cern.ch/hep-proj-grid-fabric.

[15] Barroso, Maite, “WP4 Report on Cu-rrent Technology”, DataGrid Tech-nical Report DataGrid-04-TED-0101-3_0, Apr. 2001

[16] García Leiva, Rafael y Peso, José del,“Open Source Solutions for Installa-tion and Management of PC Clustersunder Linux for ATLAS”, ATLAS NotesATL-SOFT-2003-001, Oct. 2002.

[17] Cons, Lionel and Poznanski, Piotr,“Pan: A High-Level ConfigurationLanguage”, LISA Conference Procee-dings, 2002.

[18] Cons, Lionel and Poznanski, Piotr,“Pan Language Specification”, Data-Grid Technical Report DataGrid-04-TED-0153, Nov. 2002 ( http://hep-proj-grid-fabric-config.web.cern.ch/hep-proj-grid-fabric-config/pan-spec.pdf)

ii

ii

ii

ii


http://www.uca.es

ii

ii

ii

ii

Parte II

Proyectos fin de carrera

97

ii

ii

ii

ii

ii

ii

ii

ii

8Intérprete de diagramas de flujo.

Desarrollo en software libre

Ismael Moreno Caballero [email protected]

Escuela Superior de Ingeniería de Cádiz. Universidad de Cádiz.

Carlos Rioja del Río [email protected]

Depto. de Lenguajes y Sistemas Informáticos. Universidad de Cádiz.

Resumen

Presentamos aquí la realización de unProyecto Fin de Carrera desarrollado bajola idea de ayudar a futuros estudiantes delas titulaciones de informática en la EscuelaSuperior de Ingeniería.

Para este Intérprete de diagramas de flujo(en adelante FCI) se han utilizado diversasherramientas de software libre, que posibi-litan la comunicación y extensión a la co-munidad de la aplicación. Además, por sunaturaleza didáctica, pretende ayudar a losalumnos noveles en el aprendizaje de desa-rrollo de diagramas.

8.1. Introducción

Se requiere cierta destreza para apren-der a crear algoritmos bien diseñados y,sobre todo, que arrojen resultados correc-tos, por lo que toda buena metodología deaprendizaje contemplará un período don-de el alumno practicará la creación de es-tos, aumentando la complejidad progresi-vamente.

Un obstáculo es el hecho de que los al-goritmos necesitan ser traducidos a progra-mas que lo implementen, para poder sercomprobados en funcionamiento. Aprenderel primer lenguaje de programación y acos-tumbrarse a su sintaxis y normas grama-ticales llevará un determinado tiempo al



ii

ii

ii

ii


alumno, durante el cual solo podrá probarla corrección de sus algoritmos o bien usan-do métodos formales (en ocasiones, com-plejos) que requieren cierta destreza mate-mática, o bien tener siempre disponible untutor (o, simplemente, alguien con más ex-periencia), que sea quien realice las tareasde comprobación (con todos los problemasque el factor humano pueda implicar).

FCI pretende ser un entorno de compro-bación empírica de algoritmos, apta paraprogramadores noveles, donde el tiempode aprendizaje o adaptación a este sea mí-nimo.

FCI permite crear algoritmos de una ma-nera muy intuitiva y ejecutarlos, para po-der comprobar que, sea cual sea la entradaque reciban, arrojan los resultados desea-dos. En el caso de que no funcionen comose esperaba, o bien se quiera analizar dete-nidamente los pasos que realizan, puedenser ejecutados paso a paso y, por ende, de-purados, permitiendo además visualizar elvalor de las variables en cada instante de laejecución.

8.2. Interfaz Gráfica de Usuario

El modelado de la aplicación basado enel patrón de diseño MVC ha permitido se-parar la programación de la interfaz gráfi-ca de la generación de diagramas y su pro-cesado. Esta metodología está ampliamenteaceptada en la industria actual y ha servidode base de desarrollo para las aplicacionesmás usadas cotidianamente por el usuariomedio.

Con esto, la interfaz gráfica (GUI) aportaal usuario los mecanismos necesarios parala manipulación de los diagramas (tanto su

creación y edición como su compilación ydepurado).

No difiere demasiado de las interfaces dela gran mayoría de programas de diseñode diagramas (tales como Dia, Visio, Um-brello, etc), presentando menús con iconosgráficos de edición y, también, menús tex-tuales desplegables.

8.3. Características de los diagramas.

Un diagrama de FCI está formado por unconjunto de nodos, cuya interconexión de-fine el flujo de ejecución de estos que debeseguir el algoritmo.

Los nodos se clasifican según el tipo decometido al que han sido destinados, y sudibujo en la vista del diagrama está adap-tada al estándar ISO 5807.

Cada tipo de nodo es interpretado comouna instrucción atómica de alto nivel y quepuede equipararse a una línea de códigode cualquier lenguaje basado en el paradig-ma de la programación estructurada. Así,se dispone de nodos para definir variables,para realizar asignaciones a variables, paradefinir matrices, para evaluar el resultadobooleano de una expresión, para llamar aprocedimientos y para delimitar bloques decódigo.

8.4. Características del intérprete.

Se enumeran las características principa-les del intérprete que permite ejecutar losdiagramas y, de esta manera, comprobar lasdiferentes soluciones que devuelvan estos:

1. Ejecución sobre una máquina virtualinterna (los diagramas son traduci-dos a código de esta).

http://www.uca.es

ii

ii

ii

ii


2. Dos tipos genéricos de datos: Núme-rico (números reales) y Strings (ca-denas de texto).

3. Operadores aritméticos para expre-siones (incluyendo uno de potenciay otro de módulo), de comparación ylógicos.

4. Posibilidad de llamada a bloques denodos independientes al flujo princi-pal de ejecución.

5. Funciones internas para la realiza-ción de tareas muy frecuentes y queson difíciles de implementar con losdiagramas, con ejecución optimiza-da con respecto a las llamadas a blo-ques.

6. Evaluación de expresiones lógicaspor cortocircuito.

No es necesaria la especificación explíci-ta de variables locales (se definen automá-ticamente en una asignación).

Matrices multidimensionales con tama-ños que pueden ser definidos a partir deexpresiones aritméticas complejas.

Reconocimiento de identificadores case-sensitive (sensible a las mayúsculas).

8.5. Desarrollo del proyecto.

FCI es software libre (licenciado conGPLv2) desarrollado, íntegramente, usan-do herramientas libres.

Está programado eny compilado con el GNU Compiler Co-

llection (GCC). La interfaz gráfica se ha

creado con la biblioteca wxWidgets, licen-ciada con una pequeñísima variante de laLGPL.

En lo que respecta al apartado de traduc-ción de diagramas a código de máquina vir-tual, ha sido necesario el uso de Flex y Bi-son para poder traducir expresiones com-plejas.

La creación del software y las tareas deedición de documentos asociados ha sidobajo un entorno KDE y herramientas paraeste, como el entorno de desarrollo KDeve-lop, el editor de textos Kate y el IDE paraLATEX Kile.

En la actual versión, FCI se ejecuta ba-jo sistemas operativos GNU/Linux que pue-dan ejecutar un servidor de ventanas X-window y que tengan instalados la bi-blioteca GTK+. No obstante, al haber-se usado bibliotecas y herramientas trans-portables, puede prepararse este softwa-re para ser ejecutado bajo sistemas Win-dows 9x/NT/2000/XP realizando, presu-miblemente, una mínima cantidad de cam-bios en el código.

8.6. Muestras.

A continuación se presenta un par decapturas de pantalla del software en fun-cionamiento:

http://osl.uca.es

ii

ii

ii

ii


Figura 8.1: captura de pantalla del intérprete

Figura 8.2: captura con watch(vigía) de variables

http://www.uca.es

ii

ii

ii

ii

Bibliografía

[1] wxWidgetshttp://www.wxwidgets.org

[2] Bison http://www.bison.org

[3] Flex http://www.gnu.org/software/flex/

ii

ii

ii

ii


http://www.uca.es

ii

ii

ii

ii

9Plataforma libre de desarrollo de algoritmos para el

proyecto Pelican

y su interfaz basada en Web Services1

Adrián Santos [email protected]

Escuela Técnica Superior de Ingeniería Informática. Universidad deLa Laguna.

Francisco Almeida [email protected]

Depto. de Estadística, Investigación Operativa y Computación. Uni-versidad de La Laguna.

Vicente Blanco [email protected]

Depto. de Estadística, Investigación Operativa y Computación. Uni-versidad de La Laguna.

Resumen

Presentamos en este artículo el proyec-to de fin de carrera que estamos realizan-do para implementar una plataforma librede desarrollo y acceso a algoritmos del pro-

yecto Pelican. Describiremos brevemente eldiseño de la plataforma existente y justifi-caremos los objetivos del proyecto.

1Este trabajo ha sido parcialmente soportado por la EC (FEDER) y por el Ministerio de Educacióny Ciencia, (TIN2005-09037-C02-01).




ii

ii

ii

ii


9.1. Introducción

El presente proyecto se basa en el trabajoprevio realizado en Pelican (Pelican [1]). Elobjetivo del proyecto Pelican es desarrollaruna versión paralela integrada de la GSL(GNU Scientific Library, GSL [2]) que pue-da ser utilizada como un entorno para la re-solución de problemas relacionados con lacomputación numérica científica. En parti-cular, se pretende que dicha biblioteca seatransportable a varias arquitecturas parale-las, incluyendo procesadores con memoriacompartida y distribuida, sistemas híbridos(consistentes en una combinación de am-bos tipos de arquitecturas) y clusters de no-dos heterogéneos.

La Biblioteca Científica GNU está forma-da por cientos de rutinas para la realizaciónde cálculo numérico que abarcan aritméti-ca de números complejos, matrices y vec-tores, álgebra lineal, estadística y optimiza-ción, etc.

Nuestro proyecto consiste en ampliar Pe-lican dotándolo de una herramienta quepermita acceder, implementar y usar los al-goritmos ya disponibles y aquellos aporta-dos por la comunidad. Todo el código im-plementado se pondrá a disposición del pú-blico bajo una licencia libre.

9.2. Arquitectura software

El diseño de la biblioteca Pelican se ba-sa en una arquitectura software multinivel(ver Figura 9.1): cada capa ofrece ciertosservicios a las capas superiores a la vez queoculta cómo son implementados.

La capa en la que nos centraremos enel proyecto es la denominada Web Service.Consiste en un servicio web que permite ac-

ceder a las bibliotecas disponibles en Peli-can (ver Figura 9.2).

Los principales problemas a resolver du-rante el análisis y desarrollo del móduloson los siguientes:

Instalación: Dado la heterogeneidad delos sistemas en los que se planea ins-talar el servicio se debería dotar deun sistema de instalación indepen-diente de la plataforma.

Autenticación: Dado que el servicio per-mite acceder al sistema de cómputodonde sea instalado se ha de dotarde medidas de seguridad que contro-len el acceso al mismo.

Gestión de algoritmos: El problema máscomplejo viene dado por la necesi-dad de dotar al usuario de un mé-todo automático para añadir nuevosalgoritmos. El servicio web necesitauna descripción XML del algoritmopara conocer sus argumentos de en-trada y salida. Se ha desarrollar unsistema capaz de extraer estos datosdel código fuente, generar la descrip-ción y añadir las nuevas rutinas alservicio.

Ejecución: Al igual que en la instalación,se ha de proveer interfaces para elacceso a varios sistemas de colas. Porello es necesario desarrollar una li-brería de ejecución con unos méto-dos comunes (parte independientede la plataforma) y varios backendsdependientes de la máquina dondese vaya a ejecutar.

http://www.uca.es

ii

ii

ii

ii


Serial Interface

Homogeneous Heterogeneous

Distributed−memory Hybrid

OpenMP + MPI

Hybrid−memoryArchitectures

MPI

Distributed−memoryArchitectures

Serial User

GSL

Sequential

C/C++

Shared−memoryArchitectures

Parallel User A

Shared Memory

OpenMP

UserLevel

ProgrammingModel Level

Libraries +System Tools

PhysicalArchitecture

Level

Web Service

Parallel User B Serial User Parallel User C

Figura 9.1: Arquitectura software de la biblioteca paralela integrada para el cálculo numérico cientí-fico.

* availableJobs()* getJobDescription()* getJobStatus()* sortSerial()* sortDistributed()* sortShared()* availableJobs()* getJobDescription()* getJobStatus()* matrixProductSer()* matrixProductDist()* availableJobs()* getJobDescription()* getJobStatus()* rap()

* gsl_usmv()* gsl_dmdd_usmv()

* gsl_sort_vector()* gsl_dmdd_sort_vector()* gsl_sm_sort_vector()

* gsl_rap()

ServidoresClienteUsuarios

e-mail con el resultado del trabajo

* Trabajos disponibles* Ejecutar un trabajo* Obtener estado

Figura 9.2: Esquema genérico del funcionamiento del servicio web

9.3. Proyecto

Actualmente existe una versión prelimi-nar del proyecto desarrollada como prueba

de concepto. Se han propuesto solucionespara varios de los problemas planteados pe-ro no se ha obtenido una solución factibleal problema completo. En nuestro proyec-

http://osl.uca.es

ii

ii

ii

ii


to nos centraremos en aquellos puntos quehan quedado pendientes en el trabajo ac-tual. En definitiva, los objetivos marcadosson:

Implementación de una forja en laque alojar el proyecto.

Generalizar las descripciones XML delos algoritmos para que permitan es-tructuras de datos complejas en susargumentos.

Ampliar el número de algoritmos dis-ponibles.

Automatizar la instalación del servi-cio en las máquinas de cómputo.

Mejorar la interfaz web de acceso alas rutinas para permitir la adminis-tración de usuarios y la adición deservidores de cómputo.

http://www.uca.es

ii

ii

ii

ii

Bibliografía

[1] J. Aliaga, F. Almeida, J.M. Badia,S. Barrachina, V. Blanco, M. Casti-llo, U. Dorta, R. Mayo, G. Quintana,

C. Rodríguez, y F. Sande, “Paralleli-zation of GSL: Architecture, interfa-ces, and programming models,” inProc. of the 11th European PVM/MPIUsers’ Group Meeting in conjunc-tion with DAPSYS’04 (EuroPVM/MPI2004), Budapest, Hungary, Septem-ber 19–22 2004, vol. 3241 of LectureNotes in Computer Science, pp. 199–206.

[2] M. Galassi, J. Davies et al., GNU scien-tific library reference manual, July2002, for GSL Version 1.2.

ii

ii

ii

ii


http://www.uca.es

ii

ii

ii

ii

Parte III

Talleres

111

ii

ii

ii

ii

ii

ii

ii

ii

10Edición de audio digital con Audacity

Ignacio Palomo Duarte [email protected]

Escuela Superior de Ingeniería de Cádiz. Universidad de Cádiz.

Resumen

Este artículo pretende mostrar las diver-sas posibilidades que ofrece el programade edición de audio digital Audacity. Esteprograma facilita al usuario tareas comunescomo pueden ser la restauración de vinilos(eliminación de ruido, ecualización), utili-zación de Audacity como multipistas digi-tal o aplicación de efectos de audio. Au-dacity es un programa libre y de códigoabierto para grabar y editar sonidos, dispo-nible para Mac OS X, Microsoft Windows,GNU/LINUX y otros sistemas operativos.

10.1. Introducción

Hoy en día el audio digital forma par-te importante de nuestras vidas; ya sea enforma de música comprimida en MP3, pod-

casts, inserción de audio en vídeo digital oaplicaciones multimedia, el usuario de in-formática necesita llevar a cabo ese con-junto de tareas, pero sin el desembolso quepuede acarrear la compra de un programade edición de audio profesional.

A los usuarios informáticos se les exigeun conocimiento general de todas las posi-bilidades que ofrece la informática moder-na. Muchos usuarios poseen conocimientosde edición de texto, diseño gráfico, hojasde cálculo, presentaciones multimedia, pe-ro muy pocos saben cómo editar audio digi-tal, muy presente en nuestra sociedad gra-cias a la música en formato MP3, creaciónde contenidos multimedia o edición de ví-deo digital, por ejemplo.

Este artículo pretende informar sobre eluso y situaciones en las que debemos usarun editor de audio, tanto en aplicaciones


ii

ii

ii

ii


ofimáticas como a la hora de la edición ymasterización profesional de un tema musi-cal.

10.2. Edición de audio digital

Para ilustrar el funcionamiento y la uti-lidad de un editor de audio expondremosun par de ejemplos, uno de ellos aplicadoal campo del audio profesional y otro casosolventando el problema de la restauraciónde audio procedente de grabaciones de bajacalidad, correspondiente a las necesidadesde un usuario de informática común.

10.2.1. Primer caso: Composición y mezclade un tema comercial

Pensemos en un caso real en el que se re-quiera el uso de un editor de audio. Imagi-nemos, por ejemplo un estudio musical pro-fesional encargado de la elaboración de untema comercial. El primer paso sería utili-zar un secuenciador para componer la pie-za musical, utilizando diferentes elementoshardware o sintetizadores virtuales. Luegotendría lugar la grabación de las diferen-tes voces en un estudio de grabación. Eneste punto, usando un editor de audio secorregirían los pequeños defectos en las vo-ces, tales como sibilancia, compresión diná-mica, volumen, normalización o ajustes enfrecuencias.

Una vez tenemos tanto las voces como lamúsica unimos y mezclamos ambas partesen un multipistas digital (función que tam-bién cumpliría Audacity, como se muestraen la figura 10.1), ajustamos los volúmenesde cada canal y aplicamos pequeños reto-ques a los instrumentos por separado.

Por último, una vez hemos obtenido lapista de audio final, es el momento del más-tering. Usando un editor de audio anali-zamos el espectro de frecuencias del temay aplicamos diferentes efectos, ecualizacio-nes y técnicas para obtener un sonido finalmás compacto y mucho más equilibrado envolumen y frecuencias.

10.2.2. Segundo caso: necesidades de unusuario no profesional

Sea el caso de estudio un usuario de in-formática común. Supongamos que poseeun conjunto de vinilos, música en formatocassette o grabaciones de baja calidad, y legustaría digitalizar esa música para evitarun mayor deterioro de la misma con el pasodel tiempo y también para poder disponerde esa música en su reproductor de MP3.

Utilizando las capacidades de grabaciónde un editor de audio digitalizaría la se-ñal de su equipo de música, grabando, porejemplo, toda una cara del vinilo. Luegoaplicaría una reducción de ruido para lim-piar la señal y normalizaría el volumen. Pa-ra finalizar dividiría la toma de audio en di-ferentes archivos, cada uno correspondien-do a una canción del vinilo.

Por ejemplo, en la figura 10.2 vemos co-mo la forma de onda en la imagen de laderecha goza de un mayor rango dinámicoy un volumen más constante que la ondade la derecha, obteniendose un sonido másrico, cálido y agradable de escuchar.

10.3. Programa principal

Audacity es un editor de sonidos librepara Windows, Mac OS X, GNU/Linux, y

http://www.uca.es

ii

ii

ii

ii


Figura 10.1: Audacity trabajando en modo multipistas digital.

Figura 10.2: Audio antes y después del tratamiento con Audacity.

http://osl.uca.es

ii

ii

ii

ii


otros sistemas operativos. Funciona en mo-do gráfico y es muy fácil de usar. Este pro-grama presenta, como funciones principa-les:

Grabar sonidos en vivo.

Convertir cintas y grabaciones a so-nido digital o CD.

Editar Ogg Vorbis, MP3, WAV, archi-vos AIFF, AU, LOF. Importar MIDI yRAW.

Corta, copia, pega y mezcla sonidos.Puede trabajar con múltiples pistas.

Se puede eliminar ruido, normalizar,ecualizar, amplificar, cambiar veloci-dad, modificar tono...

Es posible programar cualquier efec-to musical y/o sonoro, mediante elpanel Nyquist, usando Xlisp

Una lista completa de las característicasde Audacity pueden ser leídas en [1].

10.4. Otros programas

Además de los editores de audio existennumerosas herramientas basadas en soft-ware libre relacionadas con el audio digital.Algunas de estas aplicaciones son:

Ardour edición de audio y grabación mul-tipistas. Se puede consulta su sitioweb en [2].

Pure Data entorno gráfico de programa-ción en tiempo real, diseñado parael procesamiento de sonido, vídeo ygráficos. Su web oficial es [3].

CheeseTracker secuenciador basado entrackers. Su página oficial es [4].

RoseGarden secuenciador profesional ba-sado en partituras. Más informaciónen [5].

ZynAddSubFX sintetizador virtual. Si sedesea información adicional se pue-de conultar [6].

Si se desea obtener información sobreotros programas complementarios se pue-de consultar [7].

10.5. Conclusiones

Como vemos, la edición de audio digi-tal hoy en día resulta sumamente sencilla.Hace unos años, poseer un equipo de edi-ción de audio, mezcla, masterización y apli-cación de efectos hubiera supuesto un de-sembolso disparatado, accesible sólo a unospocos bolsillos. Hoy, en cambio, cualquierusuario de un ordenador puede realizar to-das estas tareas con software libre, sien-do el único desembolso el equipo hardwareusado. Esto ha posiblitado el auge de loshome studios y capacitando a muchos com-positores a editar y masterizar ellos mismossus propios temas.

http://www.uca.es

ii

ii

ii

ii

Bibliografía

[1] Varios Página principal de Au-dacity. http://audacity.sourceforge.net/about/features

[2] Ardour. http://www.ardour.org/

[3] Pure Data. http://www.puredata.info/

[4] CheeseTracker. http://freshmeat.net/projects/cheesetracker/

[5] RoseGarden. http://www.rosegardenmusic.com/

[6] Zynaddsubfx. http://zynaddsubfx.sourceforge.net/

[7] Wikipedia software de audio libre.http://es.wikipedia.org/wiki/Software_de_audio_libre

http://audacity.sourceforge.net/about/features



http://www.ardour.org/

http://www.ardour.org/

http://www.puredata.info/

http://www.puredata.info/

http://freshmeat.net/projects/cheesetracker/



http://www.rosegardenmusic.com/

http://www.rosegardenmusic.com/

http://zynaddsubfx.sourceforge.net/



http://es.wikipedia.org/wiki/Software_de_audio_libre



ii

ii

ii

ii


http://www.uca.es

ii

ii

ii

ii

11Introducción a la creación y tratamiento de imágenes

digitales mediante Gimp

Ignacio Montoya García [email protected]

Oficina del Software libre de la Universidad de Cádiz

Juan Carlos Gonzalez Cerezo [email protected]

Oficina del Software libre de la Universidad de Cádiz

Resumen

Este artículo presenta Gimp, la herra-mienta de creación y tratamiento de imá-genes digitales más popular en la comuni-dad de software libre, realizando un reco-rrido rápido por algunas de sus opciones ymostrando algunas de sus capacidades másinteresantes.

11.1. Introducción

Gimp (GNU Imagen Manipulation Pro-gramm), tal y como podemos leer en su pá-gina web [1], es el programa de manipula-

ción de imágenes GNU [2]. Es un softwa-re libremente distribuido mediante licen-cia GPL [3] que sirve para llevar a cabotareas como retoque fotográfico, composi-ción de imágenes y creación de imágenesde autor. Los usos habituales de Gimp abar-can desde los propios de un programa sim-ple de dibujo o diseño gráfico digital a losde uno de retoque fotográfico profesional.También se puede usar como traductor deformatos gráficos, para crear imágenes ani-madas o incluso como un sistema automa-tizado de proceso y renderización de imá-genes.

Una de las principales bondades de Gimp



ii

ii

ii

ii


es que está portado libremente a multitudde plataformas y sistemas operativos. Lamayoría de las distribuciones GNU/Linuxde hecho incluyen Gimp como el editor grá-fico estandar.

11.2. La interfaz gráfica

Al contrario que en la mayoría de progra-mas de tratamiento de imágenes, la interfazde Gimp no consiste en una única ventanadentro de la cual se encuentran la imageny el acceso a los menús. Gimp usa ventanasindependientes para el gráfico que se va aeditar, el menú de herramientas y otros me-nús y paneles de control (ver figura 11.1).Se podría hacer una división de las venta-nas de Gimp en tres categorías principales;La ventana o caja de herramientas, la ven-tana en la cual se encuentra la imagen conla que se está trabajando y las denominadasventanas de diálogo.

El control básico se lleva a cabo normal-mente a través de la caja de herramientas,la cual permite el acceso rápido medianteiconos a tareas específicas. Por otro lado, elacceso al resto de herramientas se realiza,bien a través de la barra de herramientasubicada en la parte superior de la ventanade imagen, bien a través del menú contex-tual de la misma. Las ventanas de diálogopermiten el acceso a opciones de tratamien-to de la imagen específicas, como por ejem-plo canales, capas, caminos, colores, bro-chas, gradientes, modelos y paletas.

Una de las características más interesan-tes de la interfaz de Gimp es su capacidadde ser adaptada por el usuario a sus necesi-dades de forma muy sencilla. Por ejemplo,el usuario puede configurar la caja de he-rramientas principal añadiendo o quitando

las opciones que desee de la misma. Ade-más, aunque provee por defecto combina-ciones de teclas de acceso rápido para lamayoría de opciones y funciones, Gimp per-mite que el usuario pueda configurar a sugusto dichos accesos rápidos para cualquieropción o función del programa.

11.3. Formatos gráficos

El formato gráfico nativo de Gimp es XCF(.xcf); En dicho formato Gimp guarda todala información relativa a la imagen tantosobre las capas como sobre el resto de in-formación general de la imagen y específi-ca de Gimp. Por otro lado, Gimp es capazde trabajar sin problema en modo lecturao escritura con imágenes que estén en lamayoría de los formatos gráficos existentesmás comunes, tanto bitmap como vectoria-les: BMP, GIF, JPG, PCX, PNG, PS, TIF, TGA,XPM, DCM, ICO, PSD, PPM, SGI, RGB, etc.

11.4. Textos

El soporte de textos en Gimp se basa encómo maneja texto el sistema X Window[4]. Gimp tiene herramientas para inser-tar textos en las imágenes usando cualquierfuente instalada en el sistema. Una vez in-troducido el texto, éste sigue siendo edita-ble a través de las herramientas de manejode textos. Al introducir un texto en Gimpéste se trata como una nueva capa de laimagen sobre la cual estamos trabajando.De esta forma podremos aplicar sobre di-cha capa de texto cualquiera de los trata-mientos o efectos que deseemos.

De hecho, una de las principales aplica-ciones prácticas de Gimp es la creación de

http://www.uca.es

ii

ii

ii

ii


Figura 11.1: Interfaz gráfica de Gimp

logotipos. Mediante la introducción de tex-to y aplicando muy pocos efectos se pue-den conseguir llamativos logotipos de for-ma muy sencilla y rápida.

11.5. Color

Aunque el modo de color más recomen-dado para trabajar en una imagen digital esel modo RGB (ya que nos asegura imáge-nes con profundidad de color de 24 bits) altrabajar con una imagen en Gimp se puedehacer en base a tres modos de color: RGB,escala de grises y color indexado. En cual-quier momento de hecho tenemos la opciónde cambiar la imagen entre cualesquiera dedichos modos.

Las herramientas de trabajo con colorque ofrece Gimp son muchas y variadas. Al-gunas de las más representativas son las si-guientes:

Recolector de color: Nos permite adquirirel color de un píxel concreto para tra-

bajar con él.

Paletas de colores: Nos ofrecen distintasmaneras de seleccionar un color.Introduciendo el valor hexadecimalRGB del mismo, mediante valores detono, saturación y brillo o bien a tra-vés de alguna de las herramientas deselección visual.

Histograma: Analiza los píxeles de unaimagen y los interpreta de forma grá-fica, ofreciéndonos una amplia infor-mación sobre la calidad de la ima-gen.

Niveles: Mediante esta herramienta pode-mos reducir o aumentar las sombras,medios tonos y luces de la imageno de algunas zonas determinadas dela misma simplemente mediante unasimple pulsación de ratón.

Curvas: Esta es quizás la herramienta máspotente para trabajar sobre la colori-zación de una imagen ya que permite

http://osl.uca.es

ii

ii

ii

ii


afinar al máximo las modificacionesrealizadas sobre píxels concretos dela misma.

Corrección de color: Aquí se agrupan unaserie de herramientas como son elbalance de color, ajustes de brillo ycontraste, ajustes de tono y satura-ción, colorización, umbral de color yposterización.

11.6. Herramientas de selección

Se podría realizar una primera divisiónde las herramientas de selección que inclu-ye Gimp en dos grupos básicos:

Selección mediante dibujo de contornos:El usuario crea un contorno y selec-ciona después el interior o el exteriordel mismo.

Selección especificando píxeles representativos:El usuario decide una característicade selección del píxel y Gimp se en-carga de seleccionar todos aquellospíxeles que contengan dicha caracte-rística.

Aparte de las opciones habituales (comoson cortar, copiar, mover y pegar), sobrelas selecciones se pueden realizar práctica-mente todas las operaciones que se puedenllevar a cabo sobre la imagen total. Apartede eso, Gimp permite la adicción, substrac-ción e intersección de una o varias seleccio-nes entre sí.

11.7. Capas

Aunque Gimp es en principio una herra-mienta de manipulación de imágenes basa-

da en el píxel, en un nivel superior Gimp es-tá orientado al trabajo con capas. Las ven-tajas más importantes de manejar una ima-gen en diferentes capas son que podemosdesplazar ciertos elementos o figuras encualquier momento y aplicarles tratamien-tos gráficos de cualquier tipo sin afectar ala integridad del resto de la escena. Gimpsoporta todo tipo de operaciones sobre ca-pas: creación o borrado, cambio de orden yfusión de las mismas.

11.8. Extensiones

Quizás uno de los puntos fuertes deGimp sea su modularidad, la cual le pro-porciona capacidad de ampliación median-te extensiones. Existe una amplia base dedatos [5] donde podemos consultar y acce-der libremente a todas las extensiones exis-tentes, así como enviar aquellas que noso-tros creemos. Los dos tipos de extensionesmás comunes y usados en Gimp se puedenagrupar en filtros y Script-Fu.

11.8.1. Filtros

El origen de los filtros proviene de la fo-tografía convencional en la cual se añadíanlentes distintas a la cámara para conseguirefectos sobre la imagen. Gimp dispone demuchos tipos distintos de filtros digitalespara conseguir efectos sobre la imagen di-gital: desenfoque, ruido, distorsión, efectosartísticos y de renderizado o mapas de bitsson algunos de ellos.

http://www.uca.es

ii

ii

ii

ii


11.8.2. Script-Fu

Básicamente, los Script-Fu son automa-tizaciones de tareas para aplicar distintostratamientos y/o efectos sobre una imagen.Un Script-Fu puede consistir por ejemploen aplicar varios filtros sobre una imagenen un orden determinado. La instalaciónestándar de Gimp incorpora varios Script-Fu, aunque en cualquier momento se lepueden añadir nuevos Script-Fu. Cualquie-ra puede escribir nuevos Script-Fu en supropio lenguaje Schema [6] o bien en Perl[7] a través de los llamados scripts de Perl-Fu [8].

11.9. Conclusiones

Gimp es una de las aplicaciones de tra-tamiento de imágenes digitales más poten-tes que existen actualmente. Ofrece prác-ticamente las mismas funcionalidades quecualquier otra aplicación propietaria de tra-tamiento de imágenes digitales que poda-mos encontrar en el mercado con todas lasventajas añadidas innatas a un programacon licencia GPL [3].

Gimp cuenta con una importante comu-nidad de usuarios y desarrolladores [9] queofrece extensiones y soporte al programaen forma de tutoriales, artículos, listas decorreo, foros o libros como por ejemploGrokking the Gimp [10].

http://osl.uca.es

ii

ii

ii

ii


http://www.uca.es

ii

ii

ii

ii

Bibliografía

[1] Gimp: http://www.Gimp.org

[2] GNU: http://www.gnu.org

[3] GPL: http://www.gnu.org/copyleft/gpl.html

[4] Fundación X.Org: http://www.x.org/

[5] Extensiones para Gimp http://registry.Gimp.org/index.jsp

[6] Schema in Gimp http://www.Gimp.org/tutorials/Basic_Scheme/

[7] Perl http://www.perl.org

[8] Perl-Fu http://www.Gimp.org/tutorials/Basic_Perl/

[9] Grupo de usuarios de Gimp http://gug.sunsite.dk/

[10] Bunks, Carey: Grokking theGimp New Riders Publishing 2000,Open Publication License http://Gimp-savvy.com/BOOK/index.html?Grokking_the_Gimp.html

http://www.Gimp.org

http://www.gnu.org

http://www.gnu.org/copyleft/gpl.html

http://www.gnu.org/copyleft/gpl.html

http://www.x.org/

http://www.x.org/

http://registry.Gimp.org/index.jsp

http://registry.Gimp.org/index.jsp

http://www.Gimp.org/tutorials/Basic_Scheme/



http://www.perl.org

http://www.Gimp.org/tutorials/Basic_Perl/

http://www.Gimp.org/tutorials/Basic_Perl/

http://gug.sunsite.dk/

http://gug.sunsite.dk/

http://Gimp-savvy.com/BOOK/index.html?Grokking_the_Gimp.html



ii

ii

ii

ii


http://www.uca.es

ii

ii

ii

ii

12Creación de presentaciones en DVD con dvd-slideshow

Manuel Palomo Duarte [email protected]

Depto. de Lenguajes y Sistemas Informáticos. Universidad de Cádiz.

Resumen

Este artículo presenta las posibilidades queofrece el sistema operativo GNU/LINUX pa-ra crear DVDs con contenidos multime-dia haciendo uso de la herramienta dvd-slideshow.

12.1. Introducción

Hoy en día el DVD se ha hecho un hue-co en nuestra vida diaria. Existen reproduc-tores de DVDs (u ordenadores con capaci-dad de reproducirlos) en prácticamente to-dos los hogares y centros de enseñanza. In-cluso existen lectores portátiles que incor-poran una pantalla para poder visualizarlosen cualquier lugar.

Aparte de servir para visualizar pelícu-las, el DVD puede facilitar la labor de los

profesionales de la enseñanza, ya sea apo-yando la docencia presencial o como medioclave en la docencia a distancia.

Así pues, el objetivo de este artículo espresentar las bondades del sistema dvd-slideshow para crear DVDs fácilmente apartir de galerías de fotos así como presen-tar otras herramientas que puedan comple-mentarlo.

12.2. dvd-slideshow

El paquete dvd-slideshow incluye variosprogramas (todos ellos distribuidos bajo li-cencia GNU/GPL) que facilitan la creaciónde DVDs que muestren una sucesión de fo-tografías. Permite añadirle música o soni-do, así como efectos del tipo fadein, recortede fotografías, etc.

Su página principal está en [1], pero se


ii

ii

ii

ii


recomienda su descarga en paquete .deb o.rpm desde el servidor de freshmeat [2],pues el sistema tiene numerosas dependen-cias.

12.2.1. Programa principal

El programa principal se llama como elpaquete, dvd-slideshow. Es un script pro-gramado en bash que se invoca desde líneade órdenes.

Su entrada es un fichero de texto que in-dica los datos del DVD a generar: las fotosque se mostrarán, el orden de aparición, eltiempo de exposición en pantalla de cadauna, la música que sonará en cada momen-to, si aparecerán subtítulos (esta caracterís-tica es interesante para añadir informacióna las fotos o para facilitar la accesibilidad asordos), etc. Las fotos se aceptan en forma-to JPG o PNG, y el sonido en MP3.

Por ejemplo, para mostrar una serie defotos se puede usar el código mostrado enla figura 12.1 (basado en el ejemplo very-simple.txt de [1]): La salida del programason un par de carpetas con los ficheros devídeo y audio en formato MPEG2, prepara-das para ser grabadas en un DVD con algúnprograma como dvdauthor [3] (que fun-ciona desde línea de órdenes) o QDVDAut-hor [4] (su equivalente en modo gráfico).Además genera un fichero XML para crearposteriormente un menú para el DVD conel programa dvd-menu.

Para personalizar el comportamiento delprograma, cada usuario puede tener un fi-chero llamado .dvd-slideshowrc en su direc-torio de entrada que proporcione valorespor defecto para el programa.

12.2.2. Otros programas relacionados

El mismo paquete incluye algunos pro-gramas que extienden las posibilidades dedvd-slideshow, como dvd-menu que creaun menú para el DVD con de las in-dicaciones que genera dvd-slideshow. Odir2slideshow, que genera un fichero de en-trada para dvd-slideshow a partir de las fo-tos de un directorio determinado.

En el caso de que las fotos se tengan or-ganizadas en galerías digitales, los progra-mas gallery1-to-slideshow y jigl2slideshowgeneran un fichero de entrada para dvd-slideshow leyendo los datos de una gale-ría de fotos creada con el programa Galleryversión 1 o jigl.

Otro programa muy interesante es Sli-deshow Creator. Es una interfaz gráfica pa-ra crear o modificar ficheros de entradade dvd-slideshow, que permite visualizar enentorno X-Windows las fotos en concreto ysus parámetros. En la figura 12.2 se mues-tra una captura proporcionada por la webdel programa [5].

Por último pueden resultar de inte-rés, como herramientas auxiliares a dvd-slideshow, el programa de retoque fotográ-fico gimp, el programa de dibujo lineal xfig,la grabadora de micrófono krecord o lame,que codifica ficheros WAV (como los gene-rados por krecord) en formato MP3.

12.3. Alternativas

Existen otras alternativas para crear pre-sentaciones en otros formatos, que pue-den complementar en algunos casos a dvd-slideshow:

LaTeX Beamer Class Permite crear diapo-sitivas para mostrar en videoproyec-

http://www.uca.es

ii

ii

ii

ii


# Las líneas que comienzan# por almohadilla son comentarios

# Con "title" se escribe en pantalla# title:duración:descripción# La duración es en segundo.title:5:Ejemplo de presentación

# Cada foto necesita una línea. Formato:# fichero.jpg:duración:subtítulo# La duración es en segundos.# El subtítulo es opcional.foto1.jpg:4:Introducciónfoto2.jpg:8:Primerafase grafico008.jpg:7

Figura 12.1: Ejemplo de código para mostrar una serie de fotos

Figura 12.2: Programa Slideshow Creator en funcionamiento.

http://osl.uca.es

ii

ii

ii

ii


tor desde LATEX o LyX usando la cla-se Beamer. Automatiza la creación deíndices, barras de navegación, biblio-grafía y otras características de inte-rés. Si se desea más información sepuede consultar [6].

S5 Permite crear presentaciones conXHTML, CSS y Javascript. A partirde una misma entrada produce unaversión para presentaciones vía weby otra para imprimir. Los datos de en-trada se escriben usando un subcon-junto de XHTML, y el aspecto gráficose define con CSS. Su página prin-cipal ofrece información adicional yejemplos, [7].

RaccoonShow Es un programa que creauna presentación en MacromediaFlash leyendo los datos de un fiche-ro PDF y (opcionalmente) con músi-ca de un fichero en formato WAV. Supágina principal en Internet es [8].

Tpp Este programa lee la información deentrada de un fichero de texto y creauna presentación para mostrarla encualquier consola soportada por labiblioteca ncurses. Para obtener in-formación adicional se puede consul-tar [9].

12.4. Conclusiones

Dvd-slideshow facilita la creación deDVDs. Sus aplicaciones son muy diversas,desde la creación de DVDs personales concolecciones de fotos a creación de conteni-dos didácticos.

Al estar programado en un lenguaje deshell como bash es fácil interactuar con la

shell, abriendo un mundo de posibilidades.Además, su entrada es un fichero de textoplano, por lo que se puede automatizar lageneración de diversas secuencias.

Es un programa de muy reciente crea-ción (su primera versión apareció en 2003),pero con un crecimiento rápido. Constante-mente aparecen versiones que amplían suscapacidades así como extensiones para po-der conectarlo a otros programas.

http://www.uca.es

ii

ii

ii

ii

Bibliografía

[1] Dylewski, Scott. Páginaprincipal de dvd-slideshow.http://dvd-slideshow.sourceforge.net/

[2] Dylewski, Scott. Descarga de dvd-slideshow. http://freshmeat.net/projects/dvdslideshow/

[3] Smith, Scott. Página principal de dv-dauthor. http://dvdauthor.sf.net/

[4] Okan, Varol Página principal deqdvdauthor. http://qdvdauthor.sourceforge.net/

[5] Colnaghi, Marco. Página princi-pal de Slideshow Creator. http://slcreator.sourceforge.net/

[6] Tantau, Till. Página principal enInternet de la clase Beamer paraLATEX. http://latex-beamer.sourceforge.net/

[7] Meyer, Eric A. Página principalen Internet de S5. http://www.meyerweb.com/eric/tools/s5/

[8] Bacon, Jono. Página princi-pal en Internet de RaccoonShow.http://www.jonobacon.org/projects/raccoonshow/

[9] Krennmair, Andreas & Golde, Nico.Página principal en Internet de tpp.http://synflood.at/tpp.html

http://dvd-slideshow.sourceforge.net/

http://dvd-slideshow.sourceforge.net/

http://freshmeat.net/projects/dvdslideshow/

http://freshmeat.net/projects/dvdslideshow/

http://dvdauthor.sf.net/

http://dvdauthor.sf.net/

http://qdvdauthor.sourceforge.net/

http://qdvdauthor.sourceforge.net/

http://slcreator.sourceforge.net/

http://slcreator.sourceforge.net/

http://latex-beamer.sourceforge.net/

http://latex-beamer.sourceforge.net/

http://www.meyerweb.com/eric/tools/s5/

http://www.meyerweb.com/eric/tools/s5/

http://www.jonobacon.org/projects/raccoonshow/

http://www.jonobacon.org/projects/raccoonshow/

http://synflood.at/tpp.html

ii

ii

ii

ii


http://www.uca.es

ii

ii

ii

ii

Índice de Autores

Almeida, Francisco, 103

Blanco, Vicente, 103Brieba Sánchez, José, 15

Carmona Murillo, Javier Domingo, 43Castuera Toro, Montaña, 15

del Castillo, Álvaro, 80

Fernando Sánchez, Juan Fernando, 69

García Leiva, Rafael, 80Gato, José, 80Gazo Cervero, Alfonso, 43González Sánchez, José Luis, 43Gonzalez Cerezo, Juan Carlos, 117Gonzalez Sánchez, José Luis, 15

Hernández Fernández, José Julio, 5Herrero Rodríguez, Ismael, 80

Jimenez-Peris, Ricardo, 80

Martín, María Isabel, 80Martínez Bravo, Lorenzo, 43Meléndez Aganzo, Luis, 29Montoya García, Ignacio, 117Moreno Caballero, Ismael, 99

Orús Cacho, Álvaro, 80

Palomo Duarte, Ignacio, 113Palomo Duarte, Manuel, 125

Paramio Danta, Carlos Alberto, 57Patiño, Marta, 80

Rioja del Río, Carlos, 99Ruiz Arahal, Manuel, 5

Sánchez Monedero, Javier, 29Sánchez, José Antonio, 80Santos, Adrián, 103

Ventura Soto, Sebastián, 29

Actas de las III Jornadas de Software Libre de la ...

Documents

Transcript of Actas de las III Jornadas de Software Libre de la ...