Sumario
- Ampliación de la línea de Ibernet
- Grupo de Trabajo IRIS-RED
- InfoVía en RedIRIS
- II Congreso Virtual Hispanoamericano de Anatomía Patológica
- I Reunión de Administradores de listas de RedIRIS
- Políticas institucionales frente al Abuso en el Correo Electrónico
- Grupo de trabajo IRIS-MAIL
- Reunión de Coordinación IRIS-SEARCH
- Iniciativas contra el abuso en las NetNews
- Sistema de Alta Disponibilidad para el Servicio de Netnews
- Grupo de Trabajo IRIS-NEWS
- Grupo de Trabajo IRIS-CACHE
Ampliación de la línea de Ibernet
Tras el aumento del ancho de banda en la línea entre RedIRIS y
Estados Unidos, se ha procedido también a la ampliación de la
capacidad de la línea de interconexión con Espanix a
través de Ibernet. Este enlace ha pasado de los 4 Mbps que tenía,
repartidos en dos líneas de 2 Mbps hasta los 8 Mbps (siempre en
términos de IP), utilizando para esta nueva conexión una
línea ATM de 34 Mbps. Se espera que este nuevo ancho de banda permita
paliar en parte la saturación que se venía produciendo en la
práctica totalidad del día, extendiéndose ultimamente
también a los días no laborables.Existe el compromiso por parte de Telefónica de aumentar el ancho de banda de este enlace cuando la ocupación lo demande, y no vuelva a suponer un cuello de botella.
maribel [dot] cosin [at] rediris.es antonio [dot] marquez [at] rediris.es
Las dos gráficas anteriores muestran el nivel de tráfico por cada protocolo.
Con datos tomados durante quince días se observa que el protocolo más utilizado es el HTTP, seguido del FTP y de tráfico originado en aplicaciones varias sobre TCP.
maribel [dot] cosin [at] rediris.es antonio [dot] marquez [at] rediris.es
RedIRIS desde sus inicios, en 1988, ha venido ofreciendo un servicio de acceso
a determinados servicios de RedIRIS vía Red Telefónica
Básica (RTB). En 1995 se empezaron a utilizar protocolos SLIP/PPP
(Serial Link Interface Protocol/Point to Point Protocol) y se aumentó la
gama de servicios: buzones de correo corporativo, hospedaje de páginas,
acceso a los servidores News de RedIRIS etc.. El servicio RedIRISdial se viene
ofreciendo a través de un sistema basado en un grupo de salto con 12
módems conectados a un servidor de acceso que a través de
conexiones SLIP/PPP identificaba y autorizaba la conexión.
A continuación describimos tanto el escenario previo de este servicio
(RedIRISdial) como la situación actual. Asimismo se concluye comentando
las mejoras obtenidas al dar este Servicio a través de InfoVía,
etc.
La configuración del servicio para poder dar un acceso garantizado
implica los siguientes pasos: (Configuración en RedIRIS para ser Centro
Proveedor de Información Infovía)
Otras ventajas de este servicio son: la posibilidad de tarificar el servicio,
disponer de un control de acceso de los usuarios, herramientas de
administración de las conexiones y otras.
Hoy día se está ofreciendo servicio a un total de 48 usuarios de
distintas organizaciones (Centros Afiliados). Con los siguientes recursos
técnicos:
RedIRIS ha puesto a disposición de este II Congreso su Servicio de
Listas de Distribución para la organización de 15 talleres o
salas congresuales de otras tantas especialidades del congreso. Se han ofrecido
facilidades de suscripción y participación vía Web y
correo electrónico y en general se han creado unas listas
diseñadas a medida para los objetivos del Congreso. Estas listas de
distribución, que ofrece RedIRIS, han permitido de una forma sencilla y
desde cualquier lugar del mundo participar o "escuchar" los debates de las
ponencias presentadas en el Congreso. Para todo ello se han tomado las
máximas medidas de seguridad con el fin de evitar intromisiones y
aportaciones no deseadas.
La dirección de este congreso es: http://www.conganat.org/
Por lo tanto con dos herramientas básicas de la actual tecnología
como son el correo electrónico y páginas Web es posible poner en
marcha con gran éxito este tipo de acontecimientos. Como objetivo
principal se consiguen una serie de beneficios científicos por la
lectura de las ponencias y por el intercambio de información. Como
efecto secundario se logra organizar un Congreso no presencial donde participan
personas de todo el mundo con el consiguiente ahorro económico.
Desde el punto de vista de RedIRIS el resultado más interesante fue
poder escuchar en directo las ilusiones, perspectivas y demandas de este tipo
de personas representan un ejemplo real del "usuario final". Es de esperar que
estas reuniones se mantengan de forma estable en futuras convocatorias de
Jornadas y Grupos de Trabajo de RedIRIS, donde se traten de una forma
más concreta y extensa todos los aspectos técnicos de
administración de una lista y se produzca una comunicación fluida
entre los administradores y el equipo responsable de este servicio de RedIRIS.
Asistieron unos 35 administradores de listas y otras 10 personas responsables
de comunicaciones de varias Universidades. El debate fue de gran
interés y hubo una participación más intensa que la que
tiene lugar a través de la lista de administradores, ADMIN-L.
La sesión estuvo dividida en 4 partes:
Se repasaron los objetivos del Servicio a la comunidad académica,
científica y educativa española (trasparencia 1). Se explicaron
claramente los recursos que existen en la actualidad para que el servicio
funcione de forma óptima (trasparencia 2). Se intentó explicar de
forma simple, el funcionamiento técnico en la distribución del
correo en las listas (trasparencia 3), tema importante para tener claro las
responsabilidades en caso de fallos de recepción en el correo
distribuido, tantas veces consultado a RedIRIS.
Se hizo especial hincapié en el Servicio hacia los administradores de
listas (trasparencias 4 y 5), verdadero corazón del Servicio. Se
repasaron los servicios que se les viene ofreciendo y se consultó
qué otros servicios podrían serles ofrecidos. Entre los servicios
más demandados está la posibilidad de disponer de una base de
datos de los suscriptores. RedIRIS está pensando en utilizar el Servicio
de Directorio de RedIRIS para la gestión de los suscriptores de las
listas, poniendo a disposición de los administradores herramientas de
gestión vía LDAP para PCs. Esta propuesta será conveniente
divulgada en su momento.
El resto de la exposición fue un repaso de las últimas novedades
tanto para la gestión de la propia lista como para nuevas opciones a
suscriptores.
Este fue el tema de central de la reunión presentado de forma brillante
por:
Ángel Velasco (UNED), administrador de la lista LAPEPA (Historia
Contemporánea de España) expuso su propia experiencia como uno de
los editores de la revista electrónica HISPANIA NOVA, y en la
obtención del ISSN para este tipo de revistas no disponibles en formato
papel.
Desde el punto de vista de RedIRIS el tema de las publicaciones es de sumo
interés. Los archivos de las listas son filones de información de
gran valor. Se necesitaría una labor de recopilación, filtrado y
formateado de esta documentación para la elaboración de este tipo
de publicaciones. Es decir el contenido existe, sólo falta darlo forma
de publicación o boletín. Según fue planteado en la
reunión el problema para llevarlo a cabo es la disponibilidad del
persona, para ello es necesario la creación de un comité
"virtual" de redacción seleccionado entre voluntarios de la propia
lista. Evidentemente las ideas plasmadas en la exposición de Fernando no
son mandatorias y cada uno debe de seleccionar las que más le interesen.
El tema queda abierto a futuros comentarios e ideas.
Fco. Javier expuso su particular punto de vista sobre el funcionamiento de la
lista. LERPIA considerada una herramienta útil para el desarrollo
científico de los participantes. Cuenta con pocos suscriptores y
tráfico pero suficiente para considerar la herramienta productiva por
parte de su administrador. Los objetivos del administrador de dicha lista se
alejan del concepto convencional que los administradores tienen de las listas
(número de suscriptores, aportaciones. moderación etc.)
En esta exposición se consolidó la idea de la gran diferencia
existente entre entornos llamados de ciencias puras (física,
matemáticas, etc) y humanidades. Es un tema que merecería un
estudio en profundidad.
Le reunión se cerró en espera del anuncio de la próxima
convocatoria para finales de este año coincidiendo con las Jornadas
Técnicas de RedIRIS 1998.
En el último Boletín publicado (Nº 43)
apareció una noticia en la sección de Actualidad sobre el
problema del Abuso en el Correo Electrónico (ACE). Desde entonces se ha
ido avanzando dentro de la Comunidad de RedIRIS, principalmente a nivel
técnico y de concienciación, dos de los cuatro pilares
fundamentales para atajar el problema. Los otros dos niveles son el informativo
y el de coordinación. Sobre la coordinación se han
diseñado una serie de mecanismos que se anunciarán en su momento
y que posiblemente se amplíe a otros proveedores nacionales. El nivel
informativo es el que se pretende describir en esta noticia.
No sólo se debe informar al usuario final sobre el problema del ACE,
sino también suministrarle mecanismos sencillos y ágiles para
canalizar las denuncias de forma activa o a través de su proveedor del
servicio institucional.
En este apartado se considera la necesidad de un documento oficial sobre la
política de una organización frente a este hecho. Para hacerse
una idea correcta del objetivo de este tipo de documento se puede consultar el
corres-pondiente al Centro de Comunicaciones CSIC RedIRIS en la siguiente
dirección:
Sus objetivos son:
Imaginemos a un usuario de una Universidad que se dedicara a distribuir correo
electrónico publicitario por la red o cometiera cualesquiera de los
tipos de ACE.
Quedan pendientes de respuesta algunas preguntas:
Documentación relacionada:
Se anunció la finalización de dos grupos de trabajo que durante
algo más de un año han estado trabajando a un ritmo muy bajo:
IRIS-MIME y FOROS-ES.
El grupo de trabajo IRIS-MIME cuyos objetivos han sido el ayudar a seleccionar,
configurar y probar programas de correo electrónico con todo el
potencial de los estándares MIME, se han cumplido a medias. El problema
que más afectó al funcionamiento de este grupo fue la
aparición de nuevos programas de correo electrónico más
sencillos de configurar y gestionar tales como Comunicator, Outlock, nuevas
versiones de Eudora, etc... Con estos nuevos paquetes el usuario no debe saber
practicamente lo que es MIME para enviar y recibir correo. A pesar de ello
siguen existiendo problemas de compatibilidad en la transferencia de ficheros
anexos (ej. Word) además de una serie de irregularidades de estilo que
se resumen en pensar "que todo el mundo utiliza programas de Microsoft". Se
escribió un pequeño documento sobre "Normas de estilo en el
Correo Electrónico" ( http://www.rediris.es/mail/estilo.html) donde se
incluyen recomenda-ciones genéricas y se intentan rectificar algunas de
las configuraciones por defecto de los actuales programas. Como colofón
de este grupo de trabajo queda por desarrollar una nueva versión
actualizada del catálogo de productos de correo electrónico.
Otro de los grupos de trabajo que se dieron por finalizados fue FOROS-ES que
pretendía divulgar la implantación de un servicio sencillo y muy
útil al mismo tiempo que coordinar una sistema de listas de
distribución en la Comunidad de RedIRIS. Como conclusión de este
grupo se han hecho una serie de recomendaciones recogidas en la siguiente
dirección:
Se anunció el fin del servicio de pasarela SMTP<-->X.400 que
RedIRIS ha venido ofreciendo desde sus orígenes, allá por 1988.
El último eslabón era el MTA que unía a RedIRIS con el
proyecto ISTMO (Implantación de un Sistema de Mensajes para soporte a
Organizaciones de la Administración) a través de un servidor
X.400 en el MAP (Mº de Administraciones Públicas). A
partir del 1 mayo de 1998 es el propio MAP quien ofrece este servicio que desde
hace 2 años, practicamente ninguna organización de RedIRIS ha
venido usando. Con él finaliza la conectividad con 400net de TSAI
(antiguo Mensatex) y la conexión con el servicio MailFlow de Terena.
RedIRIS dentro del servicio de correo electrónico, intenta mirar al
futuro y uno de los temas que encuentra más apasionantes son los
servidores de correo de nueva generación, más potentes,
más seguros, más robustos, más versátiles y
más rápidos que los existentes. Servidores abiertos,
estandarizados, no propietarios, de dominio público y con amplio
respaldo internacional. En esta línea Rubén Martínez
(RedIRIS) hizo una breve presentación de uno de los servidores mejor
posicionados: VMailer, actualmente en un estado beta. Este producto es
compatible con el servidor Sendmail de Berkeley. La intención de RedIRIS
es organizar un pequeño grupo para intentar trabajar con el Vmailer. A
través de la lista IRIS-MAIL se enviará más
información sobre este tema.
Durante el resto del tiempo se trataron ampliamente todos los aspectos
relacionados con el Abuso en el Correo Electrónico (ACE) en los que se
ha venido trabajando desde la reunión de Zaragoza. La exposición
del coordinador de RedIRIS se centró en la necesidad de definir
políticas institucionales frente al ACE (Ver noticia anterior). Los dos
puntos restantes de este aspecto fueron:
Nuestro objetivo es permitir que se puedan realizar búsquedas bajo
España sin la necesidad de tener que especificar una localización
geográfica ya que uno de los problemas más frecuentes a la hora
de encontrar los datos de una persona es que no conocemos su ubicación
física. Por esta razón nos resulta complicado usar el Directorio
X.500 para este propósito.
En la reunión se trató este problema y se analizaron las posibles
soluciones para que una persona pueda realizar búsquedas integradas.
Se trataron tres posibilidades:
El primero pretende la evolución hacia una arquitectura basada en
servidores LDAP de bajo precio, fáciles de manejar y de ampliar que nos
permitan generar unos índices con la información que contienen
para poder realizar las búsquedas por estos índices y agilizar el
servicio.
El segundo se basa en servidores Whois++ y también se generan
índices de la información contenida en cada servidor para poder
agilizar las consultas.
RedIRIS intentará participar en el piloto NameFLOW LDAP y, aunque se
planteó montar un pequeño grupo de trabajo basado en servidores
Whois++, no se va a realizar por el momento, debido a la imposibilidad de
encontrar centros interesados.
Otra de las actividades ha sido la colaboración con el desarrollado de
la pasarela web500gw para que incluya algunas opciones nuevas y una
versión en castellano.
Se comentó que tenemos disponible la versión 4.0 del software de
Directorio que RedIRIS distribuye entre sus centros afiliados. Esta
versión soporta conexiones LDAP sin necesidad de una pasarela
adicional.
Hemos traducido y adaptado a nuestras necesidades el documento original donde
se definen los 15 elementos de Dublin Core y se ha informado de la existencia
de ese documento a los centros que se encargan de realizar herramientas de
gestión de meta-información. De esta forma podremos utilizar esas
herramientas en castellano.
Hemos decidido modificar las herramientas de generación de
meta-información que teníamos para adaptarlas a estas nuevas
especificaciones.
Se indexarán:
A nivel internacional TERENA ha creado un piloto de indexación en el que
se plantean los mismos objetivos que en España. Su intención es
proporcionar calidad en las búsquedas usando exclusivamente
meta-información en las páginas que indexen.
La estructura que montarán podrá redirigir las preguntas por la
red de servidores indexados hacia los nodos que puedan contestar correctamente
dichas preguntas, es decir, se distribuirá la información y se
distribuirán las consultas de forma transparente al usuario.
Para ello se crearán bases de datos de conocimiento para conocer
qué servidores pueden tener la respuesta a las consultas y protocolos de
enrutado de consultas.
En cuanto a las herramientas disponibles se llegó a la conclusión
de la necesidad de una que sea capaz de extraer la información clave de
cada página. Esto es bastante complicado y, aunque hay personas
trabajando en estas tareas, por ahora usaremos las herramientas que nos
preguntan esta información y la incorporan automáticamente a las
páginas.
Son dos principalmente los Servicios de información en Internet que se
ven afectados, Correo Electrónico (ver noticia anterior) y NetNews
(Grupos de Discusión). Los mecanismos de abuso de estos dos Servicios
son distintos, pero quizás se puede hablar de una política en
contra del abuso, que sea común en ambos. Sin embargo me centraré
en los aspectos relativos al abuso en las NetNews, exponiendo las medidas
actualmente adoptadas y las nuevas iniciativas que se están produciendo
en la 'lucha' contra el 'spam', que pueden conducirnos al establecimiento de
unas normas o medidas 'anti-abuse''más estrictas que las presentes.
En concreto y como ejemplo de iniciativa, la propuesta inicial para determinar
que qué artículos son inaceptables en la jerarquía es.*
preseentada al CORUS-ES por uno de sus miembros `Julio Sánchez' fue la
siguiente:
"...
La decisión acerca de si son "substancialmente idénticos" o no,
suele realizarse sobre los cuerpos de los mensajes y las cabeceras suelen ser
algo secundario. Algunos de los grandes detectores no miran las cabeceras en
absoluto.
Una regla más: El Make Money Fast es "kill-on-sight", todas las copias
de cualquier MMF se consideran "substancialmente idénticas".
Bien, el status quo es el siguiente:
Se pretende por tanto establecer gracias a iniciativas como esta, unas medidas
que garanticen de una forma más eficaz e `inteligente' para lograr
rechazar los tan molestos mensajes que constituyen spam o abuso, y poder
proteger los contenidos de los newsgroups y por tanto la vida de las News.
Por estas razones y motivado por otras circunstancias infraestructurales por
las que se ha pensando y planificado reconfigurar el sistema actual y
convertirlo en un SAD plenamente independiente, eficaz y fiable.
Así pues el SAD que se propone, en resumen será un sistema basado
en dos servidores primario y secundario) con DIABLO como SW de NetNews, y un
control (scripts) que serán capaces de hacer asumir a uno u otro
servidor el conjunto global de los `feeds' que se mantienen en servicio. Cabe
decir que este Sistema de Alta Disponibilidad presentará las mismas
interfaces (nombres IP) que las que hasta ahora deben tener los Centros
configurados (news.rediris.es, news-atm.rediris.es, news-2.rediris.es), en este
sentido el servicio no sufre ninguna alteración.
Como se puede comprobar en la página de miembros del Newsbone, cada vez
hay más redes o ISPs que solicitan unirse al backbone de News europeo.
Hay que recordar que RedIRIS fue la primera Red operativa conectada al Newsbone
aparte de nuestros anfitriones de SWITCH. Se planteó una
relajación en los requisitos de conexión al Newsbone europeo.
Existe una necesidad imperiosa de disponer de herramientas de
monitorización, que contrariamente a las que acompañan al SW de
los servidores actuales (o las ya diseñadas para la necesidad de estos),
nos den información de trafico para cortos períodos de tiempo. Se
plantea la necesidad de homogeneizar la presentación de las
estadísticas de trafico, así como de disponer de las mismas para
servidores basados en INN.
Parece que el proyecto NewsFlow se ha estancado por falta de voluntarios. Este
proyecto consiste en el estudio de los patrones de distribución del
tráfico de NetNews en función del análisis de las
cabeceras "Path" de los artículos. A partir de este análisis se
crean unos mapas de distribución donde se ve el recorrido que siguen los
artículos desde su origen hasta sus destinos y los bucles formados en su
ruta.
Se marcaron los siguientes objetivos en el Grupo de trabajo:
La idea de este proyecto es el uso de mecanismos de sincronización para
la actualización de listas de distribución en función de
parámetros globales, esto es, puntos centrales de información en
los que obtener las listas actualizadas y oficiales para cada jerarquía
distribuida. En principio se propone aplicar esto a las jerarquías de
cada país (es*, fr*, de*, uk*...) y en función de los resultados,
extenderlo o no al resto de la Usenet.
Esta es una iniciativa para intentar evaluar las pérdidas de
artículos que se producen entre servidores. Dado el gran volumen que se
está manejando en la actualidad (14Gb/día, 400Kart/día)
que supone un full-feed, existen servidores que descartan artículos para
evitar crecimientos excesivos de sus colas de envío, bien porque
dispongan de poco espacio de spool, etc...
Los usuarios o clientes están convencidos de que estas pérdidas
se producen. Para poder evitar esto es necesario en primer lugar evaluar
dónde se producen perdidas y cuál es la magnitud de las mismas.
Este es el objetivo de este nuevo proyecto del NetNews-Working Group.
Las ideas expuestas por Gerhard Winkler (ACONET) para abordar esta tarea, se
basan en la emisión de mensajes de prueba y comprobación de la
recepción de los mismos en el resto de servidores (inyección de
carga de prueba). Aquellas personas interesasas en participar en el proyecto
pueden ponerse en contacto con él directamente (pedir su
dirección a Daniel Díaz).
Coordinado por Leigh Porter (WHISPER). Se ofreció como voluntario para
redactarla y espera la contribución de todos los newsmanagers que
conozcan INN).
Este tema en el Newsbone es preocupante, delicado de aplicar de forma
generalizada debido a las diferentes políticas de uso en cada red de
este servicio. En el WG se hizo una presentación de los diferentes tipos
de SPAM y de algunas formas de combatirlo...
Uno de los temas a tratar, visto el funcionamiento satisfactorio que
están teniendo las cachés, era el estudiar las políticas
que se pueden aplicar a nivel de cada organización para favorecer un uso
más extendido de las cachés por parte de los usuarios finales. La
primera alternativa, que pasa por una organización de aulas que
garantice una configuración de los clientes apropiada en todas las
máquinas fue expuesta por José Luis Hernández de la
Universidad Carlos III. El esquema utilizado en la Universidad Carlos III y
algunas otras universidades como la UPV, consiste en fijar todos los
parámetros de los navegadores en el momento en que los usuarios entran
en la red obligatoriamente a través de un servidor NT
ejecutándose un LOGON script. Otras universidades que utilizan este
esquema comentaron la existencia de un kit básico de servicios de red
sobre el que dan soporte y que se configura bien por el mecanismo anterior o en
el servidor al utilizarse desde máquinas sin disco duro.
Las otras alternativas ya tratadas en ocasiones anteriores son el filtro en el
puerto 80 y las cachés transparentes. Se estuvieron comentando los pros
y contras de estas últimas, a saber: capturan, sin configurar nada el
usuario, todo el tráfico al puerto 80, pero sólo a ese puerto (no
FTP, ni Webs en otros puertos) y todos los aspectos técnicos asociados:
redirección por hardware y las configuraciones necesarias.
Se trató el tema de la precarga de páginas viendo dos posibles
esquemas: la carga de los documentos más accedidos en horas de poco
tráfico (por la noche) y los formularios que permitan al usuario
determinar URLs que quiera asegurarse de que estén al día
siguiente en el grupo de cachés, apareciendo aquí el problema de
cuantos enlaces traerse a partir de un URL determinado. Discutimos el problema
de los tiempos de refresco asociados a la precarga, dada la poca utilidad que
tiene traerse los documentos si al cabo de una hora los accesos van a provocar
peticiones IMS para cotejar la validez, que si bien cargan menos la red que las
peticiones normales, dado el estado actual de la red provocan un retardo al
servir el documento al cliente.
Hablamos de la consolidación del servicio de proxy-caché en
RedIRIS basándolo en las cachés oficiales corriendo versiones
estables de Squid, los scripts de autoconfiguración y un script que
queda pendiente de hacer para tirar abajo las cachés que no estén
dando unos tiempos de respuesta adecuados; esto implica que todas tengan una
caché de backup. La idea es dejar un servicio estable y seguir
experimentando con una red de cachés separada que vaya probando Squid
1.2, intentar aplicar compresión de datos y conexiones persistentes
entre las cachés, jugar con las URNs y el enrutado en base a
números de sistemas autónomos (AS) y sobre todo substituir la
comunicación entre cachés vía ICP que genera una
importante sobrecarga por el nuevo mecanismo de Cache Digests en Squid 1.2.
Por último Luis Alberto Velasco hizo una exposición sobre los
resultados que han obtenido en el Grupo de Sistemas Inteligentes del DIT en la
UPM y que mediante simulación de tráfico y distintos
parámetros muestran los beneficios de la compresión de datos,
sobre todo en líneas de poca capacidad donde el retardo de
transmisión hace nimio el tiempo de
compresión/descompresión.
RedIRISdial es el servicio RedIRIS a través del cual se proporciona una
conectividad adecuada a aquellos centros afiliados a RedIRIS con un
número pequeño de usuarios.InfoVía en RedIRISEscenario previo de RedIRISdial
Hasta el pasado mes de febrero, el Servicio se proporcionaba con el mecanismo
anteriormente comentado. Estas conexiones sólo eran posibles vía
RTB, dichas conexiones se efectuaban desde los distintos Centros afiliados
mediante módems, pudiendo obtenerse hasta 28.800 bps. (max. velocidad de
transferencia de los módems del pool de RedIRIS). Uno de los
inconvenientes de este sistema de conexión es el coste de la llamada,
sobre todo cuando era de tipo provincial o nacional. Otro de los defectos del
Servicio era la imposibilidad de conectar estas pequeñas organizaciones
a través de RDSI (Red Digital de Servicios Integrados), ya que RedIRIS
no dispone de estos accesos.Acceso a través de InfoVía al servicio RedIRISdial
RedIRIS en base a los objetivos del Servicio RedIRISdial, y a una necesidad
creciente de dar un acceso más flexible y económico a los Centros
afiliados que no disponene de una conexión permanente, comienza a
finales de 1996 la configuración de la conexión a InfoVía.
Para ello solicitó administrativamente dicha conexión al Centro
de Gestión InfoVía (CGIV). Por diversos motivos no se lleva a
cabo la configuración a nivel técnico para poder proveer de
conexión a través de InfoVía hasta el pasado mes de
febrero.
El servicio RedIRISdial, gracias a este método de acceso, ofrece un
servicio de mayor calidad que el que hasta el momento se venía dando,
por diversos motivos. El primero y más evidente es el bajo coste de
conexión que el acceso a través de InfoVía supone,
especialmente cuando el Centro que se conecta se encuentra fuera de la
Comunidad de Madrid. Una segunda ventaja es la mayor flexibilidad en cuanto a
las opciones de conexión por parte del cliente. Existe un abanico de
posibilidades de configuración de la conexión por parte del
Centro que se desee conectar: acceso vía RTC RDSI, bien accediendo un
único usuario con su módem o su tarjeta RDSI, bien conectando
toda una LAN a través de un PROXY (InfoLink+Linux, OpenSesame +NT/W95), así como a través de un router, agregando incluso accesos
básicos RDSI en caso de necesitarse un mayor ancho de banda, etc...
Conclusiones
En definitiva esta nueva posibilidad, aumenta las posibilidades de
conexión por parte de Centros Afiliados de las características
indicadas, ofreciéndoles un mayor abanico de posibilidades, así
como las ventajas de un mayor control y seguridad por parte de RedIRIS, una
conexión más fiable, y un coste considerablemente menor,
principalmente en caso de encontrarse fuera de la Comunidad de Madrid.
daniel [dot] diaz [at] rediris.es
jesus [dot] heras [at] rediris.es
Este Congreso constituye una de las primeras experiencias en España en
la organización de congresos virtuales. La primera convocatoria
contó con el soporte técnico del Centro Informático y de
comunicaciones (CICEI) de la Universidad de Las Palmas de Gran Canaria (ULPGC)
y obtuvo un gran éxito. En esta ocasión la colaboración la
ofrece la Universidad de Castilla-La Mancha conjuntamente con RedIRIS.II Congreso Virtual Hispanoamericano de Anatomía Patológica
jesus [dot] heras [at] rediris.es
Enfocada a los administradores de listas de RedIRIS tenía como principal
objetivo exponer los aspectos técnicos del servicio, debatir sobre
cómo obtener mayor calidad en los contenidos de las listas, intercambio
de experiencias y otros temas que surgieran. Fue la primera vez que RedIRIS
organiza un aconteciemiento de este estilo donde los asistentes y ponentes
fueron científicos, docentes o investigadores que apostaron en su
día por este Servicio de listas.I Reunión de Administradores de listas de RedIRIS
Admin. del Foro de Debate PROACTIVIDAD
Universidad Autónoma de Madrid
Departamento de Geografía
jesus [dot] heras [at] rediris.es
Políticas institucionales frente al Abuso en el Correo Electrónico
El documento intentaría cubrir estas y otras lagunas
constituyéndose en un instrumento público e institucional, simple
de escribir pero ... ¿difícil de aprobar por los
máximo responsables institucionales?.
Considero que independientemente de las respuestas a estas cuestiones
debería ser atacado el acúciente problema del correo
electrónico, con un política clara, pública y oficial
acerca del problema del ACE.
Compromiso institucional acerca del problema del ACE:
http://www.rediris.es/mail/abuso/insti.es.html#doc
http://www.rediris.es/mail/abuso/user.html
jesus [dot] heras [at] rediris.es
Se contó con la asistencia de unas 50 personas y el tema central del
grupo de trabajo fue el Abuso en el Correo Electrónico, actualmente el
problema más grave que nos afecta.Grupo de trabajo IRIS-MAIL
jesus [dot] heras [at] rediris.es
La reunión se dividió en dos partes, una dedicada al
servicio de Directorio, y otra al grupo de trabajo sobre indexación.Reunión de Coordinación IRIS-SEARCH 1.- Servicio de Directorio
Actualmente cuando una persona está escribiendo un mensaje de correo
electrónico y tiene la necesidad de conocer la dirección del
destinatario del mensaje puede realizar una búsqueda en alguna base de
datos (como el Directorio X.500) desde el mismo programa de correo
electrónico.
Se analizaron otros proyectos existentes como el Piloto NameFLOW LDAP y la
creación de una Red de servidores Whois++.Referencias:
http://www.dante.net/np/LDAP-meeting.txt
http://www.tu-chemnitz.de/~fri/web500gw / 2.- Grupo iris-index
Cada día parece más claro que si queremos encontrar
información en la red de una forma eficiente tenemos que describir los
recursos que ponemos en la misma. Para la descripción de recursos
existen diversas especificaciones. El grupo decidió usar un conjunto de
15 elementos del grupo Dublin Core.
Una vez definido el formato de meta-información vamos a realizar un
piloto de indexación con información válida. El objetivo
principal será indexar todos los documentos que incorporen
meta-información para poder realizar búsquedas basándonos
en ella.
Dispondremos de un interfaz de consulta en RedIRIS desde donde podremos
seleccionar los atributos por los que queremos preguntar.Referencias:
http://www.rediris.es/metadata/dublin_core_elements.es.html
http://www.terena.nl/projects/chic-pilot
http://metadata.net/
masa [at] rediris [dot] es
En los años en los que Internet daba sus primeros pasos, no se
podía intuir el grado de abuso que determinados Servicios podrían
sufrir por parte de los usuarios; o quizás las dificultad que
suponía el hecho de haber tenido en cuenta este posible 'abuso' hizo
prevalecer el pragmatismo en la implementación de los protocolos que
usamos hoy día. En la actualidad, creo que se podría afirmar que
prácticamente ningún usuario de Internet ignora lo que se llama
ya de forma coloquial 'spam'. Entre otros motivos porque a 'ese' usuario le
afecta de forma directa en el momento que recibe en su buzón de correo
electrónico determinados mensajes de tipo comercial una y otra vez,
especialmente cuando dicho usuario esté conectándose vía
módem, etc., y deba pagar por recibir mensajes que no desea recibir.Iniciativas contra el abuso en las NetNews Medidas Anti-Spam adoptadas hoy en día en las NetNews
Desde hace ya un tiempo, en RedIRIS se ha tenido muy en cuenta este grave
problema, ya que produce una perdida progresiva de los contenidos de los
newsgroups que se distribuyen. Este abuso en las NetNews tiene o puede tener
lugar de diversas formas:
La preocupación sobre este problema en el caso concreto de las NetNews
se concreta en el establecimiento de una serie de normas. Limitación del
número de mensajes cruzados a 10 grupos por artículo (ECP<10).
Limitación del tamaño de artículo a menos de 300 Kbytes.
Límite del EMP mediante filtrado de los artículos en
función de los campos 'Subject''y 'From'.
Iniciativas anti-abuse en las NetNews para la adopción de unas medidas
más estrictas.
En foros como el del grupo de trabajo de NetNews del Newsbone europeo, se
expresa la preocupación por este problema, pero no se llega a una
decisión ejecutiva respecto a la aplicación de unas normas de
tipo general anti-spam. Sin embargo existen iniciativas como las propuestas
por miembros del CORUS-ES (Comité Regulador en Usenet de la
Jerarquía es.*). En concreto gracias a miembros de este comité
como Julio Sánchez y la puesta en común con el resto de
componentes del mismo, se están elaborando propuestas para combatir el
`spam' de una forma más eficaz a como actualmente se están
llevando a cabo. Iniciativas como estas es posible que nos lleven a proteger de
una manera más `inteligente' a la actual el contenido de los grupos que
desde los distintos News-Servers se distribuyen.
Son artículos "substancialmente idénticos" aquellos que:
Es decir que, salvo en el caso de que anuncien algo, tienen que ser casi
idénticos. Periódicamente surgen nuevos tipos de abuso y, si hay
suficiente consenso, se extienden las reglas. Pero hace bastante que no han
cambiado, la regla de "anuncian el mismo servicio" da mucho juego. No todo lo
que se propone se acepta. Por ejemplo, se es consciente de que las agencias de
colocación que vuelcan sus bases de datos en los grupos de anuncios
representan un mal uso de esos grupos y los han matado, pero no se llegó
a consenso y, por tanto, no se están cancelando excepto en los casos
(como headhunter.net) en que están incurriendo en EMP de todos modos.
...."
daniel [dot] diaz [at] rediris.es
Siempre es deseable cuando se da un servicio, sea el que sea, que éste
disponga de cuantos recursos precise con el objetivo de ofrecerlo de la forma
más segura, tolerante a fallos y eficaz posible. Esto es algo que
siempre se ha pretendido desde la coordinación de este servicio en
RedIRIS. Desde el pasado año hasta hoy día se ha podido disponer
de un Sistema de Alta Disponibilidad (SAD) controlado de forma manual,
opción que con el nuevo sistema se pretende evitar, ofreciendo un
servicio más fiable. Por otra parte como se explica a
continuación el actual SAD dispone de INN en el primario de news como
software de NetNews y de DIABLO en el secundario, lo que impide una
automatización sencilla. Esto dejará de ser así migrando
el primario a DIABLO, con lo que además de una mayor fiabilidad ofrecida
por el control automático, se dispondrá de un servicio mucho
más eficaz.Sistema de Alta Disponibilidad para el Servicio de Netnews Escenario previo
Como ya se ha comentado en la introducción de este artículo, el
escenario actual desde finales del año 97 consiste en un sistema basado
en dos servidores news y news-2, primario y secundario respectivamente del
servicio de NetNews. El servidor primario (news.rediris.es) con INN-1.7.2 como
software de NetNews distribuye artículos a todos los Centros regionales,
internacionales y comerciales. El servidor secundario (news-2.rediris.es) con
DIABLO como software de News distribuye a todos los Nodos de Madrid. Se dispone
de scripts que permiten asumir el control por uno u otro servidor
indistintamente. Ambos en teoría serían capaces de asumir el
servicio en caso de que se produjera una caída de uno u otro servidor,
pero en la práctica, en el caso de que fuera el servidor primario
(news.rediris.es) el que cayera, el servidor secundario (news-2.rediris.es) no
podría dar un rendimiento eficaz, con posibilidades de caer por
problemas de espacio en disco, aumento de la contención (uptime) en CPU
etc.. Sistema propuesto (SAD en RedIRIS). Escenario general
El sistema propuesto consiste en un nuevo enfoque que perfeccione la
filosofía que ya se adoptó en su momento. En primer lugar se
pretende eliminar una condición que dificulta enormemente la
implementación de un SAD actualmente, esta condición es la
asimetría existente en la configuración de ambos servidores (news
y news-2) cuyo SW como ya se ha descrito son INN y DIABLO respectivamente. Esto
se conseguiría instalando también DIABLO como SW de NetNews en el
servidor primario. Asimismo hay que tener en cuenta que DIABLO en principio no
da servicio a lectores (acceso a clientes o 'newsreaders'); para salvar esta
contrapartida que las actuales versiones de DIABLO tienen, se dispondría
de un PC Industrial de altas prestaciones que reemplazaría al actual
terciario de News (news-3.rediris.es), cuya adquisición está en
estudio, en el que se instalará INN, y se podrá dar así un
acceso a lectores fiable y garantizado.Conclusiones
Las verdaderas conclusiones sobre la implantaciòn de este Sistema de
Alta Disponibilidad, sólo las podremos ofrecer realmente cuando se hayan
hecho pruebas con el mismo, y evaluado su operatividad. Hoy por hoy es
lógico pensar que si dado el magnífico resultado que está
dando el SW DIABLO en el servidor secundario de news, se podrá tener un
Sistema mucho más eficaz y que además nos permita de una forma
sencilla establecer un control que implemente el Backup del servicio.
daniel [dot] diaz [at] rediris.es
Durante este grupo de trabajo se trataron los siguientes temas:Grupo de Trabajo IRIS-NEWS
Grupo de trabajo de RIPE sobre NetNews
Esta reunión tuvo lugar en Amsterdam, a finales de enero de este
año.
Las áreas de trabajo son:
Nuevos proyectos dentro del Grupo de Trabajo:
Evolución local del servicio de NetNews de RedIRIS:
daniel [dot] diaz [at] rediris.es
Empezamos esta última reunión del grupo de trabajo IRIS-CACHE
repasando el estado actual del grupo: más de cincuenta cachés WWW
instaladas en las organizaciones afiliadas a RedIRIS y un grado bastante
aceptable de redundancia gracias por un lado a la comunicación por ICP
entre cachés (resistencia a caídas de las cachés) y a los
scripts de autoconfiguración en los clientes, soportando cachés
de backup si falla la principal, o incluso acceso directo en caso de mayores
problemas.Grupo de Trabajo IRIS-CACHE
javier [dot] puche [at] rediris.es
Indice General
![[Índice General]](../logopuente_boletin.gif){kind=small}