Sumario
- Introducción
- Reunión técnica de mensajería (IRIS-MAIL)
- Reunión técnica sobre el Servicio Netnews
- Reunión técnica sobre el servicio de directorio (IRIS-X.500)
- Reunión técnica del piloto IRIS-MBONE
- Reunión Técnica IRIS-ALMACEN
- GRUPO DE TRABAJO IRIS-NTP: Posible servicio de tiempo en RedIRIS
- Reunión sobre sistemas de búsqueda de información (IRIS-INFO)
- GRUPO DE TRABAJO IRIS-CERT: Reunión técnica sobre Seguridad
Introducción
Los días 18 y 19 de noviembre, se celebraron las segundas reuniones de trabajo de RedIRIS en la Escuela de Óptica de la Universidad de Santiago contando con la asistencia de 127 personas. En total fueron nueve reuniones que en la mayoría de los casos, consistieron en presentaciones sobre la evolución de los servicios a lo largo del 96 y sesiones sobre grupos de trabajo.
Se realizaron presentaciones de los diferentes servicios : red, correo electrónico, directorio X500, NetNews, piloto Mbone y CERT, en las cuales se mostraron estadísticas de tráfico y uso, y se indicó el estado actual de cada uno de los servicios.
Las sesiones de grupos de trabajo fueron una oportunidad para finalizar algunos de ellos, avanzar en otros y proponer actividades nuevas.
Los grupos quedaron de la siguiente forma aunque a continuación se trata con un poco más de detalle cada uno de ellos.
* Grupos que finalizaron:
- SEND-CONF: sobre instalación y configuración de SendMail.
Los resultados han sido una guía, un repositorio de versiones compiladas en diferentes plataformas y un generador de configuraciones de sendmail basado en la aplicación web.
- REC-ES:sobre un registro central de recursos en la red académica.
Los resultados han sido un documento guía y la implementación del registro en el servidor web de RedIRIS.
- MAIL-PGP: sobre seguridad en correo electrónico.
Los resultados han sido una serie de documentos sobre el tema así como guías de instalación y recomendaciones sobre PGP.
* Grupos de trabajo que continúan:
- FTP-DIS: Distribución de información entre servidores FTP anónimos.
- NEWS-ES: Abierto para realizar una segunda versión del documento sobre procedimientos para la creación de grupos de NetNews bajo ES.
* Nuevos grupos de trabajo que se propusieron:
- IRIS-NTP: Puesta en marcha de un servicio piloto de sincronización de equipos en la red, utilizando el protocolo NTP (Network Time Protocol).
- IRIS-MIME: Elaboración de una guía de soporte en la configuración y utilización de MIME en correo electrónico.
- IRIS-INDEX: Propuesta de un piloto de indexación de documentación hipertexto entre centros.
- IRIS-PROXY: Instalación y coordinación de servidores PROXY-CACHE en la red académica.
- IRIS-GUIASEC: Elaboración de una guía básica sobre seguridad en un centro. Elaboración de tutoriales sobre herramientas y procedimientos de seguridad.
- IRIS-PCA: Instalación de un servicio piloto de Autoridad de Certificación de claves públicas.
- IRIS-TUTOR: Para la coordinación e intercambio de tutoriales de uso de la red
Las sesiones se emitieron por el piloto IRIS-MBONE. En los siguientes apartados
se describe con más detalle el contenido de cada reunión.
El Grupo de trabajo sobre correo electrónico tuvo lugar el día 18
de noviembre de 1996 durante aproximadamente 70 minutos y contó con una
asistencia de unas 60 personas. El orden del día estuvo dividido en dos
partes:
1ª Parte: Segunda reunión del Grupo de Trabajo sobre
actualización y configuración de sendmail
2ª Parte: Coordinación del Servicio de Correo
Electrónico
En este aspecto se llegó al acuerdo que el principal criterio de
actualización de una nueva versión será el de seguridad.
Es decir la creación de una nueva versión de sendmail en el
repositorio sólo será precompilada por el equipo y almacenada en
el repositorio cuando las release.notes avisen de la implementación de
algún parche para la corrección de problemas de seguridad en el
Sendmail.
Se dio la circunstancia de que unos días antes de la reunión de
este Grupo de Trabajo apareció un nuevo problema de seguridad en
sendmail. Pocos días después del cierre de estas Jornadas se puso
en marcha el equipo para la compilación de la nueva versión de
sendmail 8.8.3 que se colocó en el repositorio el día 25 de
noviembre para que pudiera ser instalada por las organizaciones de forma
rápida y segura.
Por supuesto se tendrán en consideración la salida de nuevas
versiones de sendmail que incluyan algún tópico no relacionado
con seguridad, pero que se consideren de interés para la Comunidad de
RedIRIS.
Se comentó la necesidad de que las organizaciones de RedIRIS que
utilizasen Estafetas con sistema operativo Unix y con sendmail utilizaran los
ficheros precompilados del repositorio. De igual forma se instó a las
organizaciones que vienen utilizando el sendmail propietario SUN o DEC,
migrarán a este sendmail de Berkeley para un mejor y más seguro
servicio.
Se aceptó la propuesta de RedIRIS de que el almacenamiento del sendmail
precompilado en el repositorio estuviera avalado, de alguna forma, por RedIRIS.
Para ello estos paquetes tendrán asociada una firma PGP de RedIRIS como
garantía. Previamente RedIRIS establecerá los mecanismos
apropiados para asegurar el funcionamiento del repositorio.
Dado que la extensión de este resumen no lo permite podréis
encontrar toda la información sobre las condiciones y divulgación
del repositorio así como, quién y cómo se almacena en la
siguiente dirección:
Reunión técnica de mensajería (IRIS-MAIL) Segunda reunión del Grupo de Trabajo sobre configuración y actualización del sendmail
1.- Política de actualización del repositorio de sendmail
Berkeley precompilados
2.- Utilización del repositorio
3.- Almacenamiento del repositorio
4.- Configuración del sendmail (sendmail.cf)
Se comentó la calidad de la configuración generada por el paquete creado en el Grupo de Trabajo. Se aconseja que los usuarios de la Comunidad de RedIRIS lo utilicen y pierdan el miedo a reconfigurar su sendmail, en muchos casos obsoleto. Los resultados del configurador de sendmail serán mayores si se utilizan los ejecutables del sendmail del repositorio.
Se discutió ampliamente la posibilidad de incluir nuevas opciones a la configuración del sendmail en los niveles de acceso a las Estafetas:
5.- Política de divulgación de los resultados
Se debatió brevemente, pues ya había sido comentado a través de la lista, el tema de la accesibilidad de los resultados del Grupo de Trabajo. Por amplia mayoría se decidió que los resultados deberían ser públicos e incluso traducidos al inglés para mayor divulgación.
6. Futuro del Grupo de Trabajo
Por la propia política de los Grupos de Trabajo de RedIRIS este Grupo debe finalizar. El trabajo y los resultados están a disposición de toda la Comunidad y creo que servirán para mejorar notablemente el Servicio de correo electrónico en la comunidad, dado que hay una gran mayoría de organizaciones que utilizan máquinas con sistema operativo Unix como Estafetas de correo electrónico.
También se intentará trabajar estadísticas utilizando la información que genera el sendmail.
El tema es lo suficientemente abierto y dinámico como para seguir
trabajando en él, por lo que queda abierto y se intentarán
debatir futuras implementaciones a través de la lista que ha sido
utilizada en el Grupo y que ha quedado abierta al publico:
send-conf [at] listserv [dot] rediris.es
Coordinación del Servicio de Correo electrónico
1.- Resumen de los Grupos de Trabajo
1.1.- Grupo de Trabajo sobre actualización y configuración de sendmail
* Objetivos alcanzados:
- Ofrecer herramientas para el diseño de un Servicio de Correo Electrónico basado en Estafetas con software Sendmail de Berkeley que sean: seguras, rápidas, fiables y estén actualizadas
1.2.- Grupo de Trabajo sobre seguridad en correo electrónico basado en PGP
* Objetivos alcanzados:
- Elaboración de documentación completa sobre PGP en los sistemas operativos más habituales
- Elaboración de documentación sobre integración de Agentes de correo con PGP: instalación, uso y experiencias
- Realización de pruebas y arranque del Servidor de Claves Públicas PGP de RedIRIS
2.- Estadísticas sobre algunos de los Servicios
2.1.- Servicio de MailBackup
Se ofrecieron unas estadísticas sobre la utilización de este Servicio y se intentó interpretar los motivos del alto tráfico en condiciones normales y en ausencia de incidentes. Los motivos dados por los participantes fueron varios: carga de las Estafetas, lentitud de las líneas internacionales etc.
En líneas generales se puede considerar que el Servicio ha cumplido, cumple y cumplirá su función. Se hizo una llamamiento para que las Organizaciones de RedIRIS lo soliciten para su correcta formalización en: http://www.rediris.es/mail/mailbackup/
2.2.- Servicio de Listas de Distribución
Las estadísticas de este Servicio indican que ha habido durante este año un gran crecimiento. Un breve resumen de las que se ofrecieron en la reunión a 14/11/96, aparecen reflejadas en el cuadro.
| Nº de listas hospedadas: | 50 | |
|---|---|---|
| Nº de subscriptores: | 10.800 | |
| Nº de mensajes tramitados por el servidor: | Febrero/96 | 619.075 |
| Marzo/96 | 658.769 | |
| Abril/96 | 737.062 | |
| Mayo/96 | 920.359 | |
| Junio/96 | 874.169 | |
| Julio/96 | 768.614 | |
| Agosto/96 | 766.353 | |
| Septiembre/96 | 912.213 | |
| Octubre/96 | 1.491.364 | |
| Noviembre/96 | 1.816.519 | |
Se hizo una nueva divulgación del Servicio para que las organizaciones participaran en la creacion de foros de interés para la Comunidad académica y científica solicitando Listas de Distribución a RedIRIS en la siguiente dirección:
3.- Coordinación de los Servicios de Listas de Distribución
Se recomendó la instalación de servidores de listas en las organizaciones con la siguiente política:
Es recomendable que listas de ámbito local, con un previsible número de miembros no muy grande, sean abiertas en servidores de listas locales de la organización. En cambio listas de ámbito internacional y con el punto de mira puesta en Latino América y la difusión del idioma castellano, así como gran cantidad de miembros es recomendable que sean solicitadas a RedIRIS.
Se puede encontrar más información en: http://www.rediris.es/list/
4.- Coordinación de los responsables del Servicio
Se hizo un llamamiento para tener actualizados los datos de los puntos de contacto del Servicio para cada Organización. Los datos de estos coordinadores son los que deben de estar en la lista:
iris-mail [at] listserv [dot] rediris.es
enviando una mensaje a: listserv [at] listserv [dot] rediris.es cuyo cuerpo sea:
Los responsables del Servicio deben darse de alta en esta lista a través de la cual se divulgará información de interés para la Comunidad (nuevos servicios, grupos de trabajo, herramientas, problemas, etc.) además de servir de foro de discusión para tratar temas de interés sobre correo electrónico.
5.- Nuevo Grupo de Trabajo sobre MIME en correo electrónico
Se abrirá un nuevo Grupo de trabajo sobre MIME. Un boceto de los objetivos del mismo son:
- Registro de Agentes de Usuario MIME utilizando el RFC-1844 (Multimedia E-mail MIME User Agent Checklist).
- Evaluación y recomendaciones de configuración de la parte MIME de los Agentes de Usuario de correo.
- Registro, evaluación y recomendaciones para Estafetas de correo: ESMTP y RFC-822/MIME.
Jesús Sanz de las Heras
jesus [dot] heras [at] rediris.es
Reunión técnica sobre el Servicio Netnews
PRESENTACIÓN
1.- Objetivos del servicio
Estas son los principales objetivos que RedIRIS pretende alcanzar en el servicio de News:
- Distribución de las Usenet News a los centros afiliados
- Coordinación de su encaminamiento de una manera afín a la infraestructura de red disponible
- Coordinación de la jerarquía es.*
- Prestación de ayuda técnica a los centros adscritos
2.- Tareas desarrolladas por el equipo técnico
Para alcanzar los objetivos antes descritos el equipo técnico de RedIRIS desarrolla las siguientes tareas:
- Asegura las vías de recepción de NetNews
- Administra los recursos disponible y adecua éstos, en la medida de lo posible, a las necesidades del servicio
- Recopila y cataloga la información sobre la Usenet
- Mantiene un punto central de información para los responsables de los centros afiliados
- Help-Desk: newsmanager [at] rediris [dot] es
3.- Situación actual y evolución
Hardware
En cuanto a hardware se ha producido la ampliación de memoria del servidor primario a 128 Mb de RAM. Se ha instalado una nueva controladora Fast-Wide SCSI con dos discos externos de 4.2Gb donde se ha instalado íntegramente el spool de artículos.
Software
En el software, durante este año se ha producido la actualización del sistema operativo del servidor primario a Solaris 2.5. También se ha producido la actualización del software servidor de NetNews a la versión 4 no-oficial del INN (INNunoff 4), que incorpora las ventajas de envío en modo flujo (streams). Este modo de funcionamiento es una extensión del protocolo NNTP que se está discutiendo en un grupo de trabajo del IETF con el fin de obtener un nuevo estándar (RFC) sobre el protocolo de transporte de NetNews, y cuya ventaja fundamental es la reducción de la latencia en la transmisión de artículos entre servidores. Con esta nueva versión del INN hemos obtenido un mejor rendimiento en nuestras conexiones con otros servidores que soportan la extensión descrita, en concreto son la Universidad de Oregon, BelNET y EasyNET como nodos internacionales, y la Universidad de Valladolid como nodo nacional.
Hemos instalado un nuevo paquete de recopilación de estadísticas de tráfico de entrada. El paquete se llama inflow, y está desarrollado por Felix Kugler (SWITCH), basado en los scripts desarrollados en RedIRIS para la medida del tráfico entrante. Sobre los mismos hemos hecho algunas modificaciones para el cómputo de valores medios mensuales y salida gráfica de resultados.
Asimismo se han modificado los scripts de información sobre el estado de los canales de transmisión (batches de envío) incluyendo la información sobre el estado de los canales NNTPLINK. Se ha adoptado este método de envío, en un principio sólo con aquellos nodos cuya conectividad a RedIRIS era por enlaces desahogados, y posteriormente con todos aquellos nodos que reciben un feed completo de los grupos distribuidos por RedIRIS.
Después de varios intentos de abrir el servidor secundario happy.rediris.es al acceso público para los grupos es.*, hemos optado por dejar abierto el acceso sólo a los grupos relacionados con la creación de otros y administración de news en general, esto es, los grupos es.news .*.
Nodos conectados
Durante este año se han unido a nuestro servicio los siguientes centros:
- Universidad de La Rioja
- MEC
- TID,SA
- Universidad de Cantabria
- Instituto Nacional de Estadística
- Universidad de Murcia (de UV a RedIRIS directo)
- Universidad de Baleares (de UPC a RedIRIS directo)
- CTI/CSIC
- CESGA, y los siguientes centros conectados a él:
- Universidad de la Coruña
- Universidad de Vigo
- Universidad de Santiago de Compostela
- Universidad Jaume I de Castellón (a través de UV)
- Los siguientes centros a través de EHU:
- Campus de Álava
- Universidad de Deusto
- Robotiker
Coordinación internacional
Durante este año han tenido lugar varias reuniones internacionales sobre coordinación del servicio de NetNews, dos de ellas dentro del marco de RIPE y otra de ellas promovida por DANTE. Estas han sido:
- 22/Abril, Berlín (NetNews WG RIPE)
- 20/Agosto, Bélgica (NewsFlow DANTE)
- 20/Septiembre, Amsterdam (NetNews WG RIPE)
DANTE
Parece ser que BT ha ofrecido a DANTE una oferta de coordinación de flujo de NetNews. Estos últimos están estudiando la posibilidad de ofrecer un servicio a sus clientes de EuropaNET.
El volumen en Kbps se está incrementando en un factor de 4 por cada año. Actualmente el volumen de NetNews de un full-feed es de 2 GB día con picos de 3 GB. El número de artículos crece en un porcentaje del 40% al año.
La discusión se centra entre la definición del servicio y el coste por el mismo. En principio la oferta de BT incluye la dotación de servidores en sus SuperHUBs que ofrecerían un servicio de NetNews a un coste fijo (<100 kECU al año), sin un Calidad de Servicio real, pero bajo condiciones comerciales, con el derecho a rechazar feeds adicionales en función de razones legales o morales, y con derecho a alimentar a redes comerciales.
RIPE
Los tópicos desarrollados por el grupo de trabajo de RIPE son similares a los de DANTE, quizás un poco más amplios, tocando tópicos más concretos de QoS y herramientas de información y estadísticas, parece que no es un tema que preocupe tanto a los ISP's, y el tema esta más centrado en las NRN (redes de investigación), bajo el amparo de DANTE.
Grupo de trabajo NEWS-ES
Durante principios de este año se ha llevado a cabo la mayor parte del desarrollo del grupo de trabajo NEWS-ES , cuyos objetivos eran la reestructuración de la jerarquía es.*, y la definición de unas normas de creación de grupos bajo dicha jerarquía. Los objetivos del grupo de trabajo se han cubierto con éxito gracias a la dedicación de sus participantes, y las normas definidas han permitido la evolución de la jerarquía durante este año de una forma aceptable. Con el fin de depurar algunos aspectos que habían quedado poco claros, se ha procedido a la re-apertura del grupo para hacer un seguimiento del impacto de la implantación de las nuevas normas y aclarar algunos aspectos que la experiencia ha demostrado que estaban poco claros o no habían sido previstos.
Estadísticas de tráfico
Por lo que podemos resumir se ha producido en este año una evolución mayor del 80% en número de artículos recibidos, de aproximadamente el 100% en volumen transferido. Un 8,2% de crecimiento en los tamaños medios de los artículos de NetNews, y aproximadamente un 100% en el ancho de banda consumido. Estos valores están sensiblemente reducidos por los problemas de BelNET con la saturación de su enlace internacional lo cual, unido al cambio de su servidor de NetNews a un PC con Linux y su política de restricción de la distribución de la jerarquía alt.* a los periodos nocturnos, a mi entender ha producido un disminución significativa en los artículos recibidos en RedIRIS, sin excluir la situación de saturación de nuestros enlaces internacionales.
Corrigiendo estos problemas podemos encontrarnos a finales de este año, con un crecimiento medio del tráfico de NetNews mayor del indicado en la siguientes líneas:
| Nº de artículos recibidos: | 94,1% |
| Bytes: | 365,8% |
| Tamaño medio de artículo: | 139,9% |
| Ancho de banda consumido: | 365,8% |
Hay que tener en cuenta que desde el 1 de Octubre SWITCH tiene un acceso de 2Mbps a EuropaNET hasta el advenimiento del TEN-34, por otro lado ha primado el flujo de otros grupos frente a los alt.binaries y derivados, lo cual afecta a sus nodos subyacentes entre los que nos encontramos.
4.- Previsiones de futuro
Si los presupuestos nos lo permiten, tenemos previsto realizar una ampliación del hardware empleado para el servicio de NetNews. Nuestras ideas consisten en disponer de un servidor de mayor capacidad dedicado en exclusiva a la alimentación de los nodos regionales, y desplazar el actual servidor a la alimentación de nodos en Madrid y lectura de los clientes necesarios.
El actual servidor de NetNews dispone de una tarjeta ATM, y es posible que antes de finalizar este año esté operativa la conexión directa en ATM con los router centrales de acceso a RedIRIS, lo cual mejorará sensiblemente su rendimiento.
Estudiaremos, viendo las tendencias europeas al respecto, la posibilidad de implantar en RedIRIS nuevas formas de obtención de NetNews, que aliviasen el colapso de nuestros enlaces internacionales. En concreto lo referente a alimentación por satélite, aunque esta previsión no creo que sea muy necesaria con el advenimiento del TEN-34.
Estaremos atentos a la evolución de las nuevas herramientas que se puedan desarrollar en la distribución multicast de NetNews. Por lo que sabemos, los técnicos de Xlink están trabajando en ello.
Detalles que nos quedan pendientes, de menor prioridad son:
- Estadísticas semanales y mensuales de tráfico de NetNews accesibles vía Web.
- Formulario de actualización a la subscripción de grupos.
- Otros detalles que pueden surgir durante la reunión.
DISCUSIÓN
Problemática de crecimiento exponencial (caso particular: jerarquía alt.*)
Como se ha visto en la exposición anterior, el crecimiento de las Usenet News es un tema preocupante. El ancho de banda puede no ser el problema principal en el futuro (si se cumplen las previsiones), pero los recursos técnicos y humanos sí pueden serlo. Por otro lado no hay que olvidar el coste asociado a este ancho de banda consumido.
En relación con los recursos técnicos hubo sugerencias de utilizar equipos de bajo coste para el servicio, en concreto servidores con arquitectura de PC, procesadores Pentium y bajo el sistema operativo Linux. Estamos abiertos a recibir cualquier estudio serio sobre el rendimiento de estos equipos como servidores de NetNews con mucha carga, pero en ningún caso creemos conveniente arriesgar la estabilidad de un servicio con experiencias de este tipo.
Sin entrar en el debate de los contenidos, es demasiado patente, que esta discusión está centrada en grupos que nada tienen que ver con una red de I+D. Desde RedIRIS se propuso el estudio de la no distribución de los grupos con contenidos claramente no relacionados con el I+D que mayor consumo de recursos técnicos suponen, en particular grupos de contenidos binarios bajo la jerarquía alt.*
La opinión general de los asistentes era que una eliminación de estos grupos crearía un incremento considerable del uso de otros recursos menos óptimos (WWW, FTP), en la búsqueda de contenidos similares, lo que produciría un crecimiento considerable del ancho de banda consumido en los enlaces troncales de RedIRIS y accesos internacionales.
El tema sigue abierto a debate. Se estudiarán iniciativas que puedan surgir en otras redes similares a nivel europeo.
Definición de requerimientos de centros conectados
La conexión al servicio de NetNews de RedIRIS implica que ciertos centros deben convertirse en nodos primarios de otros nodos subyacentes dada la topología de red a la que nos intentamos ajustar por motivos obvios. Hasta ahora no se han especificado explícitamente los requerimientos que esta situación implicaría, más bien se daban por sabidos, pero creo que es necesario hacer unas breves especificaciones. Nuestras sugerencias son:
- Equipamiento técnico suficiente
- Capacidad de distribución de grupos incluyendo los requeridos por los nodos hoja
- Capacidad de albergar lectores esporádicos dentro de la zona
- Recursos humanos
- Help-Desk
- Asistencia a nodos secundarios en caso de defectos de transmisión a los mismos
- Información de estado y/o estadísticas accesibles vía WEB. para información a responsables de NetNews en nodos subyacentes
Información y formación a usuarios
Una tarea importante que deben realizar los centros es la formación de sus usuarios. Esta es una tarea que difícilmente podemos abarcar en RedIRIS, pero que supone un pilar fundamental para el buen uso de los recursos ofrecidos. Se podría realizar un grupo de trabajo que abordase este tema, sería una forma de poder abarcar el proyecto de forma conjunta, y si es necesario se buscarían fondos del PAST o cualquier otro tipo de subvención para abarcarlo. Algunos centros ya han abarcado ese proyecto, y sus experiencias podrían ser interesantes para todos.
Juan Antonio García
juan [dot] garcia [at] rediris.es
Reunión técnica sobre el servicio de directorio (IRIS-X.500)
1.- Informe de gestión del Servicio de Directorio
Se dio una visión de la gestión del Directorio X.500 que ha realizado RedIRIS durante 1996 indicando el aumento del número de entradas que ha pasado de 47.330 a 61.048 entre octubre de 1995 y octubre de 1996.
En total 9 servidores han actualizado su software a la versión de Isode Consortium.
2.- Mantenimiento de la información en el Directorio
Este fue uno de los puntos más conflictivos de la reunión porque siempre nos encontramos con el mismo problema, resulta bastante complicado mantener el directorio actualizado si las herramientas de las que disponemos para la gestión de las entradas no son cómodas de usar.
Se plantearon diversas soluciones que pasaban desde usar programas sobre PC a realizar aplicaciones de volcado basadas en el web.
De aquí puede salir un grupo de trabajo que obtenga una documentación sobre la instalación, configuración y el mantenimiento de DSAs, desarrollando una guía sobre el volcado de datos.
3.- Otros usos del Directorio
Este año se han incluido URLs en las organizaciones que cuelgan de España. Se promueve esta iniciativa para que los responsables de los centros incluyan los URLs en las entradas de sus departamentos.
Se van a almacenar claves y certificados X.509 en el Directorio en un proyecto conjunto con el Área de seguridad.
4.- Otros directorios
Se comentaron otras alternativas al directorio X.500.
Si se desea ampliar esta información se puede consultar la dirección:
Javier Masa
javier [dot] masa [at] rediris.es
En la sesión se comentó la topología de la red virtual
multicast en RedIRIS. El Centro de Comunicaciones CSIC RedIRIS mantiene el nodo
central que está compuesto por tres estaciones de trabajo. Existen 12
túneles a "routers" de comunidades autónomas, y en total 26
centros reciben el servicio en alguna subred.
Los túneles de primer nivel que parten del centro de comunicaciones CSIC
RedIRIS, tienen como extremo:
Con posterioridad se pasaron a tratar los parámetros de
configuración de la red. El "threshold" es un mecanismo que implementan
los túneles del protocolo de routing DVMRP para restringir la salida de
los datagramas "multicast" de una red. Sólo pueden llegar al otro
extremo del túnel los paquetes de información que tengan un TTL
igual o superior a la suma del "threshold" definido en el túnel y su
métrica (distancia). De cara al usuario final el TTL sirve para
identificar el ámbito de difusión de las sesiones.
Quedó de la siguiente forma:
A continuación, se analizó el grado de difusión del
servicio dentro de varios centros. El escenario varía entre aquellos
donde el servicio está limitado a una única subred IP, a otros
que por su implementación de red, se expanden los datagramas multicast a
todo los equipos del centro.
En la reunión se indicó la falta de un mecanismo de control sobre
las retransmisiones. Aunque la red tiene un límite máximo de 512
Kbps o 768 Kbps, se pueden producir emisiones no deseadas que colapsen la red y
que incumplan los procedimientos de creación de sesiones nacionales e
internacionales.
Se presentó la agenda y los procedimientos de creación de
sesiones que se encuentran en el servidor web de RedIRIS. Todas las sesiones
deben registrarse para evitar solapamiento y permitir una cierta calidad de
servicio dentro del caudal máximo permitido. Gracias a este registro
también se puede establecer un punto de información de eventos
multicast.
Por último se propuso realizar un documento guía sobre los pasos
que debería seguir un usuario para emitir y participar en una
sesión Mbone. Este documento estará formado por unos
procedimientos de registro de sesiones y un conjunto de recomendaciones
obtenidas tanto de experiencias realizadas en el piloto como de
documentación existente.
La reunión trató sobre dos grupos de trabajo relacionados con
sistemas de almacenamiento.
En la segunda reunión del grupo de trabajo FTP-DIS se ha puesto de
manifiesto la necesidad de realizar un esfuerzo mayor que el realizado hasta el
momento en aras de conseguir los objetivos propuestos en su creación y
ratificados en parte en esta reunión.
El objetivo principal del grupo sigue siendo el realizar una
coordinación de todos los FTPs de nuestra comunidad con el fin de lograr
por una parte, un mejor aprovechamiento de los recursos evitando las
redundancia en la medida de lo posible y por otra dotar al usuario final de
formas de búsqueda más cómodas que la proporcionada por
archie.
Los pocos resultados del grupo de trabajo se reflejan en la situación
actual de los FTPs: habiendo setenta gigabytes totales en el registro,
todavía hay muchas colecciones de software no contenidad en
ningún FTP español, mientras algunas otras muy populares llegan a
duplicarse en seis o siete FTPs distintos. No obstante, el mero hecho de que
los FTPs de la comunidad IRIS hayan crecido y dispongan de colecciones de
software muy populares ha conseguido corregir la tendencia del usuario final a
ir al repositorio origen en el extranjero. Un reflejo de ésto son los
más de tres gigabytes diarios que se llevan los usuarios del FTP de
RedIRIS (ver http://www.rediris.es/ftp/stats
El grupo de trabajo realizó en su día una herramienta de registro
de colecciones software en los FTPs. Está aún pendiente el
registrar todo el software disponible en los FTPs españoles. Dado que el
registro de colecciones software incluye información de tipo bastante
dinámico y descripciones que deben ser actualizadas. Se intentará
buscar un responsable por cada colección software que asuma la
responsabilidad de mantener al día la documentación asociada. En
este punto se desestimó la posibilidad de generar la
documentación de las colecciones software automáticamente
mediante un robot buscador debido a lo difícil de encontrar una manera
de realizar dicha tarea que pudiese funcionar con todas las colecciones
existentes dada la diferente manera de organizar la documentación de
cada una.
Se acordó realizar un esfuerzo para tener disponibles las
estadísticas de cada FTP e ir estimando en virtud de las mismas la
evolución del grupo. Mientras que a nivel de cada FTP las
estadísticas más interesantes pueden ser los accesos totales de
usuarios (separando los de IRIS del resto) clasificados por colecciones a las
que acceden, a nivel global interesa obtener el tráfico total generado
para traer las colecciones software del extranjero, el total de software
disponible respecto al total de espacio en la suma de todos los FTPs de RedIRIS
y los accesos totales a cada colección de software.
También se ha considerado interesante dotar los medios necesarios para
que colecciones o aplicaciones concretas generadas en España encuentren
una manera fácil de albergarse en los FTPs de RedIRIS y darles la
publicidad adecuada.
Se ha decidido, dentro de la comunidad IRIS, iniciar un esfuerzo de
creación y coordinación de cachés de red. Este esfuerzo
pretende conseguir los mismos buenos resultados que iniciativas similares
están dando en otros paises y responde a la necesidad de optimizar un
tráfico tan desorganizado y redundante como el provocado por las
aplicaciones basadas en el protocolo http.
La creación del grupo de trabajo tuvo lugar durante las pasadas
reuniones de trabajo de RedIRIS en Santiago de Compostela en el mes de
Noviembre. La reunión empezó haciendo una revisión del
estado actual de las cachés de RedIRIS, a saber: seis cachés de
universitarias registradas sin ninguna coordinación existente entre
ellas. La universiad de Oviedo siendo actualmente la más avanzada en la
operación de su proxy-caché ha conseguido ahorros de hasta un
cincuenta por ciento en el tráfico http. A continuación se
trataron los objetivos del grupo de trabajo.
Los objetivos del grupo de trabajo IRIS-CACHE son: por una parte tomar las
acciones necesarias para promover la creación de cachés a nivel
regional y de organizaciones en toda la comunidad IRIS y por otra parte
estudiar e implementar la coordinación necesaria para optimizar los
resultados de la cooperación entre cachés.
En cuanto al hecho de promover la creación de cachés, se estima
necesario que todas las instituciones afiliadas a RedIRIS vayan montando las
suyas propias, para facilitar esta labor el grupo debe ir generando
guías de instalación de un proxy-cache http, guías de
instrucción a los usuarios finales y una lista de distribución de
soporte técnico. RedIRIS facilitará un registro de cachés
españolas integrado con el registro europeo de cachés en marcha
desde hace unos meses.
En cuanto vayan dándose resultados por parte del grupo de trabajo se
verán los medios más efectivos para su difusión de manera
que lleguen a todos los responsables técnicos de instalaciones donde sea
factible y recomendable la instalación de un proxy-caché.
En lo que respecta a la coordinación necesaria no se va a optar por una
jerarquía cerrada sino más bien por un banco de pruebas que en
base a ensayos de interconexión de cachés y análisis de
las estadísticas resultantes vayan configurando la mejor
topología posible en cada momento. Queda como tarea del grupo de trabajo
el determinar las estadísticas más significativas sobre el
rendimiento de interconexiones de cachés y dotar de los medios para
recabar las estadísticas de todas las cachés instaladas.
Mediante la cooperación entre cachés se espera conseguir que unas
cachés puedan servir como respaldo de otras cuando no puedan estar
operativas y que repartiéndose las zonas de las que se responsabiliza
cada caché, cada nueva caché en el grupo ayude a tener más
capacidad de almacenamiento y más fiabilidad en conjunto.
RedIRIS espera poder ofrecer en este año próximo un proxy-cache
de http público para todos los usuarios de nuestra comunidad. Situando
este proxy-caché en la salida internacional se intentará tener
disponible un alto porcentaje de los accesos a USA y Europa en la caché.
Esta caché servirá de padre a las cachés regionales y
formará parte del programa de coordinación Europea dentro de la
red académica europea que está llevando a cabo TERENA.
La difusión de documentación sobre todas las pruebas realizadas y
los resultados obtenidos, y sobre todo el ofrecer al usuario final un servicio
lo más fácil de utilizar posible estarán presentes en
todas las tareas que realice el grupo de trabajo.
En breve esperamos definir unos objetivos y plazos de trabajo que
devengarán, posiblemente en el segundo tercio del año que viene,
en el establecimiento de un servicio básico de sincronización
dentro de nuestra comunidad.
La reunión se dividió en dos sesiones de grupos de trabajo. La
primera trató sobre el registro de recursos y en la segunda se propuso
un nuevo grupo sobre indexación de servidores web.
En el grupo de trabajo sobre registro de recursos (REC-ES), se presentó
un documento guía que describe los objetos que registra el Centro de
Comunicaciones CSIC RedIRIS y los procedimientos para añadir, y mantener
la información. El documento de referencia se encuentra en la siguiente
direccion:
Como continuación a esta actividad se pondrá en marcha dentro de
la coordinación de sistemas de información un nuevo servicio que
responderá a las siglas "Registro de Recursos en RedIRIS" que va
dirigido principalmente a usuarios finales de redes académicas y de
investigación. En las siguientes líneas se describe brevemente la
presentación del servicio que se realizó en la sesión y
que queda recogido en el mencionado documento:
Dentro de estos objetos de información se encuentran:
En la sesión del grupo de trabajo iris-index, se dio una idea general
sobre la forma de actuar de los robots que actualmente se encuentran en la red
y sobre la problemática que están ocasionando debido a la
imposibilidad de encontrar de una forma cómoda toda la
información que se busca en la red.
Se propusieron mecanismos para solventar estos problemas en la comunidad de
RedIRIS mediante el uso de sentencias específicas para ayudar a los
robots a encontrar la información de manera eficiente. Asimismo se
propuso también utilizar de forma conjunta la información
indexada por un robot de forma que únicamente acceda a un servidor un
robot.
Para ello se está usando Harvest que permite generar una base de datos
indexada que posteriormente se puede exportar para que todos los robots puedan
obtenerla sin necesidad de recorrer el servidor.
El objetivo del grupo es crear un mecanismo para la indexación de
recursos en la comunidad de RedIRIS de manera que en un futuro próximo
quien lo desee pueda crear un índice de alguna materia.
Se identificaron algunos centros que iban a participar por que ya estaban
usando Harvest como software para la indexación.
Se identificó la información a indexar. En principio se
creará un índice de tesis doctorales que se encuentren presentes
en los servidores de los centros que participen en el piloto de
indexación
Se generará documentación sobre instalación,
configuración y mantenimiento del software necesario para este
propósito. También se generará información sobre
cómo han de ser los documentos que se indexarán, indicando los
campos META necesarioso la alternativa que se elija.
Si se desea más información sobre el grupo de trabajo puede
encontrarse en:
Se celebró la segunda Reunión de Trabajo del Servicio de
Seguridad de RedIRIS , donde se analizó el funcionamiento del servicio en
su primer año de existencia y se definieron varias líneas de
trabajo para el futuro.
Era necesario definir claramente la postura de RedIRIS en cuanto a incidentes
de seguridad externos a la comunidad de I+D. En este sentido, el servicio de
seguridad tiene dos funciones complementarias con necesidades operativas
diferentes, que se explicaron en esta reunión.
En primer lugar, existe un servicio de atención primaria frente a
incidentes, que requiere coordinación con servicios similares y no puede
restringirse a una comunidad cerrada. Se ha decidido colaborar con entidades
externas a RedIRIS cuando el origen del incidente esté en nuestra
comunidad, y actuar de `puente' entre otros servicios de seguridad en el resto
de los casos. Bajo estas premisas la mayor organización internacional en
materia de seguridad (FIRST) ha aceptado la candidatura de RedIRIS como futuro
miembro y como punto de contacto oficial en España.
En segundo lugar, existen una serie de servicios adicionales (formación,
asesoría, ayuda personalizada) que restringimos a la comunidad de I+D.
Se hizo un balance de la gestión de estos servicios, destacando tanto
los puntos fuertes como las deficiencias, principalmente en materia de
coordinación con las instituciones de RedIRIS. Como resultado se
acordó establecer una estructura más ágil y flexible de
puntos de contacto, tanto para la resolución de problemas de seguridad
como para coordinar actividades.
Hasta ahora las actividades complementarias se han limitado a
consultoría, la participación en el grupo de trabajo sobre PGP y
la implantación del servicio de distribución de claves PGP. En
esta reunión se presentaron los primeros grupos de trabajo
específicos de seguridad, sobre los siguientes temas:
Reunión técnica del piloto IRIS-MBONE
El piloto se encontraba desconectado de la red Mbone de Internet desde finales
de Julio. Hasta entonces y durante un año, el servicio se había
recibido por un trayecto virtual ATM con el Reino Unido. En breve, se
pretendía restablecer la conexión con algún vecino en la
red europea.
Los valores de cara al usuario final son los siguientes:
También se decidió aumentar de 512 a 768 Kbps el ancho de banda
de los túneles por ATM, de este modo, pueden soportar el tráfico
internacional de Mbone, que puede llegar a 512 Kbps y un tráfico
nacional de 256 Kbps. Estos limites se irán cambiando en función
de la disponibilidad de anchos de banda en el troncal de comunicaciones.
Celestino Tomás celestino [dot] tomas
Reunión Técnica IRIS-ALMACEN 1.- Grupo de trabajo FTP-DIS
2.- Creación del Grupo de Trabajo IRIS-CACHE
Javier Puche javier [dot] puche [at] rediris.es
Juan Antonio García juan [dot] garcia [at] rediris.es
Reunión sobre sistemas de búsqueda de información
(IRIS-INFO) Grupo de trabajo REC-ES
Grupo de Trabajo IRIS-INDEX
Celestino Tomás
celestino [dot] tomas [at] rediris.es
GRUPO DE TRABAJO IRIS-CERT: Reunión técnica sobre Seguridad
Rubén Martínez
ruben [dot] martinez [at] rediris.es
Índice General
![[Índice General]](../logopuente_boletin.gif){kind=small}