Instalación y administración de aulas informáticas
basadas en LiNUX

Ponente:

• Administrador de Sistemas en el Centro de Cálculo del Departamento de Ingeniería Telemática de la ETSI de Telecomunicación de la Universidad Politécnica de Madrid
• Ex-coordinador del Proyecto X-Mame
• Colaborador en la revista "Linux Actual"

Copyright. Licencia de uso

• Su distribución mediante medios electrónicos es libre, siempre y cuando se conserve el texto íntegro y en su formato HTML original, haciendo especial mención a la conservación del mensaje de copyright
• El autor y dueño del copyright cede los derechos de publicación impresa a Prensa Técnica S.L., autorizando a ésta a realizar las modificaciones al texto que considere oportunas para su publicación
• La distribución o copia, total o parcial, en cualquier medio impreso por parte ajena a Prensa Técnica S.L. Está expresamente prohibida
• La publicación en Web, o por cualquier otro medio electrónico de este documento está autorizada siempre y cuando se respeten los términos anteriores

Problemática de un aula informática

• Acceso semi-público. Seguridad
• Número de puestos
• Control y gestión de cuentas
• Administración
• Instalación y actualización
• Firewalling y control de acceso
• No uniformidad del equipamiento

• Administración centralizada
• Acceso a servidores de información
• Gestión de cuentas y correo electrónico
• Flexibilidad

• Arranque remoto
• Red de gestión
• Organización de los servidores
• Configuraciones
  • Auto-reparación
  • Re-instalación automatica
• Ventajas e inconvenientes
  • Fiabilidad
  • Tolerancia a fallos
  • Rendimiento

• Organización física
• Organización lógica
• Arranque e instalación de equipos
• Gestión y Administración
• Detalles específicos
• "Trucos" y consejos

• Windows95 en aulas informáticas
• Documentación y estadísticas
• Configuraciones "bajo demanda"
• Aplicaciones en CyberCafés
• Puntos de información de uso público basados en Linux

Referencias. Transparencias de la ponencia

En esta conferencia se analiza la problemática inherente a dichas aulas informáticas, se exponen diversas soluciones, con sus pros y contras, y se describe la solución Linux que actualmente es utilizada en los Laboratorios Docentes del Departamento de Ingeniería de Sistemas Telemáticos de la E.T.S.I. Telecomunicacíon de la Universidad Politécnica de Madrid, dando servicio centralizado a dos aulas informáticas con más de 100 puestos y cerca de 1800 usuarios

Cuando el administrador se efrenta a la tarea de mantener en correcto funcionamiento un conjunto de PC's y tenerlos permanentemente actualizados, y "listos para funcionar", debido a estas "diferencias", el coste no crece linealmente, sino que se dispara: un simple PC desconfigurado puede hacer perder todo un día de trabajo.

Si además de ello, añadimos el hecho de que el PC no sea para uso personal, sino compartido por una comunidad heterogénea de usuarios, el mantenimiento puede llegar a ser una auténtica pesadilla para el administrador.

Esta situación no es en absoluto extraña: laboratorios docentes, cibercafés, salas de diseño arquitectonico... son entornos que se caracterizan por:

• Redes de 20 o más ordenadores que deben dar un servicio idéntico
• Grupo heterogéneo de usuarios, cada uno con sus necesidades y metodologías de trabajo
• Entorno "inseguro" en el sentido de que la gente que use el ordenador no tiene por qué tener experiencia en administración, o peor aún, gente con espíritu de "cracker"

• Software -o sistema operativo- intrínsecamente inseguro o inestable
• Problemas de localización geográfica: tal es el caso de aulas distribuídas en varios edificios, o el de los Puntos de Información Cultural
• Requerimientos de actualización de software
• Necesidad de gestión centralizada
• Necesidad de sistemas de respaldo y backup
• Necesidad de afrontar fallos de hardware, bien por uso, o bien intencionados ( robos, roturas, etc )
• Poder hacer frente a cambios en la disposición, y configuración del parque informático instalado
• Seguridad: gestión de firewalling, routing. Establecimiento de filtros. Logging. Gestión y elaboración de estadísticas. Control de accesos
• Mantenimiento y gestión de servidores de información para la red: Servicios de acceso a InterNet, correo, ftp, news. etc

En resumen, el administrador se enfrenta a la ingrata tarea de mantener un parque informático heterogéneo, con múltiples usuarios y en un entorno "hostil" e inseguro, sobre el que no siempre puede tener control directo.

• Que el ordenador solo esté inactivo en caso de fallo hardware
• Que no haya que personarse en el puesto para resolver tareas software
• Que exista un protocolo de administración centralizada
• Escalabilidad: la solución debe ser independiente del número de puestos o bien, poder ampliarse de forma sencilla sin mas que añadir recursos en paralelo con los existentes
• Independencia ante la diversidad de hardware: Actualizar equipos no debe implicar reinstalar el sistema
• Seguridad: ante errores software o incluso ataques, el sistema debe poder ser recuperado sin intervención directa en la máquina
• Tolerancia a fallos: debe haber sistemas redundantes que ante el fallo hardware de un equipo permitan que la red siga en pie
• Seguridad hardware: es frecuente el robo de componentes , teclados ratones, etc, lo que obliga a unas mínimas, y por otro lado elementales normas de vigilancia y seguridad.

Antes que nada, es necesario decir que el "100% seguro" es imposible: mientras el usuario tenga posibilidad de tomar control del ordenador, lo que con sistemas por todos nosotros conocidos es tarea de "primero de cracker", no hay solución posible a dicho problema. Lo que nosotros pretendemos es que a pesar de estos ataques, el PC pueda volver a estar operativo sin más que el usuario siguiente haga otra cosa que apagar y encender el ordenador

Pero no solo debemos pensar del lado del administrador. Nuestra aula debe ser capaz sobre todo de atender a las necesidades y requerimientos del usuario, que es al fin y al cabo el destinatario de nuestro trabajo. Debemos pues

• Ofrecer un entorno funcional
• Dar posibilidad de actualización del software y de los recursos de que dispone el usuario
• Ofrecer servicios adicionales: Acceso a la Red, correo electrónico, servicios de información

• Gestión y control de cuentas, passwords, etc
• Gestión de los servicios que el aula ofrezca: web, correo, etc
• Actualización centralizada de software
• Elaboración de estadísticas e informes
• Diversas gestiones administrativas: reservas de puestos, gestión de recursos humanos, etc

El primer paso consiste pues, en el control del arranque del sistema. No podemos darle al usuario libertad, pues basta con que éste se haga con el control del arranque para tener bajo control dicho ordenador. Es más: no podemos simplemente confiar en deshabilitar el arranque desde disquetera, pues fácilmente el contenido del disco duro puede estar corrompido, o plagado de virus informáticos, o no responder en absoluto a lo que el administrador -e incluso el usuario- desean. Se impone un arranque controlado y que dependa enteramente de lo que el administrador haya dispuesto.

Las soluciones evidentes son:

• Arranques basados en Disco-ROM, bien mediante tarjeta, bien mediante CD-Rom. Son altamente seguros y fiables, pero tienen el inconveniente de que su actualización no es sencilla, y obliga a que el gestor se dé un "paseo" puesto por puesto para actualizarlo, e incluso tenga que invertir un tiempo precioso en abrir cada ordenador
• Arranques basados en red local. Mucho más sencillo. la actualización es automática y permiten mayor flexibilidad. Inconvenientes: el primero, la dependencia del sistema respecto de la red -lo que hoy en día no es un problema sino una neceisdad- ; y segundo y más serio: debido a la diversidad del hardware y al rápido avance de éste, hay que proveer un a ROM de arranque remoto específica para para cada tipo de tarjeta, con su proceso de prueba, grabación, etc. Realmente esto corresponde a los costes de puesta en marcha, pues una vez conseguido esto, la solución es "permanente"
• Algunas empresas vendedoras de sistemas operativos ofrecen soluciones de arranque centralizado y actualización distribuída que pecan de un detalle fundamental: esperan que el contenido del disco duro permita un mínimo arranque del sistema. Como la experiencia nos ha demostrado, ésta no es una concepción realista, y además no da protección contra ataques de virus y cambios de configuración del sistema de arranque. No se puede dejar el correcto funcionamiento de un aula informática a la buena voluntad de los usuarios

• Esconder las diferencias de hardware entre los puestos
• Garantizar que el contenido e información disponible sea uniforme
• Permitir una rápida actualización en caso de que haya habido un "desastre" en la sesión anterior

Para actualizar la información, se suele acudir a procedimientos de carga remota del software. Dependiendo del centro y de los recursos esta actualización será más o menos centralizada y/o automática.

Un recurso habitual para conseguir una rápida actualización es el no actualizar en absoluto: las aplicaciones se toman de un servidor de red. Debemos en este caso proporcionar un entorno de red seguro y fiable, con sistemas redundantes y que permita una reconfiguración "on line", para no perder servicio.

En toda esta descripción hemos focalizado el tema desde el lado del puesto de trabajo. ahora toca plantearse el lado del administrador. Toda aula informática debe tener:

• Un puesto de control, desde donde se pueda monitorizar y administrar el aula
• Uno o varios equipos proveedores de servicios:
  • Cuentas
  • Impresoras
  • Correo electrónico
  • Servicios de información ( Web, ftp )
• Uno o varios servidores de aplicaciones
• Un router/firewall
• Un servidor "maestro"
• Sistemas de backup y respaldo

La solución común es dividir el aula informática en dos subredes

• La red de explotación, donde se instalan los equipos y trabajan los usuarios
• La red de gestión en la que normalmente trabajan los administradores

• Proveer sistemas de auto-configuración de red de los puestos: bootp dhcpd, DNS, etc
• Proveer programas de distribución de información volatil: passwords y autentificación de usuarios, características hardware de equipos listas de correo, etc

Este enfoque tiene algunas limitaciones:

• El rendimiento. Con sistemas operativos de todos conocidos es difícil que un servidor pueda proporcionar recursos simultaneos a más de veinte puestos. Es preciso que se puedan poner servidores en paralelo y que puedan intercambiarse las funciones de estos "al vuelo"
• Las propias limitaciones de la red local: Empíricamente se comprueba el el momento de mayor carga de la red se produce en los cambios de turno, cuando prácticamente todos los equipos re-arracan a la vez. Se hace preciso un cuidadoso estudio de la topología de la red y de su rendimiento
• Fiabilidad. El concentrar algunos servicios en un solo equipo puede dar lugar a que, en caso de caída del servidor, el servicio se interrumpa. Será necesario proveer al sistema de monitores que disparen alarmas ante cualquier fallo de uno de los servicios críticos
• A pesar de todo, es necesaria siempre una vigilancia física del aula de trabajo, así como sistemas de seguimiento y "logging" de eventos. En el momento que el número de puestos sea elevado, el tratamiento de toda esta avalancha de información puede llevar a ocupar la mayor parte del tiempo del administrador

• Dos aulas informáticas, en sendos edificios, con una capacidad total para 150 puestos de trabajo
• Unos 1800 alumnos de las diferentes asignaturas impartidas en el Departamento, que necesitan de los servicios de dichos laboratorios
• Un plantel de 6 personas de personal de administración y servicios divididas en 2 administrativos, dos técnicos hardware y dos técnicos software. Además dichas personas deben simultanear sus tareas en el laboratorio con la gestión y administración del Centro de Cálculo del Departamento
• Ciertas Asignaturas necesitan recursos especiales en el tema de seguridad: para diversas prácticas se utilizan analizadores de protocolo, sniffers, etc que comprometen seriamente la seguridad y el funcionamiento "políticamente correcto" de los sistemas
• Un servidor web y un sistema de correo que deben ser altamente eficientes y seguros, pues es el método utilizado tanto por profesores como por alumnos para el envío de prácticas, información etc
• Un sistema de gestión de accounting distribuído, que permite
  • Bloqueos selectivos de cuentas
  • Cambios y actualizaciones de los passwords
  • Elaboración automática de listas de correo
  • Gestión de logs y estadísticas
• Una separación física de las redes de explotación y gestión del resto de las redes del Departamento, lo que garantiza la seguridad, y la respuesta ante fallos de conectividad

A la hora de plantearnos la instalación y gestión de los laboratorios Los criterios de diseño fueron:

• El objetivo fundamental es la realización de prácticas docentes, debiendo todos los restantes servicios, estar supeditados a este
• Seguridad: debe en caso necesario poderse aislar completamente el laboratorio del resto de la red. Debe garantizarse asímismo que la red de gestión es segura, aunque no lo sea -y de hecho no lo es- la red de explotación
• Fiabilidad: se debe garantizar que los equipos sean capaces de arrancar incluso si alguno de los servidores falla. Para ello se ha diseñado una bateria de servidores de aplicaciones en paralelo, de manera que pueden asumir fácilmente las funciones uno de cada otro, en caso de caída
• Rendimiento: Se ha diseñado un cableado físico que asegura que la red no va a limitar la velocidad de respuesta. Asímismo, los servidores en activo tienen un sistema de reparto de carga que asegura que no habrá sistemas sobrecargados
• El mantenimiento y la actualización se debe poder realizar directamente desde el Centro de Cálculo, sin necesidad de acceder físicamente a los puestos
• Las tareas administrativas deben poder ser realizadas por el personal de secretaría sin que en ningun momento se comprometa la seguridad o estabilidad del sistema
• El coste de mantenimiento debe ser solo el referido al apartado de reposición del hardware estropeado. No es significativo el coste de puesta en marcha, que se realiza durante los periodos no lectivos
• Debe permitirse un cierto nivel de acceso de los alumnos a los recursos: dispositivos como disqueteras y CD-Roms deben estar disponibles para que los alumnos puedan realizar las prácticas de laboratorio en su casa
• Un último criterio: nos enfrentamos a 1800 alumnos de informática y telecomunicaciones, que son espoleados por sus profesores a investigar, y para quienes la informática es casi una pasión. Casi todos ellos tienen ordenador personal en su casa. Muchos de ellos son asiduos lectores de grupos de noticias relacionados con la seguridad, los virus informáticos y las técnicas de "hackering". Se trata de no verlos como "enemigos", sino de ser capaces de encauzar dichas tendencias en el laboratorio de una forma constructiva y provechosa para todos

Rápidamente se ha hecho evidente que no podemos basarnos en sistemas Windows o MS-Dos para hacer frente a mas de 100 puestos docentes: su alta dependencia de un disco duro para el arranque hacen al PC vulnerable a la etapa más crítica: la de quien toma el control en el arranque. Del mismo modo soluciones tipo "Zero Admin Kit" de Microsoft, tampoco tienen cabida si pensamos que ni siquiera puede haber garantía de que el ordenador arranque.

Por ello desde hace bastantes años se utilizan tecnicas de arranque desde red local. Diversos proyectos de fin de carrera desarrollados por personal que ahora trabaja en el departamento, nos resolvieron los temas de instalar MS-Dos en estaciones que arrancaban de red. Con la evolución de la informática se ha pasado a otros sistemas operativos, pero al fin y al cabo la solución inicial sigue siendo ésta.

La solución Linux no es evidente a primera vista:

• Linux necesita de un root file system o de un swap. En caso contrario debemos proveer a cada puesto de suficiente memoria
• No podemos utilizar soluciones tipo XDM: cuando se tiene tal numero de puestos, es necesario una inversión demasiado costosa en los servidores. Aparte de ello hay un problema inherente de seguridad: los alumnos tendrían acceso a los servidores y a sus recursos
• Queremos que cada puesto sea autónomo: en caso de fallo de uno o más servidores, deben ser capaces de dar una funcionalidad mínima.
• No resuelve de forma sencilla el problema de las diferentes configuraciones hardware

¿Cuál es la solución?

La idea es hacer un arranque por etapas, que desde una pequeña imagen traída por TFTP sea capaz de regenerar un sistema completo en un tiempo aceptable ( más de tres minutos en arranque no se considera satisfactorio cuando los alumnos solo disponen de turnos de trabajo de dos horas )

El proceso de arranque es el siguiente:

• Mediante BOOTP cada tarjeta resuelve su configuración y carga por tftp una imagen
• Dicha imagen contiene un kernel mínimo y un RamDisk que contiene las instrucciones iniciales de carga
• La imagen inicial hace lo siguiente:
  • Prueba los sucesivos módulos de red hasta dar con el apropiado
  • Formatea y reparticiona el disco duro local, ignorando el contenido anterior y creando dos particiones: una que será el futuro root file system y otra de swap. Cada partición tiene aproximadamente unos 64 Mbytes
  • Monta por NFS un filesystem auxiliar, del que extrae una imagen comprimida con la que recompone el root filesystem en el disco duro. Dicha imagen ocupa unos 10 Mbytes, y se descomprime en el cliente para optimizar tráfico de red
  • Desmonta y libera los recursos e imágenes, Dando entonces control al disco duro local

El resto del arranque corresponde al de un Linux normal, con las siguientes salvedades:

• La red se configura mediante Bootp. Todos los servidores de aplicaciones están preparados para responder a dicha petición
• El /home y el /var/spool/mail se montan vía NFS por auto-mount en función del usuario que hace login
• El /usr se monta en read-only por NFS desde uno de los varios servidores de aplicaciones. Se utiliza un método muy simple pero eficiente para proceder al reparto de carga: se monta el /usr de aquel servidor que nos ha respondido al bootp
• Cada puesto arranca unos servicios mínimos: se han deshabilitado la mayor parte de las funcionalidades del inetd.conf
• Expresamente nos decidimos en contra del uso de páginas amarillas. Son demasiado inseguras y atan al puesto a la necesidad de que haya un servidor que responda. En su lugar un sistema de gestión remota actualiza todos los ficheros relacionados con el accounting
• La configuración de elementos dependientes del hardware se deja para la fase final: en uno de los directorios montados por NFS se consulta una database que contiene informacion sobre:
  • El tipo de ratón
  • El tipo de tarjeta gráfica y monitor
  En base a ellos se construyen los enlaces apropiados y se configuran las aplicaciones dependientes de hardware: las X-Windows, la SVGALib, y el DosEMU

Cuando este proceso ha terminado, ( unos tres minutos, dependiendo de la carga de la red y de la velocidad del ordenador ) disponemos de una estación de trabajo completa lista para el usuario

Experimentalmente se comprueba que los tiempos de mayor carga de la red corresponden al proceso de recuperación de la imagen del disco duro. Además se da la dificultad añadida de que dicho proceso suele ocurrir de forma simultánea en todos los puestos, coincidiendo con los cambios de turno de los alumnos. Por ello se ha diseñado la topología de la red de manera que se optimiza el funcionamiento de los servidores de aplicaciones

Dichos servidores se encuentran concentrados en el Centro de Cálculo unidos por una red de 100Mbits. una línea de fibra óptica une los dos edificios, y líneas de 100 Mbits llegan hasta cada una de las mesas de trabajo. En función del tipo de tarjetas de red de los puestos, bien se llega a 100Mbits a ellos, o bien mediante un hub se convierte a 10Mbits

Se han concentrado todas las funciones críticas en el segmento a 100Mbits. La red de gestión por contra, funciona a 10. El router que hace de pasarela entre las dos redes tiene un proxy de Web para optimizar en lo posible los accesos al exterior.

Las listas de correo se gestionan desde el segmento de explotación, puesto que la experiencia demuestra que el mayor tráfico de correo es interno. Se ha configurado el correo electrónico de manera que solo los mensajes salientes tienen que atravesar el router.

Puesto que el firewall impide todo acceso desde y hacia la red de explotación se hace necesario un paso auxiliar para que los alumnos accedan al exterior. En el caso del Web, es el proxy el encargado de proporcionar dicho acceso. En el caso del correo electrónico, un PC auxiliar, y una ingeniosa configuración de los MX's en el DNS permite dicho acceso. Los servicios de Telnet, ftp y similares están deshabilitados, y sólo para el acceso desde el exterior a la red de explotación se permite un acceso restringido por ssh y slogin desde las estaciones de trabajo de los profesores

El DNS está gestionado desde el Centro de Cálculo. Existe un dominio propio "lab.dit.upm.es" que permite independizar los laboratorios del resto del departamento. La configuración de correo hace "host masquerading" de manera que con independencia del puesto de trabajo todas las direcciones de correo aparecen como "usuario@lab.dit.upm.es"

Para la gestión de cuentas, y teniendo en cuenta que debe ser el personal de secretaría, se ha creado una cuenta "operador" que no compromete el sistema y una serie de programas de gestión que permiten la gestión de cuentas, listas, etc de una forma sencilla

La actualización del software en los servidores de aplicaciones es sencilla: desde un servidor maestro, y mediante tecnicas de rdist se distribuye a los demás equipos el software, las configuraciones, etc

Como resultado de este trabajo, podemos decir que en estos momentos el principal problema del laboratorio consiste en evitar el robo de las bolas de los ratones....

No obstante, no deberemos olvidar que dicho caché ocupa espacio en disco duro; espacio que es preciso formatear en arranque, lo que puede alargar el proceso hasta hacerlo inaceptable. Como siempre la solución consiste en una correcta evaluación y prueba en condiciones reales del sistema.

La idea de poder aplicar estas técnicas a plataformas que ejecuten Windows-9x es atractiva, aunque tropieza con una serie de dificultades añadidas:

• Windows 95 necesita arrancar desde Disco duro
• No se puede hacer un Download de la imagen del disco: una instalacion mínima de un "disco C:" de Windows, ocupa unos 60 Mbytes ,lo que hace inviable su carga desde la red en un tiempo razonable, incluso aun comprimiendo la imagen
• Es necesario un cargador, que particione y formatee el disco duro
• Es obvio que una instalación mínima de Windows es poco util para un usuario. Por ello es necesario un servidor de aplicaciones extra, usualmente un sistema con Windows-NT. El problema es que dicho sistema es difícilmente escalable, y la experiencia demuestra que cuando mas de 20 puestos arrancan desde el servidor 20 aplicaciones simultáneas, hay una sospechosa tendencia a la aparición de pantallas azules en el servidor NT ....

A pesar de ello, en el Departamento se ha conseguido un arranque dual Linux/Windows95 en una de las dos aulas informáticas. La solución, de nuevo nos la proporciona Linux y sus facilidades para arranques desde Ram-Disk. La idea básica consiste en tener permanentemente en una partición del disco una imagen comprimida del disco C: y mediante un menú de arranque darle al usuario la posibilidad de arrancar Linux, Windows, o bien si se sospecha que la imagen windows pueda estar corrompida, regenerarla de nuevo o incluso actualizarla desde el servidor.

Un último obstáculo: Windows95 no precisa de autentificación para arrancar, lo que convierte el PC en un sistema "libre". Un programa auxiliar verifica que el usuario ha autentificado correctamente una sesión contra el servidor de cuentas ( que ejecuta samba ), y en caso contrario fuerza un reset de la máquina

Todo lo dicho hasta ahora es de aplicación en aulas informáticas, donde es requisito que el usuario tenga acceso pleno a todos los recursos. No obstante es de perfecta aplicación a otros escenarios, siendo el más común el de un CyberCafé. Realmente la única diferencia consiste en que normalmente el número de puestos será menor, y que el acceso a aplicaciones es mucho más restringido. Aquí sí son de aplicación técnicas de XDM con window managers que solo permitan acceso al navegador, o a aplicaciones concretas.

Un último punto es el de aquellas situaciones donde el problema no es el número de puestos, sino la localización geográfica. Hablamos de puntos de información. Básicamente son PC ejecutando navegadores. El problema está en que no es posible una supervisión permanente del puesto. La única solución viable es el arranque mediante Disco-ROM, y unos programas de supervisión remota. De nuevo Windows es una solución inviable, y Linux es la solución ideal

En entornos hostiles es necesario conseguir que la intervención del operador sea mínima. Los costes se disparan exponencialmente con el número de puestos, y no es razonable otra alternativa que la gestión y administración centralizada. Linux es la solución ideal para estos entornos, por prestaciones, fiabilidad, seguridad y posibilidades de configuración

• Referencias
  • Estudiar la documentación que viene en los fuentes del núcleo de linux acerca de NetBoot y NFSRoot. Consultar también sus respectivos HOWTO's
  • Sobre InitialRamDisk encontraremos también alli el fichero initrd.txt
  • Información sobre el paquete NetBoot la encontramos en la NetBoot Home Page

• Transparencias de la ponencia
  • Portada
  • Indice
  • Introducción
  • Problemática de una A.I.
  • Requerimientos y Necesidades
  • Soluciones
  • Esquema funcional de una Aula Informática
  • Los laboratorios docentes del D.I.T.
  • Esquema de los Laboratorios
  • Secuencia de arranque desde Boot-PROM
  • Conclusión. Ampliaciones

• Sobre el autor :-) y el Departamento de Ingeniería Telemática
  • Mi Home Page
  • La Home Page del Departamento
  • La Home Page de la E.T.S.I.T

Este documento ha sido elaborado íntegramente con vi y Netscape en un Pentium 166MMX con Eurielec Linux 2.1 Las imágenes han sido elaboradas con Xfig Las capturas han sido realizadas con Xv