CONTENIDOS

1 Introducción	8

1.1 Acerca del proyecto	8

1.2 Acerca de esta guía	9

1.3 Como usar esta guia	10

1.4 Información para los que toman decisiones...........	12

1.4.1 Recomendaciones generales	12

1.4.2 Migración por continuación y por sustitución	12

1.4.3 Pasos de la migración	13

1.4.4 Alternativas de comparación	13

1.4.5 Futuros aspectos claves	14

1.4.6 Rendimiento económico	15

2 Aspectos clave de la guía de migración	17

2.1 Definiciones importantes	17

2.1.1 Código abierto, software libre	17

2.1.2 Software propietario	17

2.1.3 Software Linux comercial	17

2.1.4 Migración por continuación	17

2.1.5 Migración por sustitución	18

2.2 Pasos de la migración	18

2.1.6 Microsoft Windows como la situación inicial	19

2.1.7 Entorno del sistema con migración por sustitución	21

2.1.8 Entorno del sistema con migración por continuación	22

2.1.9 Dependencias internas sin el entorno del sistema Microsoft	23

2.3 Distribuciones de Linux	25

2.1.10 Introducción	25

2.1.11 Debian GNU Linux	27

2.1.12 Distribución SuSE Linux	28

2.1.13 Distribución Red Hat	29

2.1.14 Certificaciones	29

2.1.15 Conclusiones	31

2.4 Modelos de licencias

2.4.1 GPL

2.4.2 GPL reducida

2.4.3 Licencia BSD

2.5 Origen de los Datos

2.5.1 Experiencias con proyectos de migración.

2.5.2 Experto en integración.

3. Descripción técnica de los pasos de la migración

3.1 Introducción

3.2 Sistemas de ficheros

3.2.1 Aspectos generales

3.2.2 Windows NT 4

3.2.3 Migración por sustitución

3.2.4 Migración por continuación

3.3 Servicio de impresión

3.3.1 Aspectos generales

3.3.2 Introducción

3.3.3. Punto de partida – imprimir bajo Windows NT 4

3.3.4 Migración por sustitución

3.3.5 Migración por continuación

3.4 Servicios de autenticación

3.4.1. Aspectos generales

3.4.2 Punto de partida – Windows NT 4

3.4.3 Migración por sustitución – Linux, Samba y OpenLDAP

3.4.4 Migración por continuación

3.5 Servicios de red

3.5.1 Aspectos generales

3.5.2 Punto de partida – servicios de red bajo Windows NT 4

3.5.3 Migración por sustitución – servicios de red bajo Linux

3.5.4 Migración por continuación - servicios de red bajo Windows 2000

3.6 Auditoría del sistema y mantenimiento de servicios

3.6.1 Aspectos generales

3.6.2 Punto de partida – servidor de mantenimiento de sistemas bajo Windows NT 4

3.6.3 Migración por sustitución –Linux

3.6.4 Migración por continuación - Windows 2000

3.7 Servicio de directorio

3.7.1 Aspectos generales

3.7.2 Fundamentos

3.7.3 Servicio de directorio activo (ADS)

3.7.4 Migración por sustitución – Samba, OpenLDAP

3.7.4 Migración por continuación – Introducción de ADS

3.8 Middleware – COM, .NET, J2EE

3.8.1 Modelo de objetos de componentes (COM)

3.8.2 “.NET”

3.8.3 Java 2 Enterprise Edition (J2EE)

3.9 Servicios Web

3.9.1. Aspectos generales

3.9.2 Fundamentos

3.9.3 Servicios web .NET

3.9.4 J2EE

3.10 XML (eXtensible Markup Language)

3.11 Servidores Web

3.11.1 Aspectos generales

3.11.2 Introducción

3.11.3 Internet Information Server 4.0 (IIS 4.0)

3.11.4 Migración por sustitución

3.11.5 Migración por continuación

3.12 Portal de servicios Sharepoint

3.12.1 Aspectos generales

3.12.2 Introducción

3.12.3 Foros

3.12.4 Document Management System (DMS)

3.12.5 Funciones de búsqueda

3.12.6 Conclusiones

3.13 Bases de Datos

3.13.1 Aspectos generales

3.13.2 Introducción

3.13.3 MS SQL Server 7.0

3.13.4 Migración por sustitución

3.13.5 Migración por continuación

3.14 Groupware

3.14.1 Aspectos generales

3.14.2 Introducción

3.14.3 Situación inicial – Microsoft Exchange 5.5

3.14.4 Migración por sustitución

3.14.5 Migración por continuación

3.15 Office / Escritorio

3.15.1 Aspectos generales

3.15.2 Introducción

3.15.3 MS Office : situación inicial

3.15.4 Migración por sustitución

3.15.5 Migración por continuación

3.15.6 Más aplicaciones de escritorio

3.15.7 Integración de aplicaciones Windows en unión con clientes Linux.

3.15.8 Evaluación

3.16 Servidores de terminales y clientes ligeros

3.16.1 Aspectos generales

3.16.2 Introducción

3.16.3 Proyecto de servidor de terminales Linux

3.16.4 Servidor de terminales NX

3.16.5 Servidores de terminales Windows y Citrix

3.17 Alta disponibilidad

3.17.1 Propósitos

3.17.2 Los “cinco nuevos” y la realidad

3.17.3 La aproximación

3.17.4 Categorías de los sistemas HA (de alta disponibilidad)

3.17.5 Software propietario HA (de alta disponibilidad)

Software de HA de código abierto	269

4	Evaluación de la eficiencia económica......................................................271

Introducción	271

Principios metodológicos	272

4.2.1 Análisis monetario	273

4.2.2 Análisis de beneficios	273

4.2.3 IT-Wibe 21 (recomendaciones sobre supuestos de eficiencia económica para sistemas de TI)	273

4.2.4 Matriz de costes de migración	274

4.2.5 TCO	275

4.2.6 Comparabilidad	275

4.2.7 Nueva introducción vs. migración de sistemas	276

4.2.8 Aproximación por coste total	277

La dimensión (operativa) monetaria	278

4.3.1Aplicaciones	278

4.3.2Categorías de costes	278

4.3.3Características de las categorías aplicadas para agencias públicas	279

Dimensión estratégica	281

4.4.1Discución macro económica	281

4.4.2Discusión micro económica	281

Resultados finales de la evaluación de la eficiencia económica	282

Recomendaciones de migración, basados en la evaluación de la eficiencia económica	283

4.6.1Migración completa	285

4.6.2Migración de continuidad	286

4.6.3Migración parcial	286

Conclusiones	289

Gastos con diferentes escenarios de migración	289

4.8.1Suposiciones generales en relación con los costes de migración	289

4.8.2Costes de migración de Windows NT a Windows 2000	291

4.8.3Costes en la migración de Windows NT a Linux	294

4.8.4Costes de migración de Exchange 5.5 a Exchange 2000	297

4.8.5Costes de migración de Exchange 5.5 a Samsung Contact	298

4.8.6Recomendaciones en relación con productos/grupos de productos	299

Ejemplo de evaluación de urgencia y calidad / estrategia	329

Criterio de urgencia	330

Criterio de calidad/estrategia	330

Análisis de beneficios	330

5 Recomendaciones de migración	336

Declaraciones generales	336

5.1.1El camino de toma de decisiones	336

5.1.2Recomendaciones generales	337

“Migración de reemplazo” completa	339

5.2.1Modelo de arquitectura	340

5.2.2Agencias públicas medianas y pequeñas	343

5.2.3Agencias públicas especializadas con función de servicio de TI	346

5.2.4Agencias públicas pequeñas	348

“Migración de continuidad” completa	350

5.3.1Minimizando el grado de integración, grados de libertad de protección	352

5.3.2Caminos de migración adicionales	354

Migración parcial	354

5.4.1Migración selectiva	354

5.4.2Migración parcial en el lado del servidor	357

Caminos de migración	358

5.5.1Migración en un paso	358

5.5.2Migración suave	360

5.5.3Factores críticos de éxito	362

6 Autores y expertos contribuyentes	375

7Abreviaturas	377

8Glosario	386

9Tablas	392

10Ilustraciones	396

11Apéndice	400

11.1Apéndice:Wibe (especificación de recomendaciones sobre eficiencia económica para sistemas de TI)	400

11.1.1Revisión de los catálogos recomendados de criterios	400

11.1.2Catálogo general de criterios, IT-WiBe21, para escenarios de migración	400

11.1.3Catálogo especial de criterios, IT-WiBe21, para objetos de migración	404

11.1.4Explicación de los criterios adicionales	406

1 Introducción

“Un producto sustituye a otro si ofrece a los clientes un incentivo para el cambio que sobrepasa los costes del cambio o que supera la resistencia al cambio. Un producto sustitutivo ofrece un incentivo al cambio si, comparado con su precio, ofrece a los clientes un valor superior que el producto que era utilizado previamente.”

M.E. Porter

1.1Sobre el proyecto

Difícilmente existe una afirmación que describa mejor la esencia del extenso debate público sobre el uso de software de código abierto que esta afirmación, relativamente simple, de este profesor de la Escuela de Negocios de Harvard sobre los fundamentos de la competitividad. Linux, como insignia del código abierto tiene una larga historia como (desde el punto de vista de la teoría de la competencia) “producto sustitutivo” establecido, mientras que otros productos, como MySQL o OpenOffice, todavía están a medio camino de conseguirlo. (Puede echarse de menos la presencia del clásico de OSS, Apache, en esta enumeración, pero debe notarse que los autores de esta guía consideran a este producto como el original, en lugar del sustituto).

El sistema operativo Linux es, en particular, uno de los pocos productos de software que a día de hoy registra ratios de crecimiento y que ya se utiliza exitosamente en el 40% de las compañías y organizaciones alemanas, y esta tendencia todavía sigue aumentando. A la vista de este desarrollo, debería ser muy fácil contestar a la pregunta relacionada con los incentivos que desencadenaron el desarrollo de software de código abierto.

De todos modos, esta suposición no es cierta – al contrario: Difícilmente hay otro asunto que sea tan controvertido en las industrias de la información y las comunicaciones como los pros y contras del software de código abierto. Considerando el hecho de que sólo las ventas anuales del sistema operativo Windows superan los 10000 millones de USD es, por tanto, fácil ver que el debate sobre las alternativas está influenciado por poderosos intereses económicos.

Se discutirán las características técnicas de los productos y los parámetros económicos de las alternativas comparadas, adicionalmente al hecho de que el modelo de licencia es único y adicionalmente, a las preguntas frecuentemente formuladas en relación con la influencia de este modelo en la capacidad de innovación del la industria de TI. Esto nos lleva a un estudio pluridimensional y por tanto inevitablemente complejo que está abierto a interpretaciones. Es más, los competidores – i.e. código abierto vs. Microsoft – ya no son productos de software aislados, sino una plataforma casi completa con una larga variedad de software.

Un análisis objetivo y comprensible juega un papel clave en esta situación, que se ve determinada por los intereses más variados y un alto nivel de complejidad. Ese estudio debería contemplar no sólo las propiedades técnicas del software en cuestión

sino también su uso futuro, en particular, el uso especifico financiero, estructural/organizacional y el marco político de referencia en la administración alemana.

1.2 Sobre esta Guia

El titulo de esta guia ya sugiere que -inicialmente e independientemente de la decisión general de introducir software de código abierto- el ciclo de vida del software de Microsoft requiere varias decisiones de migración. Un buen ejemplo es la eliminación progresiva del soporte para Windows NT que todavía es utilizado extensamente, con su sistema operativo sucesor requiriendo un acercamiento fundamental diverso hacia el diseño de dominios.

Para distinguir entre el reemplazo de este software por los productos de OSS y un cambio a las generaciones subsecuentes de los productos de Microsoft, los términos de reemplazo y continuidad en la migración son utilizados a menudo en esta guía. La guía de la migración se centra en recomendar el grado óptimo y económicamente razonable de la solución más que en apuntar a sustituir productos ya en uso.

La guía de la migración ha sido diseñada para los responsables a cargo de la planificación e implementación de las estrategias y proyectos de TI en la administración pública.

La primera parte (el capítulo 2) ocupa el inicio de la situación del software IT que condujo al desarrollo de los planes de la migración y da una descripción de la arquitectura básica del software de Microsoft y de la plataforma alternativa basados en estándares abiertos/código abierto. El supuesto mapa del entorno del sistema muestra las funciones cubiertas por productos o soluciones concretas y visualiza las correlaciones entre el producto individual y las capas del software.

La segunda parte (los capítulos 3 y 4) trata la aplicación sobre la migración potencial o la nueva introducción de sistemas e infraestructuras. Las áreas de aplicación individuales del software se analizan desde un punto de vista técnico y comercial. Mientras que el análisis técnico se centra la identificación y la evaluación de soluciones alternativas a los productos de Microsoft, el análisis comercial trata la pregunta de cómo el cambio de software se puede manejar en la manera más económica posible.

La tercera parte (capítulo 5) contiene las recomendaciones de la migración para diferentes agencias públicas así como un resumen técnico y un análisis comercial.

Estas recomendaciones incluyen las ofertas concretas para las agencias públicas pequeñas, medianas, grandes y especializadas. Los pros y los contras de diversas trayectorias de la migración también son considerados. La tercera parte muestra también los factores críticos para el éxito de los proyectos de migración. Aunque reemplazar software no es generalmente algo nuevo, la experiencia de los proyectos de la migración realizados en la administración pública confirma que la introducción de los productos de software debe ser planeada cuidadosamente y que el éxito de estos proyectos es depende en gran medida de la preparación del personal implicado en la tarea de la migración.

Durante los meses de trabajo sobre esta guía de migración, llegó a ser de nuevo evidente que este tema es un campo muy dinámico y rápidos cambios. El numero

de paquetes de software disponibles bajo Linux, bajo GLP y de naturaleza comercial, se incrementó visiblemente durante la duración de este proyecto. Esto también se aplica al número de fabricantes que no solamente expresaron su adscripción a la estrategia Linux, pero quienes también lanzaron productos concretos o por lo menos un plan del lanzamiento. Además de grandes proveedores de software, tales como SAP, Oracle, Sun o IBM, las compañías pequeñas y medianas de software están ofreciendo cada vez más un número creciente de aplicaciones especiales y de sistemas. Éste es un desarrollo positivo para los partidarios del código abierto que contribuye hacia la madurez y aumento de las ofertas de OSS por una parte, pero también incrementa la dificultad de mantener una descripción clara de qué objetivos han sido alcanzados.

Al final, se deja a los lectores que ellos mismos identifiquen los "incentivos del cambio" que se aplican a su situación específica. Los autores esperan que la guía de la migración sea un asistente bueno y fiable para las consideraciones técnicas y comerciales.

1.3 Como utilizar esta guia

La siguiente sección contiene una corta introducción de cómo utilizar la estructura interna de este documento. Diseñado para proveer al lector la ayuda en la navegación, de modo que puedan fácilmente encontrar el contenido relevante, ya que este volumen resulta algo pesado. La guía se dirige a dos grupos distintos. Un grupo se compone de los responsables a cargo de la planificación e implementación de las estrategias y proyectos de las TI. El segundo grupo lo forman los Administradores TI en las agencias públicas que estarán ciertamente muy interesadas en descripciones técnicas detalladas.

Recomendamos que ambos grupos lean la información siguiente.

Este capítulo termina con una sección específicamente para los responsables.

La sección titulada "información para los responsables" contiene un resumen del contenido y de los resultados más importantes de la guía de la migración en forma concisa. Ningún lector de esta guía de la migración debe saltar las primeras cuatro secciones del capítulo 2. Estas secciones contienen definiciones terminológicas que son importantes para el resto de la guía. Además, se describen los componentes del entorno subyacente a un proyecto de migración. También se describen los apartados migración por sustitución y migración por continuación.

Además, las explicaciones individuales en el capítulo 3 comienzan con un resumen de los resultados de las explicaciones técnicas referidas, de modo que los responsables puedan obtener una descripción de los resultados y las explicaciones técnicas de los diversos componentes de la migración.

El capítulo 4.7 contiene un resumen de los resultados de los análisis comerciales.

Por otra parte, el capítulo 5 contiene también las recomendaciones relacionadas con los efectos económicos de los diversos métodos de migración.

El análisis comercial (capítulo 4) se ocupa de los aspectos financieros de los proyectos de migración y es por lo tanto particularmente relevante para los lectores que tienen que tomar las decisiones estratégicas y económicas fundamentales. Se utilizan diversos escenarios para estudiar los aspectos monetarios de los posibles proyectos de migración.

El capítulo “Recomendaciones de Migración” proporciona los detalles relevantes para la toma de decisiones en una administración pública. Este capítulo contiene recomendaciones de combinaciones adecuadas a distintos escenarios posibles de distintas estructuras de administración . Estas recomendaciones están basadas en los análisis técnicos y comerciales precedentes. Las explicaciones de la sección titulada “Migración suave”, abordan cuestiones clave como qué condiciones y factores deben considerarse para lograr una implantación exitosa del proyecto. Este es el núcleo de información esencial y relevante que necesitan las personas responsables de la toma de decisiones. No obstante, cada responsable es libre de complementar con cualquier otro contenido esta guía.

Un recorrido exhaustivo de la guía puede ser interesante para responsables de TI. La estructura está dispuesta de forma que el capítulo 2, titulado “Puntos clave de la guía de migración”, que sigue a la introducción, contiene información general importante para entender el resto de la guía. Las secciones que siguen a las primeras cuatro secciones ya mencionadas contienen información relativa a las distintas distribuciones Linux, modelos de licencia de código abierto y, sobre todo, información relativa a los datos en que se fundamenta esta guía.

Los detalles técnicos discutidos en el capítulo 3 son posiblemente la fuente más importante de información para los responsables TI que estén familiarizados con los requerimientos específicos de su administración cuando se trata de asuntos tales como:

¿Qué es técnicamente viable y/o dónde se dan los problemas?

¿Cómo pueden resolverse los problemas o utilizar soluciones de compromiso?

¿Qué es importante desde el punto de vista técnico cuando se trata de migrar un componente?

¿Qué funcionalidades pueden mantenerse después de la migración, y/o cuáles son las restricciones?

Y muchos más.

Dentro de cada sección, se presentan los componentes del sistema desde un punto de vista técnico. Se describe primero la situación técnica de partida y seguidamente se tratan aspectos particulares de migraciones por reemplazo y continua. Para los lectores interesados, con la adecuada capacitación técnica, se ofrece una visión general de las distintas tecnologías, con información detallada en lo concerniente a la adecuación de las distintas soluciones y productos. Las secciones que tienen que ver con migración por reemplazo, contienen una gran cantidad de información pensada para los lectores que todavía no tienen familiaridad con las tecnologías basadas en Linux o que sólo han tenido un contacto limitado con ellas.

El capítulo recoge los análisis técnicos y económicos de los capítulos precedentes para conformar recomendaciones concretas. Este capítulo presenta los distintos escenarios que se explican de manera distinta dependiendo del tamaño y grado de especialización

de la administración pública particular. Los lectores encontrarán información concreta dependiendo de sus necesidades y la situación de partida particular.

Información para responsables de toma de decisiones

Recomendaciones generales

Como ya se ha indicado en la sección anterior, la guía de migración generalmente analiza las dos rutas, esto es, migración por continuación y por sustitución. El resultado general puede mencionarse ya aquí: el número de escenarios donde la migración por sustitución, utilizando productos de código abierto, es la aproximación más favorable para las administraciones públicas se ha incrementado. Esto es, por una parte, debido a que los resultados de la evaluación de eficiencia económica en la que los productos OSS son en general ventajosos. Por otra parte, la madurez actual, penetración y compatibilidad de los productos OSS está allanando el camino de forma especial a los proyectos de migración y, de esta forma, contribuyendo a menores costes de cambio que en el pasado. La evaluación de la eficiencia económica, en particular, confirma que se pueden alcanzar ahorros substanciales no sólo cuando se eliminan los costes de licencias, sino también – y sobre todo – como consecuencia de la creciente competencia entre sistemas operativos y productos 'Office'.

Los resultados de la guía se refieren principalmente a la situación de partida que aún prevalece en muchas administraciones públicas. Estos entornos se caracterizan por utilizar Windows NT 4 como sistema operativo y los productos relacionados de Microsoft, tales como MS Exchange 5.5, Internet Information Server 4 y MS SQL Server 7.

Migración por continuación y por sustitución

Esta configuración es la situación de partida para la migración por continuación dentro de la familia Microsoft. Un énfasis especial se pone en la migración de los productos mencionados arriba a Windows 2000 y las series de producto 2000 – también con la mirada puesta en Windows XP y Windows 2003 -. El enfoque en Windows 2000 no significa que, en el caso de administraciones que ya hayan completado su migración a este entorno, la guía no resulte de utilidad. Esta guía proporciona información útil, para estos últimos casos, en ambos aspectos: análisis técnico y recomendaciones. Las argumentaciones que se presentan y las medidas inmediatas para la reducción de la dependencia interna aseguran que estas opciones pueden mantenerse abiertas con una visión hacia futuras migraciones.

Estas recomendaciones están escritas principalmente para administraciones públicas que acaban de completar la migración a Windows 2000 por una parte, y para administraciones que han decidido (por la razón que sea) o bien se ven forzadas a continuar utilizando la línea de productos Microsoft en el momento presente.

En el caso de la migración por reemplazo se concluye que los resultados y recomendaciones deben diferenciarse en vista del gran número y diversidad de soluciones. Los criterios importantes para seleccionar la solución correcta son: tamaño, intensidad de uso TI y el grado de “especialización” de las administraciones públicas que proveen servicios TI para otras administraciones. Deben identificarse correctamente los productos equivalentes y escenarios de migración. Esta guía diferencia, en este caso, entre migración selectiva, de largo alcance y completa - dependiendo del “alcance” en lo que concierne a las TI. Selectiva por reemplazo de componentes individuales del entorno de las TI,

Puesto que las funcionalidades individuales y propiedades concretas pueden ser importantes en cada caso individual, cada agencia pública debería evaluar el nivel crítico de las funcionalidades divergentes por sí misma. Las diferencias de este tipo se encuentran primeramente en el campo de las aplicaciones Office, en especial en la integración de aplicaciones especiales y Office, así como en el campo de la compatibilidad e intercambio de documentos entre Office y OpenOffice.org y/o StarOffice. Debido a problemas de compatibilidad, la edición normal de documentos con OpenOffice.org y/o StarOffice y MS Office es posible sólo hasta un nivel muy limitado, La edición normal, en principio, sólo es posible a nivel de contenidos.

Los análisis técnicos muestran que, generalmente, existen soluciones de código abierto y/o soluciones comerciales para sistemas basados en Linux adecuadas para los componentes existentes en sistemas Windows y servicios de infraestructura.

En relación con los servicios de infraestructura, Samba y OpenLDAP juegan un papel importante para la implementación de sistemas heterogéneos. CUPS es un servicio de impresión innovador y a la vez probado y comprobado que cumple los requerimientos de cualquier entorno de impresión actualizado, es eficiente económicamente y complejo. El número de soluciones software complejas está creciendo. De todos modos, los sistemas basados en Linux son ofrecidos también para la gestión de sistemas corriendo bajo Windows.

Las soluciones alternativas a MS Exchange, incluyen por ejemplo productos de software libre, especialmente para el uso como servidores puros de correo. Samsung Contact es una solución de reemplazo total que permite el uso continuo del cliente de correo Outlook en entornos medios y amplios y Exchange4 Linux para entornos pequeños.

Hay muchos sistemas abiertos de gestión de bases de datos. Por ejemplo, SAP DB, MySQL, y PostgreSQL. Es más, algunos sistemas de bases de datos comerciales como Oracle y DB2 son soluciones probadas y comprobadas bajo Linux y por tanto, no requieren un análisis técnico adicional.

La lista podría continuar con casos de todas las aplicaciones y áreas de infraestructura. La guía de migración contiene secciones separadas para estos asuntos, como soluciones de alta disponibilidad o clientes “ligeros”. Se explican también las diferencias y restricciones de las alternativas consideradas.

1.4.5Futuros aspectos clave

Con el fin de dar al análisis la necesaria orientación hacia el futuro, se considerará el papel de los componentes que juegan un papel central en la nueva arquitectura de Microsoft, así como una descripción y un análisis de la situación de partida. Estos son, sobre todo, el entorno de desarrollo .NET con sus componentes principales, i.e. servicios web y Xml, así como el portal de servicios SharePoint.

- Página 15 -

Los resultados se pueden resumir en lo siguiente:

Tanto la arquitectura .NET y la alternativa Java/J2EE generalmente ofrecen dos posibilidades para implementar la reutilización de componentes y la interoperabilidad entre plataformas y aplicaciones

La reutilización que puede lograrse por medio del uso del mismo modelo de componentes (COM+ en el caso de Microsoft y JavaBeans en Java) serán referidas como integración profunda debido a su dependencia del entorno de ejecución y/o los lenguajes de programación. Las aplicaciones generadas usando un modelo de componentes pueden ser utilizadas solamente dentro de la misma plataforma.

XML servirá como el formato de documentos y de intercambio de datos y por lo tanto forma la base para el uso de servicios web los cuales, gracias a su independencia de un entorno de ejecución concreto y gracias al uso de interfases de protocolo, pueden ser usados para integración superficial de servicios. Los servicios basados en servicios web pueden ser usados más allá de los límites de las plataformas.

En vista de los problemas de seguridad que están todavía sin resolver en conjunción con con el uso de aplicaciones ofrecidas por medio de servicios web, en el presente no es posible dar una recomendación general para el modelo de integración superficial entre plataformas. Esta será una tarea clave del trabajo en desarrollo.

Una recomendación general para el modelo de componentes ya ha sido fijada en la recomendación de estandarización de SAGA y especifica JSE/J2EE como el modelo de componentes obligatorio debido a la independencia de plataforma general. El uso de otra tecnología distinta de la tecnología de preferencia debe ser justificada (por ejemplo, por ventajas comerciales significativas) (en favor de la arquitectura .NET, por ejemplo).

El uso de XML como el formato de datos que SAGA ya se especificó como el “estándar universal y primario para el intercambio de datos entre todos los sistemas de información relevantes para propósitos administrativos”, así como la especificación SAGA de PDF como el formato de intercambio de documentos probablemente conducirá a una mejora sustancial (aunque ciertamente, no a la completa eliminación de todos los problemas) en conjunción con la interoperabilidad de los productos de Office con MS Office 2003 y superiores.

Eficiencia económica

La evaluación de la eficiencia económica en la guía de migración se centra en dos aspectos claves:

Determinar enunciados generales concernientes a la eficiencia económica de los productos de software libre

Describir métodos y ayudas para la determinación de evaluaciones específicas a cada agencia y cálculos de costes de migración relacionados con los proyectos

Con la matriz de costes de migración y una evaluación de la eficiencia económica amoldada a las condiciones de los proyectos de migración (WiBe 21)5 se describen dos acercamientos metodológicos hacia el cálculo de la rentabilidad de los proyectos de migración.

Esta guía contiene modelos calculados y comentados para diferentes escenarios a fin de explicar estos métodos en mayor detalle. Para considerar las características especiales del proceso de migración, estos modelos calculados incluyen una propuesta para el criterio de análisis a ser seleccionado así como un nuevo criterio de análisis y recomendaciones para la evaluación y análisis de beneficios para la preparación de una evaluación de la eficiencia económica de acuerdo a WiBe 21. Esto significa que esta guía no solo permite la estimación de un proyecto en términos económicos sino también ayuda a determinar índices de rentabilidad o urgencia y/o importancia estratégica de estos proyectos. La matriz de costes de migración es también una forma rápida y pragmática de soporte para la evaluación de eficiencia económica.

Podemos concluir que las evaluaciones de eficiencia económica muestran particularmente que el grado de integración entre los entornos Windows y MS Office será un factor de decisión clave a favor o en contra de una migración de reemplazo. El número de aplicaciones Office existentes, la extensión y complejidad de las macros, scripts y plantillas utilizadas, así como el número y disponibilidad del código fuente de las aplicaciones especiales usadas que solo pueden ejecutarse bajo Windows determinan la eficiencia económica y viabilidad de la migración de reemplazo. Esto es por que, especialmente con respecto a este punto, algunas recomendaciones apuntan hacia reducir dependencias e incrementar la interoperabilidad.

5 - IT-WiBe 21 – Empfehlungen zur Durchführung von Wirtschaftlichkeitsbetrachtungen in der Bundesverwaltung, insbesondere beim Einsatz der IT, Version 3.0 – 2001, KBSt publication series, Volumen 52, Mayo 2001.

2 Aspectos clave de la guía de migración

Definiciones importantes

Algunos términos utilizados a diario son entendidos de forma distinta por personas distintas. Esto afecta, por ejemplo, al software de código abierto, software libre, propietario, comercial, etc. No es sólo esto, sino que esta guía introduce también nuevos términos.

Con el fin de evitar malentendidos al leer esta guía, se definen los términos más importantes brevemente a continuación.

código abierto, software libre

Los términos “software de código abierto” y “software libre” se utilizan como sinónimos en esta guía de migración. La abreviación utilizada para ellos es OSS.

OSS permite a cada usuario leer y modificar sin coste el código fuente disponible. Esta transparencia permite a los usuarios aprender del código fuente y/o adaptarlo a sus requisitos particulares. El software está disponible sin coste, los usuarios no tienen que pagar licencia. El software modificado puede ser copiado y distribuido. La libertad del software se define y protege mediante las licencias correspondientes. El capítulo 2.4 contiene una descripción de los modelos más importantes de licencias.

OSS no debería confundirse con aquel software que, aunque disponible sin coste, no puede ser modificado o corregido por el usuario y/o que está sujeto a licencias que prohíben el uso del software para propósitos comerciales.

Software propietario

El software propietario no es OSS. Pertenece a un individuo u organización, generalmente el fabricante del software (copyright). El uso del software está sujeto a los términos de la licencia establecida por el propietario. Estos términos prohíben habitualmente la duplicación, distribución y modificación del software.

El software de este tipo se ofrece en ocasiones sin coste, con la condición de adherirse a los términos aplicables de la licencia.

Software comercial Linux

El software comercial Linux (COLS) abarca el conjunto de software propietario que puede ejecutarse bajo sistema operativo Linux. Este software sigue presentando como ventajas el uso de estándares, y la interoperabilidad resultante, así como precisión en la definición de interfaces.

Migración por sustitución (o de reemplazo)

Esta guía diferencia entre una migración de reemplazo y una migración por continuación. ¿Cuál es la diferencia entre estas formas de migración?

La migración de reemplazo significa un cambio de las aplicaciones y servicios Windows al igual que del sistema Windows a plataformas OSS o COLS . Unos ejemplos:

de Windows NT a Linux

de MS Office a OpenOffice.org

de MS SQL Server a Oracle

Migración por continuación

La migración por continuación significa continuar con el uso de productos de Microsoft, por ejemplo, migrar de NT 4 a Windows 2000, Windows XP o Windows 2003.

Algunos ejemplos:

de Windows NT 4 a Windows 2000

de MS Office 97 a MS Office 2003

Caminos de Migración

Muchos organismos públicos e instituciones están actualmente afrontando cuestiones tales como cuál será el desarrollo que seguirán sus sistemas de IT en los próximos años.

Las razones para esto son diversas:

Suministradores descontinuando el soporte para productos clave.

Incremento de los requerimientos técnicos

Consolidación de sistemas existentes en el entorno

Metas estratégicas, las cuales acrecientan las dependencias industriales e incrementan la operatividades

Actualmente hay, por lo tanto, cuestiones para encarar las cuestiones propias de cuáles van a ser los sistemas y componentes que formarán parte de nuestras futuras estructuras tecnológicas. La guía de migración analiza y examina los siguientes pasos generales de migración:

Migración de reemplazo utilizando Linux y software libre (OSS)

Migración de reemplazo utilizando Linux/software libre y productos Linux comerciales(COLS)

Migración por continuación con MS Windows 2000 y generaciones sucesoras como la relación con aplicaciones y sistemas Windows.

Además de esto, puede considerarse la opción de una migración híbrida porque no se puede contar con una solución OSS/COLS para todos los sistemas antiguos, tanto por razones técnicas como comerciales.

Dentro del ámbito de esta guía no son posibles los análisis completamente exhaustivos. Esto último sería imposible, debido tanto a la complejidad de los entornos de TI a considerar como a los requerimientos específicos de algunas agencias públicas. En lugar de esto, la guía de migración debe entenderse más como una fuente de respuestas y ayuda para la toma de decisiones en las cuestiones clave que mayoritariamente son formuladas por las autoridades públicas.

2.2.1Microsoft como situación de partida

La ilustración de la figura 1 muestra el contexto de sistema Microsoft de este modo u otros similares en muchas agencias públicas y organizaciones. La figura muestra un visión de los servicios y módulos de software que forman parte de la situación de partida considerada para los casos de migración analizados. El capítulo 3 comienza para cada uno de estos componentes con una descripción técnica de la situación real en términos de funcionalidades y características especiales disponibles de cara a la migración. Esta descripción es seguida por un análisis técnico de una, o si aplican, varias soluciones adecuadas para una migración total. El tercer paso es un análisis de la migración de continuidad. El cuarto y último paso del análisis técnico es una evaluación y recomendación sobre uno u otro camino de migración.

Figura 1: Contexto de sistema – situación de partida

Han sido necesarias algunas suposiciones en relación con las funcionalidades concretas de una infraestructura de TI en el momento de escribir esta guía. A menos que se indique explícitamente lo contrario en los análisis técnico y comercial, se han realizado las siguientes suposiciones.

2.2.1.1Plataforma servidor

Se ha supuesto que la situación de partida en las agencias públicas está basada en una de los dos modelos de dominio de los clientes NT.

Entorno con un dominio NT en el que se almacenan el usuario y las cuentas de usuario.

Entorno con un dominio NT de cuentas que incluye las cuentas de los usuarios y varios dominios con recursos, que mantienen las cuentas de usuario y confían en el dominio de cuentas.

Con este entorno los servicios de infraestructura, están disponibles aplicaciones y componentes de integración sobre la base de un servidor NT 4.

En esta guía se consideraron los siguientes servicios clave de infraestructura:

Servicio de registro-autenticación

Servicios de ficheros (disco)

Servicios de impresión

Servicios de red

Servicios de gestión de sistemas.

En relación con las aplicaciones del servidor, esta guía se concentra en las siguientes áreas por su uso extendido en las administraciones públicas:

Internet Information Server (IIS) versión 4 como el servidor web para intranet y presencia en internet

Exchange 5.5 como solución de mensajería y groupware

SQL-Server 7 como sistema de gestión de bases de datos para muchas aplicaciones de base de datos.

Normalmente, los diferentes servicios fueron relacionados e integrados sobre la base de:

Component Object Model (COM) y

el correspondiente servicio COM distribuido (DCOM).

Los servicios Windows NT 4 pueden ofrecerse sobre dos variantes de sistema operativo

Windows NT4 Server

Windows NT4 Server Enterprise Edition.

La segunda variante (Enterprise Edition) permite la implementación de los servicios sobre dos nodos (servidores) en un cluster.

2.2.1.2Plataforma de cliente y sus aplicaciones

En el lado del usuario, cabe esperar que Windows Nt4 Workstation sea el sistema operativo dominante. Otras variantes de sistema operativo, como Windows 95 ó 98, son ignoradas en el análisis. La suite Microsoft Office se utiliza como

como la aplicación más importante en la base del sistema operativo. Las versiones 97 y 2000 son consideradas como las versiones más utilizadas en este momento. Los usuarios las utilizan en su trabajo diario. Los programas que utilizan son el procesador de textos, la hoja de cálculo y el programa de presentaciones, así como las funciones de correo electrónico y groupware.

Aparte de estos productos, también existe un conjunto de aplicaciones para tareas muy específicas que están profundamente integrados en el escritorio Windows. Estos programas deben analizarse en detalle con un ojo puesto en la migración. Como estas aplicaciones están afectadas por la migración del sistema TI subyacente, deberán desarrollarse estrategias internas, dependiendo del número y complejidad de estas aplicaciones. Esta guía describe algunas propuestas y procedimientos recomendados.

Para terminar, otras aplicaciones y herramientas estándar (como el gestor de ficheros y el empaquetador) también están a disposición del usuario en sus tareas cotidianas. Estas aplicaciones y herramientas serán necesarias en el panorama del nuevo sistema.

Panorama del sistema con la migración por reemplazo

La ilustración de la figura 2 muestra un resumen de un sistema alternativo basado en Linux. La ilustración muestra los sistemas y aplicaciones más importantes para los cuales la migración por reemplazo es posible.

En la década pasada, muchos desarrolladores de aplicaciones hicieron sus productos y servicios para Linux o los portaron a Linux. Aparte de grandes desarrolladores, como IBM, SUN u Oracle, un número amplio de compañías menores ofertaron soluciones especiales que deberían mencionarse aquí también. Dada la base de información y distribución que existe en el campo del software comercial, no es necesario examinar esos productos con la vista puesta en la viabilidad. La guía de migración se enfoca en soluciones de código abierto algo menos conocidas y en soluciones que, sólo recientemente, hacen posible la migración por reemplazo en áreas críticas.

La ilustración de la figura 2 muestra que existe más de una alternativa para ciertas aplicaciones. Esta es la razón del por qué las soluciones de fuente abierta tradicionales se tuvieron en cuenta en el análisis técnico. En casos en los que no existan aplicaciones de fuente abierta adecuadas, se examinarán soluciones software propietarias que se puedan ejecutar en Linux y que estén basadas en estándares abiertos.

Figura 2: panorama del sistema – migración por reemplazo.

Panorama del sistema con migración continua (o por continuación).

La migración continua está enfocada en el reemplazo de entornos Windows NT 4 existentes con versiones nuevas. La ilustración de la figura 3 muestra que los productos de las versiones 2000 serán las principales del análisis. Con la base de un servidor Windows 2000 y su infraestructura de servicios, el capítulo 3 debate las características técnicas y las medidas técnicas y conceptuales necesarias para la migración de cada servicio y producto en el servidor. Además, se analizarán y evaluarán las repercusiones de los cambios técnicos y las innovaciones.

Figura 3: panorama del sistema – migración continua

Además de la parte servidora, se realizará un análisis análogo de los escritorios para la migración por reemplazo. En este caso, sin embargo, el análisis se basa en Office XP.

El análisis se extenderá – siempre que la información disponible lo permita – hasta incluir la introducción de los productos servidores y de oficina de las versiones 2003.

Dependencias internas dentro del sistema Microsoft

Las arquitecturas basadas principalmente en productos de Microsoft son objeto de dependencias internas en varios grados. Las siguientes secciones explican algunas de las dependencias internas dentro de la infraestructura establecida por Microsoft.

Una dependencia relativamente obvia es que las aplicaciones Microsoft sólo pueden instalarse y utilizarse en sistemas operativos Microsoft. Esto es aplicable tanto a las aplicaciones de servidor como de oficina (por ejemplo, MS SQL Server, MS Exchange, etc.) y, con algunas excepciones, (Office 98 para MacOS, Internet Explorer 4 para UNIX), también a las aplicaciones de escritorio (p.e. Office) a software cliente cercano al sistema (p.e., los componentes cliente de MS SQL).

La aplicaciones de servidor suelen requerir una administración de usuarios para poder autenticar a los mismos y otorgarles acceso a los recursos. Microsoft ofrece variantes respecto a la base de datos a emplear. La variantes se enumeran a continuación utilizando como ejemplo MS SQL Server:

Variante A: un sistema de gestión de usuarios específico de MS SQL Server.

Variante B: la base de datos local de usuarios del sistema operativo del servidor.

Variante C: la base de datos de usuarios de un dominio Windows, a condición de que el servidor sea miembro de la estructura. Desde el lanzamiento de Windows NT, esta variante ha estado disponible para casi todos los productos de servidor de Microsoft y permite a los usuarios un sistema de identificación único en un entorno Microsoft puro.

Variante D: no se ofrece un sistema en el que la autentificación y la autorización las realicen instancias de otros fabricantes.

Con Windows 2000 y sucesores, Microsoft ha desplazado la administración y autentificación de usuarios a servicios de directorio (ver más adelante) empleando estándares abiertos como Kerberos y LDAP, aunque sin permitir instancias no-Microsoft.

Respecto al mundo Windows NT 4.0, deben mencionarse otras dependencias respecto a la administración de usuarios. Por ejemplo, no es posible implementar entornos Microsoft Exchange (versiones 4 a 5.5) sin la estructura de dominio Windows NT. Otro ejemplo de dominio NT obligatorio es la funcionalidad de servicios en cluster. Lo mismo se puede aplicar a la arquitectura distribuida de componentes DCOM (Modelo de Objetos de Componente Distribuido – Distributed Component Object Model) creada por Microsoft con una infraestructura de seguridad que requiere que el cliente y el servidor pertenezcan a una estructura de dominio. Un gran número de aplicaciones cliente/servidor (de Microsoft y otros fabricantes) utilizan DCOM.

Con Windows 2000, Microsoft desarrolló aún más el modelo de dominio NT, que acabó en el servicio de directorio activo. Dentro del directorio activo, el modelo de dominio NT y sus propiedades aún se pueden ver y son necesarias para la compatibilidad hacia abajo. La introducción de Kerberos como mecanismo de autenticación, por ejemplo, no significa la eliminación del mecanismo NTLM (NT LAN Manager). Es más, los entornos Windows 2000 puros siguen utilizando NTLM en ciertas ocasiones (como en clusters). Al mismo tiempo, el directorio activo fue retocado añadiéndole funcionalidades tendentes a ser manejadas separadamente o que no existían en el mundo Microsoft anterior. Respecto a la funcionalidad de las directrices de grupo, algunas partes ya eran conocidas en Windows NT como directrices del sistema, Kit de Administración de Internet Explorer (IEAK – Internet Explorer Administration Kit) o Gestor de la Configuración de Seguridad (SCM – Security Configuration Manager). Las nuevas funcionalidades se introdujeron en el campo de las directrices de grupo, como la distribución del software, la dependencia en unidades organizativas, dominios o sitios o scripts de entrada y salida del sistema.

Una característica completamente nueva en el directorio activo de Windows 2000 es la integración de tecnologías de cifrado, como IPsec o EFS (Sistema de Ficheros Cifrado – Encrypted File System). Si se van a utilizar estas tecnologías de cifrado deberá configurarse un PKI (Infraestructura de Clave Pública – Public Key Infraestructure) que se integra en el directorio activo. En este contexto, Microsoft también ha desarrollado el protocolo Kerberos para permitir la autentificación mediante tarjetas inteligentes (SmartCards). Otro requisito obligatorio del directorio activo de Windows 2000 es una infraestructura DNS (Sistema de Nombres de Dominio – Domain Name System) para la resolución de nombres.

El DNS se debe corresponder, al menos, con las versión 8.2.2 de BIND. Windows incluye un DNS propio.

Exchange 2000 es el primer producto Microsoft que requiere el directorio activo de Windows 2000 como funcionalidad obligatoria. Al contrario que Exchange 5.5, Exchange 2000 ya no incluye su propio servicio de directorios. Cualquier información del e-mail de los usuarios y de las listas de distribución de Windows 2000 se localiza en el directorio activo, que debe ser preparado para su integración en Exchange por una modificación de esquemas. El Servicio Total de Catálogos del directorio activo juega un papel primordial en Exchange 2000. Exhange 2000 utiliza este servicio global de catálogos para solicitar información más allá de los límites de los dominios. Outlook 2000, por ejemplo, utiliza también el Catálogo Global. Es más: Exchange 2000 utiliza el directorio activo no sólo en modo lectura, sino también en modo escritura: El servicio de Actualización del Receptor de Exchange 2000, escribe sus resultados en el directorio activo. Las herramientas para administración de usuarios de e-mail, están completamente integradas en la consola de gestión “directorio activo – usuarios y ordenadores” .

Estas correlaciones y dependencias entre el sistema operativo y las aplicaciones de Microsoft caracterizan el progresivo incremento del alcance de la integración dentro de ésta plataforma e inician muchas preguntas respecto de aspectos estratégicos en relación con el uso de alternativas potenciales de estos productos.

¿Cómo puede implementarse la interrupción de cierta línea de productos o de los ciclos de actualización?

¿Cómo puede minimizarse la dependencia de una línea de productos y el equipo técnico necesario?

¿Qué medidas llevan a la reducción de la dependencia de un suministrador y a la diversificación del entorno de software?

¿Existen suficientes alternativas para ciertos componentes del software en la forma de alternativas más económicas?

A la vista del nivel de dependencia que se ha alcanzado a día de hoy a nivel de producto, estas preguntas sólo pueden ser respondidas por una aproximación estratégica que debe ser considerada dentro del entorno de las TI de las administraciones.

2.3Distribuciones Linux

2.3.1Introducción

Existe un puñado de distribuciones Linux para implementar sistemas de servidor y de cliente. Más allá del propio sistema operativo, estas distribuciones contienen muchos paquetes de software. Estos paquetes no son sólo aplicaciones de escritorio disponibles de las formas más variadas, sino también software para servidores web, sistemas de gestión de bases de datos, servidor de correo, firewall, servidor proxy, servicios de directorio y muchos más.

Temas clave de la guía de migración

Algunas distribuciones seleccionadas serán brevemente descriptas a continuación, mencionando también sus características particulares.

Las distribuciones son ofrecidas por muchos fabricantes diferentes, En general, son desarrolladas y empaquetadas originalmente buscando simplificar la instalación del núcleo del sistema operativo y los programas relacionados. Para propósitos de instalación, las compañías de distribución han desarrollado un grupo de herramientas de instalación diferentes para el núcleo libre del sistema operativo y las unidades de software que lo rodean algunas de las cuales, por su parte, también fueron licenciadas como software libre. El cliente de una distribución no compra el mismo Linux. Lo que se paga en su lugar es la combinación del sistema operativo, programas de utilidades, programas de instalación y la documentación creada por el distribuidor. El propósito de las distribuciones es reducir los esfuerzos administrativos y de organización por parte del usuario ya que el núcleo del sistema operativo no incluye ningún concepto útil para sus necesidades. Esto significa que el sistema operativo está abierto para diferentes conceptos de administración y organización.

El comprador de una distribución usualmente recibe los volúmenes de datos (hoy en día, unos cuantos CDs) y una documentación muy extensa. Aunque el volumen y calidad de la documentación varía de distribución a distribución, la documentación en general incluye un manual de instalación e información de uso más detallada. Los volúmenes de datos contienen las versiones correspondientes del software del sistema operativo y una multitud de unidades de software adicionales. Según la Licencia Pública General GNU (GPL), la cual aplica a muchos programas y al núcleo del sistema operativo utilizado bajo Linux, los distribuidores también proveen el código fuente de los programas correspondientes. Eso hace posible que los usuarios recompilen el software cuando aparecen problemas y modifiquen el software en línea con sus requerimientos específicos.

Las diferentes distribuciones están disponibles como paquetes completos (CD, documentación) distribuidos por los vendedores mediante pago o como copias gratuitas desde la Internet. Los paquetes comprados a los vendedores incluyen normalmente ciertos servicios de soporte que el proveedor brinda y que no están disponibles para versiones descargadas desde la Internet. En el caso de las tres distribuciones discutidas a continuación, es posible una diferenciación adicional entre versiones ofrecidas por proveedores de distribuciones comerciales y una distribución que fue desarrollada por un proyecto de grupo en un esfuerzo conjunto.

La compatibilidad de las versiones de Linux y la estandarización de las diferentes distribuciones serán temas importantes en el futuro. Para evitar diferencias inaceptables entre las distribuciones individuales, se definió el Filesystem Hierarchy Standard7 para la estructura de directorios de Linux. Los proveedores de distribuciones usualmente implementan este estándar en sus distribuciones. Como un elemento importante del intento para asegurar interoperabilidad, el Filesystem Hierarchy Standard también está integrado al Linux Standard Base 8 (LSB). El objetivo del Linux Standard Base es definir estándares diseñados para lograr máxima compatibilidad de todas las distribuciones y para prevenir divergencia entre los sistemas Linux. El propósito de la estandarización es facilitar el trabajo tanto de los desarrolladores de software como de los distribuidores.

7 http://www.pathname.com/fhs/

8 http://www.linuxbase.org

TEMAS CLAVE DE LA GUIA DE MIGRACION

Considerando una futura proliferación de distribuciones Linux conformes con el LSB, la distribución de software será posible en el futuro independientemente de la distribución Linux respectiva.

Además de LSB, el Free Standard Group9 debe ser mencionado también en el contexto de actividades de estandarización. Ese grupo es una fusión de LSB, OpenI18N10 (previamente Linux Internationalization Initiative Li18nux) y LANANA (The Linux Assigned Names and Numbers Authority). LANANA se encarga de la administración del espacio de nombres de Linux para evitar colisiones de nombres entre aplicaciones y drivers. Lo miembros del FSG son

Caldera, Compaq, Conectiva, Debian, Dell, Hewlett Packard, Hitachi, IBM, Miracle Linux, The Open Group, Oracle, Red Hat, SCO, Sun, SuSE, Turbolinux, VA Software y los miembros del grupo de código abierto Entwicklergemeinschaft [código abierto Developer Group]. Todos los fabricantes de las distribuciones discutidas en ésta guía son miembros del FSG. La lista de distribuciones certificadas LSB está disponible en Internet11

Los criterios para la selección de una distribución son los requerimientos relacionados con el soporte y el concepto de administración así como el soporte de hardware por un lado y el marco de referencia financiero/organizacional por el otro. Un ejemplo de tales criterios son la disponibilidad de acuerdos marco u ofertas de aplicaciones específicamente personalizadas a las necesidades de las agencias públicas.

Las distribuciones presentadas a continuación fueron seleccionadas por su amplia utilización (consultar también el capítulo 2.5.1)

2.3.2 Debian GNU Linux

El proyecto Debian es llevado adelante por una multitud de desarrolladores que están desarrollando un sistema operativo libre en un esfuerzo conjunto. Una característica distintiva de este grupo es la distribución a nivel mundial de sus casi 1000 miembros honorarios. La característica más importante de la distribución es el hecho de que el software está disponible libremente en el sentido de la GPL y que puede ser copiada y utilizada comercialmente sin ninguna restricción.

La distribución puede descargarse desde Internet o bien comprarse. La distribución Debian es considerada como un producto no comercial. Eso significa que el precio de los Cds principalmente cubre el costo de producción y distribución de volúmenes de datos. El proyecto Debian en sí mismo no ofrece ningún paquete de Cds, una característica que distingue ésta distribución de las otras.

Otra característica distintiva de Debian es la forma con que son manejados los errores y fallos en el grupo de desarrolladores. En un procedimiento de rastreo de fallos, se publica una lista que contiene todos los mensajes e informes de error abiertos, los cuales son manejados por los desarrolladores. Ese mecanismo de control de calidad hace de Debian la distribución más estable y libre de fallos. Debian está caracterizada por largos ciclos de versión lo cual contribuye

9 http://www.freestandards.org

10 http://www.openi18n.org

11 http://www.opengroup.org/lsb/cert/cert_prodlist.tpl?CALLER=cert_prodlist.tpl

Temas clave de la guía de migración

a la alta calidad de la distribución ya que éso significa que las nuevas versiones no son liberadas prematuramente.

Otra característica clave de Debian es el formato de paquete único y las herramientas de sistema. Una ventaja importante es la posibilidad de actualizar fácilmente los sistemas y/o problemas individuales sin la necesidad de reinstalar completamente el software. El manejo de paquetes también es utilizado para actualizaciones regulares del sistema en la forma de actualizaciones de seguridad y estabilidad.

Hay disponibles varias listas de correo12 para apoyar la operación y el desarrollo. Si esa fuente de información no es suficiente, se ofrecem servicios de soporte por parte de numerosos proveedores comerciales.

2.3.3 Distribución SuSE Linux

SuSE Linux AG es uno de los mayores proveedores internacionales de distribuciones Linux. Tradicionalmente, SuSE Linux AG tiene una presencia muy fuerte en el mercado Alemán. SuSE comenzó adaptando la distribución Slackware13 a las demandas del mercado Alemán. Algún tiempo después, la compañía desarrolló una distribución propia. Durante el transcurso del tiempo, SuSE desarrolló productos para varias aplicaciones. La tabla siguiente (Tabla 1) describe las propiedades más importantes de las diferentes distribuciones.

Tabla 1: SuSE Linux

La distribución SuSE está basada en el sistema de paquetes RPM desarrollado por Red Hat. El sistema de paquetes hace posible una fácil instalación y desinstalación de software, incluyendo software de terceros. Sin embargo, la experiencia sugiere que ciertos paquetes de software específicos de una distribución deberían ser instalados usando el método preferido por el fabricante respectivo. Las distribuciones SuSE incluyen el sistema de instalación y administración YaST. Los usuarios pueden elegir tanto una interfaz texto como una interfaz gráfica para la administración del sistema.

12 http://www.debian.org/support

13 http://www.slackware.org

TEMAS CLAVE DE LA GUIA DE MIGRACION

Las principales diferencias entre las variantes de distribución mencionadas previamente radican en sus aplicaciones recomendadas y las diferencias resultantes, en el ámbito de soporte ofrecido, en los acuerdos de licencia disponibles y por último, pero no menos importante, en el precio de compra.

Las soluciones empresariales son ofrecidas para aplicaciones en áreas de negocios críticas, como soluciones optimizadas con un enfoque hacia la disponibilidad y escalabilidad. Las características integradas incluyen, por ejemplo, capacidad de cluster, capacidad de multiprocesador y E/S asíncrona.

Además, se ofrencen diferentes programas de soporte para las diferentes distribuciones. Dependiendo de las exigencias del cliente se ofrecen por ejemplo soporte 24x7, acuerdos y certificaciones a nivel de servicio personalizados.

2.3.4 Distribución Red Hat

La distribución Red Hat es otro producto comercial. Red Hat también ofrece a sus clientes diferentes variantes de la distribución para diferentes aplicaciones (consultar Tabla 2). Red Hat usa una funcionalidad de administración de paquetes desarrollada internamente. Los paquetes de programa (.rpm) son manejados por el Red Hat Package Manager lo cual hace uniforme y amigable con el usuario el manejo del software.

Tabla 2: Red Hat

Las diferencias principales entre los diferentes productos son sus aplicaciones recomendadas y las diferencias resultantes en el ámbito del soporte ofrecido, en los acuerdos de licencia disponibles y en el precio de compra.

2.3.5 Certificaciones

La certificación es posible para hardware, software y empleados.

2.3.5.1 Hardware

La certificación de hardware incluye un procedimiento de prueba seguido por la certificación de los productos para plataformas y versiones de Linux definidas. Las prestaciones y conveniencia del hardware son verificados en conjunto con la operación de las distribuciones Linux definidas. Los fabricantes de hardware pueden tener sus productos certificados junto

con los productores de las distribuciones más importantes. Aparte de la seguridad y de la calidad, la certificación es un punto fuerte para la compra a los constructores de hardware.

La certificación ofrece a los clientes un nivel más alto de seguridad en temas de compatibilidad del hardware y el sistema operativo usado, especialmente en el caso de aplicaciones y soluciones críticas para los negocios, como los sistemas EPR con RAID o hardware SAN. La certificación puede ser el argumento clave para los usuarios y los clientes.

Software

Las certificaciones software se llevan a cabo por los constructores de software (Vendedor de servicios independiente). Los constructores individuales validan y certifican las distribuciones como plataformas de sistemas operativos para su software de aplicación. Las compañías SAP y Oracle, por ejemplo, certificaron SuSE Linux Enterprise Server como una plataforma para determinadas aplicaciones.

Las certificaciones también están disponibles para sistemas por parte del fabricante de distribuciones RedHat. El proceso de certificación es aplicado normalmente sólo a la versión Enterprise de una distribución de un fabricante determinado. Muchos clientes requieren certificaciones software como un prerrequisito para uso de una plataforma como sistema operativo porque el soporte necesario de la aplicación, para la instalación y el manejo a veces sólo es ofrecido si el producto está certificado.

Certificación de los empleados

Aparte de la certificación hardware y software, la certificación también es requerida para las habilidades y el conocimiento técnico de los empleados.

Los líderes del mercado en el campo de los programas de certificación son, en el momento:

El RedHat Certified Engineer

El Linux Professional Institute

El objetivo de ambos programas de certificación incluye el desarrollo de estándares para la calificación de los empleados. La cualificación ofrece a los empleados las siguientes ventajas:

Soporte cuando están contratando personal

Cualificación estandarizada de los empleados

La certificación también ofrece a los empleados y los futuros empleados un número de ventajas:

Que está cualificado para el trabajo

Prueba de dicha calificación

Mejores oportunidades en el mercado de trabajo.

Ambos programas de certificación, generalmente se pueden considerar equivalentes, con RHCE enfocado más en la distribución propia de la compañía. Red Hat comenzó a desarrollar el programa Ingeniero Certificado Red Hat (del inglés, Red Hat Certified Engineer, RHCE) en un momento en que no existía ningún otro programa de certificación Linux. LPI no depende de ningún distribuidor ni de ninguna distribución y al mismo tiempo es una organización sin ánimo de lucro.

2.3.6	Conclusiones

Los usuarios pueden elegir entre numerosas distribuciones y versiones de las mismas. La identificación y definición de las necesidades son clave para la decisión. Cualquier decisión en favor de una distribución en particular debe basarse en las expectativas que se tengan en ella y su fabricante y el conjunto general de documentación. Si, por ejemplo, se requiere un amplio soporte del fabricante debido a la falta de recursos internos, las distribuciones de los distribuidores comerciales suelen ser los productos elegidos. Si se necesita certificación hardware o software para un campo de aplicación específico, normalmente se debe recurrir a las versiones empresariales de las distribuidores comerciales. Qué productos hardware o software están actualmente certificados para una determinada distribución y versión, es algo que debe ser comprobado caso por caso.

Debian es una distribución estable, meticulosamente depurada, probada y testeada para aquellos usuarios que no desean depender de una variante comercial. Si se requieren servicios de soporte completo, numerosos proveedores de servicios pueden ofrecerlos.

2.4	Modelos de licencia

De los diferentes modelos de licencia existentes en el mundo Linux, a continuación se resumen y caracterizan los más importantes.

2.4.1	GPL

La General Public License (GPL)18 desarrollada por la Free Software Foundation es probablemente el modelo de licencia mejor conocido. El kernel de Linux y la mayoría de las aplicaciones Linux son objeto de la 'GPL' como una licencia que garantiza, entre otras cosas, la libre disponibilidad y distribución del código fuente de estos programas. Con el fin de asegurar que el software permanecerá libre, incluso en el futuro, la GPL establece sucesivamente los derechos concretos y los términos de uso.

Los derechos y términos incluyen, en detalle:

° Sección 0:

La libertad de ejecutar el programa para absolutamente cualquier propósito.

° Sección 1:

Permite la copia y distribución, palabra por palabra, de copias de código fuente del

______________________

18 El original en Inglés se puede encontrar en: http://www.gnu.org/copyleft/gpl.html. Una traducción en Alemán está disponible en: http://www.suse.de/de/privates/support/licenses/gpl.html, incluso prevalece la versión original.

programa con la condición de que la nota de copyright y la licencia son también copiadas, y distribuidas con dichas copias. Está permitido explícitamente cobrar una cantidad por el hecho de realizar una copia y por otros servicios, como los servicios de garantía.

Sección 2

Permite modificaciones del programa y la copia y distribución de la versión modificada, con la condición de que la versión modificada contenga indicaciones relacionadas con dichas modificaciones a también con la condición de que esta sea publicada sin coste adicional y sujeta a los mismos términos de licencia y condiciones. Esto no aplica a las partes del programa que que constituyen secciones independientes y se distribuyen de forma separada.

Sección 3

Permite la copia del programa o de una versión basada en él en código objeto o en formato ejecutable con la condición de que se anexe el pertinente código fuente o una oferta escrita para distribuir el código fuente bajo petición (válida por al menos 3 años).

Las otras secciones contienen supuestos relacionados con la expiración de los derechos de la licencia, la liberación de responsabilidad y garantía, situaciones de conflicto con otras reclamaciones y una serie de temas que pueden leerse cuando sea necesario.

Los términos y condiciones de la GPL evitan la privatización del software producido colectivamente y promueve por tanto, el desarrollo de cierta cantidad de software gratuito.

GPL reducida

La Licencia Pública General Reducida GNU (GNU Lesser General Public License- LGPL ) es una forma alternativa de licencia. Esta licencia fue esbozada inicialmente bajo la denominación de Library GPL.

La LGPL es mayormente idéntica en propósito y contenidos a la GPL. Esto significa que deben garantizarse la copia gratuita y la distribución y modificación de software y librerías. Adicionalmente, el código fuente – incluyendo el código fuente de las versiones modificadas – debe estar disponible.

La diferencia en relación con GPL es el hecho de que programas no sujetos a GPL o licencias equivalentes, pueden utilizar librerías gratuitas bajo LGPL y formar una entidad ejecutable. Si estas librerías estuvieran sujetas a GPL, sólo los programas sujetos a GPL podrían enlazarse con estas librerías. Por el contrario, LGPL permite a los desarrolladores realizar programas no sujetos a la producción restrictiva de GPL y a pesar de ello, utilizar librerías gratuitas. Los programas que utilizan librerías sujetas a LGPL pueden distribuirse sujetos a términos de licencia y condiciones que pueden ser libremente seleccionados. En cualquier caso, el código fuente de las librerías sujetas a LGPL debe entregarse a los clientes, de tal modo que puedan modificar y reenlazar el código.

Licencia BSD

La licencia BSD es uno de las modelos de licencia gratuita más antiguos. UC Berkeley desarrolló este modelo de licencia para la distribución de versiones modificadas de Unix.

La licencia BSD permite la copia gratuita de software con o sin modificaciones del usuario, como código fuente y/o como binarios en las siguientes condiciones:

Cuando se distribuye el software, la nota de copyright y la propia licencia BSD, deben ser incluidos en los ficheros en cuestión.

Si el software es distribuido en formato binario, la nota de copyright y los términos y condiciones de la licencia BSD deben estar contenidos en la documentación del programa o en cualquier otro sitio.

Sin un permiso por escrito, ni el nombre de la universidad, ni los nombres de los autores pueden ser utilizados con fines publicitarios.

La versión original de la licencia incluía además otra disposición de conformidad por la que cualquier material publicitario para una funcionalidad bajo licencia debía incluir la frase “Este producto incluye software desarrollado por la Universidad de California en Berkeley y sus colaboradores”. Esta cláusula fue eliminada de la licencia antigua y la última versión de Berkeley fue licenciada bajo una nueva variante. Esto explica porqué se han usado los términos “antigua” y “nueva” licencia BSD.

La licencia BSD no incluye ninguna restricción por el uso y distribución de código fuente y programas. El único requerimiento es una disposición de conformidad de copyright la cual debe anexarse a los términos de la licencia BSD y una renuncia de garantía junto con el producto. La licencia no estipula explícitamente que el software modificado deba ser distribuido como código fuente. Esto significa que cualquier empresa de software puede integrar código fuente sujeto a la licencia BSD en uno de sus productos y posteriormente mantener el código fuente oculto.

Comparada con las licencias descritas más adelante, la licencia BSD está sujeta a ciertas restricciones que pueden, incluso, ser consideradas de menor relevancia.

Fuentes de información

Los resultados que se presentan en esta guía se basan principalmente en las siguientes fuentes:

Experiencia obtenida en proyectos previos de migración

Experiencia en el desarrollo de productos OSS y COLS

Integración del saber hacer de expertos

Estudios de viabilidad de proyectos propuestos de migración

Conceptos detallados de migración

Documentación de migración

Literatura técnica y de producto

La información técnica importante para esta guía fue recolectada mediante:

búsqueda intensiva en la literatura

encuestas y su evaluación

grupos de trabajo sobre temas concretos así como

la implicación directa de numerosos expertos y productores de software.

Los contenidos y averiguaciones recogidos de la información antes mencionada y de otras fuentes de conocimiento fue agrupada y organizada de acuerdo con los temas, analizada y evaluada para los fines de los diversos asuntos que son considerados en esta guía.

Experiencia con proyectos de migración

El asunto “Integrar y utilizar OSS” está en la agenda tanto de las administraciones públicas como de la industria. Esto ha dado lugar a un número de proyectos de migración en los que la experiencia y las averiguaciones hasta la fecha pueden ser utilizadas. Más allá de la información y experiencias puramente tecnológicas, estos proyectos llevan a conclusiones importantes sobre factores críticos de éxito (ver apartado 5.5.3) así como la información suficiente que se espera para los pasos individuales de la migración.

El informe se realizó sobre la base de varios tipos de documentos, como conceptos técnicos detallados, especificaciones de prestaciones y resúmenes de documentación de proyectos. Este análisis sirve también como base para el desarrollo de encuestas para los estudios de proyectos individuales.

La información fue normalmente recogida en encuestas en agencias públicas y compañías realizando proyectos de migración y/o con los administradores, usuarios y desarrolladores involucrados. Las preguntas abarcaban los siguientes aspectos:

Situación inicial

Aspectos clave del proyecto

Motivación y objetivos

Factores clave de éxito

Costes y beneficios

Lecciones aprendidas

Proyectos derivados – Estrategia de desarrollo de las TI

Estas preguntas se complementaban con preguntas técnicas de detalle en relación con proyectos parciales de migración correspondientes a los retos técnicos específicos de estos proyectos individuales.

Los proyectos de migración pueden basarse en la experiencia de proyectos piloto que fueron iniciados por la Oficina Federal Alemana para la Seguridad de la Información (BSI) dependiente del

Ministerio Federal del Interior (BMI). En el momento de realizar la revisión, estos proyectos se habían completado en gran medida y con un éxito considerable.

Adicionalmente, fueron revisados otros proyectos en administraciones públicas y en la industria, que estaban siendo guiados sobre la base de sus propias evaluaciones de eficiencia económica. La información y experiencia de esos proyectos también ha sido considerada en esta guía de migración.

Las situaciones de partida de todos estos proyectos han sido y siguen siendo muy diferentes. Muchos casos implicaban sistemas basados en Windows NT-4 en el lado del servidor que debían de ser reemplazados y consolidados. Incluso, también existían entornos híbridos con Windows NT, Unix y Linux en el lado del servidor. Todas las variantes del mundo Windows – desde Windows 95 hasta Windows XP – estaban representadas en el lado del cliente. Reflejando el estado actual de equipamiento de la mayoría de las agencias públicas, las estaciones de trabajo Windows NT 4 representaban la mayor parte de los casos.

El alcance y los tipos de migración demostraron ser también muy diversos. Además de migraciones completas (servidores y clientes), también se realizaron migraciones de servidor, con Windows NT 4 permaneciendo en el lado del cliente. En gran medida, fue posible la reutilización de las estructuras de permisos y ficheros ya existentes sin necesidad de realizar cambios en los clientes NT y sin afectar a los usuarios en el cambio. Adicionalmente, uno de los proyectos de migración estudiados consistía en una migración total de los clientes donde los clientes Linux fueron integrados en una red NT4 previamente existente. También debemos mencionar otro proyecto de migración con migración de servidor de una parte, y migración de los clientes “pesados” originales a clientes “ligeros” de la otra. Para permitir la continuidad del uso de las aplicaciones Windows que se requerían (aplicaciones especiales)y para las cuales no existía la variante en Linux ni alternativa alguna en Linux, se introdujo el software de servicios de terminales y emulación de programas en este caso.

Desde un punto de vista técnico, existía experiencia práctica sobre la migración de aplicaciones importantes y servicios de sistema. Los casos incluían:

Migraciones de bases de datos, incluyendo la migración de una base de datos MS SQL Server a SAP DB, manteniendo la aplicación Visual Basic en el lado del cliente.

Migración de servicios de infraestructura

Servicios de ficheros/disco (incluso en entornos heterogéneos con Samba)

Servicios de impresión

Servicios de autentificación (incluso con servicio de directorios OpenLDAP)

Servicios de red

Migración de Office

Migración de servidor de Web

y muchos más

Los proyectos piloto iniciados por el BSI se pusieron en práctica en las siguientes agencias públicas:

Oficina federal alemana de monopolios

Comisión de monopolios

Instituto para la Ciencia y la Reproducción animal de Mariensee

Otros proyectos de los que también se han reunido datos o bien se encuentran aún en proceso de planificación e implementación, o ya se han concluido en las siguientes agencias:

Comisionado federal de Protección de Datos (BFD)

BUNDESVERWALTUNGSAMT (BVA)

BSI

Además, varias compañías han contribuido con información muy valiosa procedente de proyectos en áreas de infraestructura y aplicación, especialmente en el uso de sistemas ERP y DBMS así como en el uso de tecnologías de servidor de terminales y plataformas de gestión de sistemas.

2.5.2 Integración de expertos

Además de la evaluación de las experiencias y resultados obtenidos en los proyectos de migración,

varios expertos de la comunidad OSS y proveedores de servicios OSS, así como de la industria del software, colaboraron en preparar los contenidos de esta guía de migración. Estos expertos colaboraron principalmente en seminarios, en reunir información y en dar repuesta a problemas técnicos, así como en participar como autores activos de esta guía y asegurar su calidad.

Los seminarios sobre los temas elegidos con participación de expertos, administradores y usuarios, resultaron ser de gran utilidad para clarificar las cuestiones abiertas. Se celebraron seminarios en los que se trataron los siguientes temas:

Migración en un entorno de sistemas heterogéneos con Linux y Windows usando Samba.

Migración del DBMS desde MS SQL Server 7 a un sistema de gestión de bases de datos libre o a un sistema de gestión de bases de datos bajo Linux.

Migración del Groupware desde Exchange 5.5. con vista a utilizarlo en entornos heterogéneos con un uso continuado de MS Outlook.

Migración de aplicaciones de escritorio centrada en la migración de Office (De Office97/2000 a OpenOffice/StarOffice) y la consiguiente reutilización de los documentos, plantillas, macros y scripts existentes.

Uso de servicios de directorio, que incluyen el uso del servicio de directorio de código abierto OpenLDAP, incluso junto al directorio activo en escenarios de sistemas heterogéneos.

Uso de WIBE21 para evaluar la eficiencia económica de los proyectos de migración.

3. Descripción técnica de las fases de migración

3.1 Introducción

Las descripciones técnicas hacen una aproximación más técnica a los distintos productos, soluciones y servicios descritos en el capítulo 2 en los sistemas de TI en cuestión:

Se trataron los siguientes aspectos:

Servicios de infraestructura

Servicios de ficheros

Servicios de impresión

Servicios de autenticación

Servicios de red

Componentes middleware y de integración

Servicios de Directorio

Modelo de componentes de objetos

Plataformas para sistemas distribuidos y servicios web

XML

Servicios de Directorio

Servicios en Servidores

Groupware y mensajería

Servidores de bases de datos

Servidores Web

Servicios especiales

Aplicaciones de escritorio, incluyendo el paquete Office

Las descripciones se centran en la posibilidad técnica de migrar productos individuales de Microsoft a soluciones OSS o COLS adecuadas. Se analizarán en detalle los siguientes aspectos para los componentes individuales de este escenario partiendo del escenario de sistemas IT establecido por Windows, descrito en el capítulo 2.1:

¿Cual es la situación inicial?

¿Qué funciones importantes están disponibles?

¿Qué interfaces existen y/o a cual hay que dar servicio?

¿Cuáles son las características especiales durante la operación?

¿Qué alternativas están disponibles en OSS o, si aplica, en soluciones COLS?

¿Cuáles son las diferencias funcionales?

¿Se cumplen los requerimientos críticos?

¿ Qué debe tenerse en cuenta a la hora de migrar?, ¿donde están los problemas?, ¿como pueden resolverse?

¿Existen múltiples alternativas?, ¿para quien y/o con que propósito pueden utilizarse dichas alternativas?

¿Cómo pueden dichas alternativas integrarse en mundos completamente heterogéneos? Si es necesario, ¿Como interaccionan entre ellas? (Especialmente con Microsoft, compatibilidad e interoperabilidad)

¿Cuales son las repercusiones de la integración potencial en un futuro con la linea de productos de Microsoft?

¿Que potenciales existen si el uso de la linea de productos de Microsoft continúa?

¿Que funcionalidades adicionales están disponibles?

¿Donde residen los mayores cambios?

¿Cubren dichas innovaciones y posibles modificaciones los requerimientos críticos?

¿Que debe tenerse en cuenta debido a la independencia de los sistemas?

La descripciones normalmente finalizan con una breve evaluación. Si existen múltiples alternativas, son soluciones comparables e igualmente comentadas, si existe la posibilidad de llevarse a cabo.

Sistema de ficheros

Perspectiva general

El resultado de las descripciones detalladas de los servicios que se cubren pueden ser resumidas como sigue:

En el caso de la sustitución directa de un servidor Windows NT como sistema de almacenamiento de ficheros, manteniendo fijos los clientes Windows, Samba es el sistema idóneo dentro de la comunidad de código abierto. Samba se comporta como si de un servidor Windows NT se tratase, desde el punto de vista de los clientes Windows. Samba esta en continua actualización y soporte, no solo por la comunidad sino que también esta creciendo entre proveedores de servicios IT.

Dependiendo de la envergadura de la migración Linux desde el punto de vista del cliente, NFS y AFS también son alternativas muy interesantes. NFS y AFS están ampliamente extendidos entre redes UNIX, pero debe instalarse software adicional en los clientes para poder integrar clientes Windows. Un cliente NFS se incluye, por ejemplo, en los Servicios de Microsoft Windows para UNIX (SFU 3.0).

El cliente AFS está disponible libre de cargos y con su código fuente en OpenAFS.org. El uso de NFS y AFS en un entorno de clientes Windows siempre requiere un gran cambio en cuanto a conceptos en comparación con Windows NT.

El concepto de seguridad de Kerberos, que también oculta el directorio activo de Windows 2000, juega un papel importante que viene a modernizar la infraestructura IT dentro de un proyecto de migración. La posibilidad de ver OpenAFS como alternativa a Windows2000

como servidor de ficheros debería ser evaluada con más detalle si el cliente final sigue utilizando la linea de productos de Windows.

Los sistemas de ficheros más apropiados para el almacenamiento físico de datos en sistemas de discos de servidores reales son , por ejemplo, XFS y EXT3. Ambos sistemas soportan “journaling”, “quotas” y la asignación de privilegios de acceso a nivel de fichero y de directorio. Tanto XFS como EXT3 soportan atributos extendidos de ficheros como abd POSIX-ACL's para garantizar los derechos. Cuando se “mapea/traduce” de Windows-ACL a POSIX-ACL debe tenerse cuidado, puesto que la fina granularidad con la que los privilegios pueden ser definidas bajo Windows, se pierden. Como análisis final, las repercusiones que ambas restricciones tienen en dicho caso o si son aceptables, deben ser analizadas profundamente.

Windows NT 4

Requisitos funcionales

La funcionalidad general de un sistema basado en red consiste en los siguientes puntos:

- Recibir (escribir) y entregar (leer) ficheros.

- Crear y presentar una estructura de directorios.

- Administrar y presentar “meta-datos” para directorios y ficheros.

- Implementar los privilegios de acceso y restricciones en ficheros y	directorios.

- Deshabilitar accesos a ficheros en el caso de que se produzca un	conflicto.

En la mayoría de los entornos, los servicios de ficheros de Windows Nt se utilizan para los siguientes propósitos:

Almacenamiento de ficheros específicos de cada usuario (directorios /home)

Almacenamiento de los perfiles basados en servidores si se requiere soporte optimizado para usuarios que interactúan con distintas máquinas.

Almacenamiento de ficheros de grupos, específicos de usuarios (carpetas de grupo) que serán utilizadas únicamente por un conjunto determinado de usuarios (por departamentos, por ejemplo).

Almacenamiento de bases de datos basadas en ficheros que serán utilizados por distintos usuarios al mismo tiempo (como la base de datos de MS Access pero con “frontent” separado).

Almacenamiento de programas (ficheros .exe, ficheros .dll, etc de aplicaciones) para evitar la necesidad de almacenar dichos ficheros localmente en la máquina cliente.

Almacenamiento de sistemas de bases de datos que permiten el almacenamiento de datos del usuario en otro servidor bajo una ruta “UNC”.

En la práctica, los usos aquí descritos normalmente varían mucho en cuanto a detalles según requisitos, que serán resaltados en las secciones que siguen.

El sistema de ficheros NTFS4

El sistema de ficheros NTFS4 es la base del almacenamiento y manejo de ficheros bajo Windows NT4.

Propiedades

Las propiedades de NTFS4 incluyen, por ejemplo, lo siguiente:

La carpeta de cada fichero tiene asignado lo que se denomina una lista de control de acceso (ACL, Access Control List), que se almacena en el mismo fichero o carpeta. La ACL contiene lo que se denomina entradas de control de acceso (ACE, Access Control Entries) que contienen el SID del grupo o usuario y la autorización correspondiente.

El acceso es también controlado a través de la ACL y es posible implementar un sistema de control de acceso granular. La ACL debe ser a su vez fragmentada en listas de control de acceso al sistema (SACL, System Access Control List) y en listas de control de acceso discrecional (DACL, Discretional Access Control List): Las DACLs contienen los SID de los grupos y usuarios que están autorizados a acceder a dicho objeto o no. Las SACLs determinan el modo en que el subsistema monitoriza el acceso al objeto.

En principio, NTFS4 no soporta herencia: Sólo cuando se crea un fichero nuevo, los privilegios de la carpeta se copian en la ACL (lista de control de acceso) de dicho fichero. Cuando los privilegios de la carpeta cambian, la herencia de los privilegios de las ACL que contienen los ficheros de dicha carpeta, debe ser activada explícitamente. Debemos considerar otra característica especial: Un fichero que se almacena en la ruta UNC \\servidor\\freigabe\\ordner\\subordner puede ser leído por un usuario aunque la carpeta “ordner” prohíba su lectura, siempre que la carpeta “subordner” lo permita.

No existe limite en la longitud del nombre de la ruta. Se soportan los nombres de ficheros con más de 256 caracteres. Aparte de nuevas excepciones (como *, \), todos los caracteres del conjunto de caracteres Unicode de 16 bits pueden ser, teóricamente, utilizados. Los nombres cortos corresponden a la convención 8.3. Los genera automáticamente el sistema operativo cuando se almacene cualquier directorio o fichero. Aunque las mayúsculas y las minúsculas se omitan durante el almacenaje, no se discriminarán durante el proceso de acceso al fichero.

Cada carpeta y cada fichero tiene sus atributos almacenados en forma de “flags” (protección de escritura, archivos, sistemas, ocultos y comprimidos) al igual que la fecha en la que se crearon por primera vez, la fecha en la que se hizo el último cambio y la fecha del último acceso. El grado de compresión depende exclusivamente del contenido del fichero.

NTFS soporta la tecnología de cadenas múltiples. Su frecuencia de uso es relativamente baja. Las cadenas múltiples deben ser soportadas por la aplicación en cuestión, y/o deberá ser programada en la misma. Se habilitarán, por ejemplo, en el almacenamiento de recurso Folk de ficheros en Macintosh.

Desde el Service Pack 4, NTFS es capaz de manejar “quotas” (limites). La asignación y control de limites de uso en disco (quotas) está basada en la propiedad del propietario y cubren todo el volumen (dispositivo lógico del servidor de ficheros). Debido a restricciones técnicas, el uso de limites de espacio en disco debe ser considerada como una excepción más que como una regla existente en algunos entornos.

El tamaño máximo de un fichero en NTFS4 son 2TB (terabytes), al igual que la capacidad del dispositivo lógico. La capacidad máxima del dispositivo lógico cubre 2TB ( teóricamente 16 exabytes). La cantidad real de datos en red depende del tamaño del cluster que se utilice durante el formateo. El numero de ficheros esta limitado a 232-1.

NTFS habilita el registro de intentos y accesos satisfactorios. De este modo, es posible, por ejemplo, diagnosticar repetidamente la eliminación indeseada de ficheros .

Los volúmenes de datos con formato NTFS son defragmentados continuamente durante las operaciones. La corrección automática (autocorrección) bajo Windows NT 4 no existe. Si se desea activar esta herramienta se deberán contratar los servicios de una tercera empresa.

El sistema de privilegios de NTFS

Windows reconoce un total de 13 privilegios que pueden ser asignados a un objeto dentro del sistema de ficheros (nos referiremos a directorios y ficheros como objetos, indistintamente) para cada usuario o grupo:

Navegar por carpeta/ ejecutar un fichero.

Listar carpetas / leer fichero.

Leer atributos.

Leer atributos extendidos.

Crear ficheros / escribir datos.

Crear carpetas / agregar datos.

Escribir atributos.

Escribir atributos extendidos.

Eliminar subcarpetas y ficheros.

Eliminar.

Leer privilegios.

Cambiar privilegios.

Transferir privilegios de propietario.

Los cambios en los privilegios de acceso se realizan a traves de la pestaña de “configuración de seguridad” del diálogo de “propiedades”. Con el fin de encubrir la complejidad de los 13 privilegios del sistema que están estrechamente relacionados, de los usuarios promedio, esta pestaña ofrece la posibilidad de preseleccionar algunos hitos, denominados “privilegios de grupo” como una combinación más apropiada de los privilegios individuales. Existen 5 privilegios de grupo para ficheros y 6 para directorios. Los 13 privilegios individuales se muestran en el dialogo de “Entrada de privilegios” que se accede a traves de los botones “extender/mostrar/editar”.

En este contexto, el punto de vista de los privilegios de grupo ofrecidos en la configuración de seguridad es extremadamente problemático porque la presentación puede sugerir fácilmente la falta de algunos privilegios, que de echo, existen. En el caso de acceso completo, por ejemplo, donde el privilegio de escritura de atributos extendidos es el único privilegio que no puede ser heredado, la presentación esquemática de la configuración de seguridad muestra un dibujo de perfiles de privilegio que habilitan únicamente lectura y ejecución. La tabla que sigue muestra que combinaciones de privilegios corresponden a que privilegios de grupo. Por favor, recuerde que la casilla de privilegios de grupo permanecerá activa aunque únicamente este activo un único privilegio.

Tabla 3: Propiedades de los privilegios de grupo de Windows.

Privilegios de grupo de Windows

Debido a las inconsistencias descritas anteriormente, solo se tendrá en cuenta la vista extendida del dialogo de “entrada de privilegios”.

Atributos del sistema

Además de los privilegios, se aplicarán numerosos atributos y atributos extendidos a ficheros y directorios.

Tabla 4: Atributos de Windows.

Intervención

Auditoría

Windows incluye opciones de auditoría de largo alcance a nivel de fichero y directorio. Es posible, por ejemplo, auditar todos los privilegios de forma individual para cada usuario o grupo. La información generada se almacena en el log de seguridad del controlador de dominio y/o del ordenador Windows 2000 implicado si la directiva de auditoría está activada en la directiva del sistema.

Control de acceso

El control de acceso a ficheros y directorios a través de la red en entornos Windows NT se puede llevar a cabo mediante los dos mecanismos siguientes:

Abrir directorios (compartir)

Privilegios NTFS

Para poder acceder a ficheros a través de la red, se debe liberar o abrir uno de los directorios del nivel más alto. Esta liberación da origen a un ACL que se almacena en el registro. Los privilegios para esta operación de liberación se restringen a los siguientes niveles:

Lectura

Escritura

Acceso Total

Estos privilegios se aplican de forma absoluta. Esto significa que los privilegios NTFS localizados por debajo son sobreescritos por los privilegios de liberación. Ejemplo: un privilegio de lectura a nivel de liberación impide la escritura aun cuando los privilegios NTFS lo permitan.

Se debe prestar especial atención en entornos Windows NT a los privilegios (directivas para privilegios de usuario) debido a que esos privilegios pueden ser importantes para los servicios de ficheros, por ejemplo, “tomando la propiedad de ficheros y objetos” y “grabación de ficheros y directorios”.

Concepto de usuarios y grupo

Cada directorio y cada fichero se asignan a un propietario que puede ser tanto un grupo como un usuario. El usuario que crea el fichero, normalmente se convierte en el propietario. Si el usuario es un miembro del grupo de administradores, este grupo se convierte en el propietario.

El control de acceso sistemático en el entorno Windows NT utiliza con preferencia la asignación de privilegios a grupos. La asignación de privilegios a cuentas de usuario individuales debería dejarse para sistemas de ficheros específicos de usuario.

En un entorno Windows NT existen los siguientes tipos de grupos:

Grupos globales

Grupos locales en servidores miembros

Grupos locales en controladores de dominio

Los grupos locales en los Controladores de Dominio difieren de los grupos locales en los Servidores Miembros en que, en el caso de los primeros, existen en todos ellos con el mismo SID (Identificador de Seguridad).

Los grupos locales en los Servidores Miembros pueden ser anidados (anidación de grupos) con los siguientes grupos:

Con los grupos globales del dominio propio

Con los grupos globales de los dominios en los que uno confía.

Los grupos globales sólo tienen cuentas de usuario como miembros.

En el ámbito de dominios de Windows NT existen dos principios “clásicos” de control de acceso diferentes:

Método U-G-L-R (Usuario-Global-Local-Recurso):

El usuario es miembro de un grupo global. Este grupo global por su lado es miembro de un grupo local en un servidor de ficheros. Este grupo local es el único para el que se establecen privilegios NTFS en el recurso de ficheros. (ver fig. 4)

Método U-G-R (Usuario-Global-Recurso):

El usuario es miembro de un grupo global. Este grupo global es el único para el que se establecen privilegios NTFS en el recurso de ficheros. (ver fig. 5)

[... Figura 4 ....]

Figura 4: método U-G-L-R.

Una asignación no ambigua de un recurso y un grupo local (o grupo global, respectivamente) es una condición para que ambos métodos funcionen sin riesgo.

Esto significa que el grupo es usado por este recurso de forma exclusiva.

Si el servicio de ficheros está implementado por un cluster, el método U-G-L-R tiene el inconveniente que el grupo local en el nodo servidor no puede tener el mismo SIDs. Esto puede remediarse configurando los nodos como controladores de dominio o usando el método U-G-R.

Herramientas

Windows NT ofrece una selección limitada de herramientas para la gestión de ficheros, carpetas y sus privilegios.

Con la interface gráfica de usuario:

Explorador NT (explorer.exe)

Gestor de fichero (filemanager.exe)

Y sólo en la línea de comandos:

calcs

Herramientas del Kit de Recursos: xcacls, scopy, etc.

Las herramientas ofrecidas por Windows NT a menudo ofrecen menos que la funcionalidad completa.

El explorador de NT por ejemplo es el mejor ejemplo de esto: no es posible establecer el propietario (solo aceptarlo) o copiar las ACLs (Listas de Control de Acceso).

Uno debe por lo tanto asumir que el administrador de un entorno NT utilice herramientas de terceros fabricantes o desarrolle sus propios scripts (como Perl)

para facilitar la administración o para ejecutar tareas muy especiales.

Esto hace que la estructura de privilegios mostrada por un Explorador de NT difiera de los verdaderos accesos concedidos.

Protocolos de red

La comunicación con servidores de ficheros Windows NT vía red puede estar basada en diferentes protocolos de transporte

TCP/IP

NetBEUI

SPX/IPX

Appletalk

TCP/ IP, NetBEUI y SPX/ IPX son poco probables en un entorno NT. Generalmente se asume que TCP/IP será el único protocolo en el futuro. Esta es la razón por la que el “Servicio Pasarela para Netware” y los “Servicios de Impresión y Ficheros de Macintosh” no se tratan aquí.

Con respecto al servicio de ficheros,

SMB (Servidor de bloques de mensajes) via NetBT (NetBIOS sobre TPC/IP)

puede ser visto como el estándar con los puertos 137/UDP/TCP (nbname), 138/UDP (nbdatagram) y 139/TCP (nbsession).

Conectando

La difusión en estos servidores de ficheros está disponible normalmente para el usuario en forma de letras de unidad. Esto ha menudo se realiza vía scripts en el inicio de sesión. Además, los usuarios pueden navegar en una red Windows. Esto hace que los usuarios puedan clicar en el servidor de ficheros y conectarse a una unidad de red o pueden abrirlo directamente.

Características especiales a considerar durante la operación en producción en caso de migración

A continuación se describen algunas características especiales que pueden tener puntos críticos en un proyecto de migración:

Con respecto al almacenamiento de los ficheros específicos de un usuario (directorio home), se demanda algunas veces que los datos almacenados sólo puedan ser leídos por el usuario y por el sistema operativo (para protección de virus, por ejemplo). Windows NT permite guardar los eventos en estos casos.

El almacenamiento de los perfiles basados en servidor esta sujeto a un proceso complicado en el cliente durante el proceso de escritura. Se debe asegurar una comunicación y una estructura de privilegios libres de fallos, especialmente en entornos de terminal server donde se especifican los perfiles basados en servidor como características obligada.

TECHNICAL DESCRIPTION OF THE MIGRATION PATHS

Version: 29.08.2003 Page 47

Algunos ficheros específicos de grupo pueden ser accedidos por varios usuarios al mismo tiempo. En este caso es interesante que dichos usuarios sean informados del uso compartido del documento. Por ejemplo: un usuario que abre un fichero “Word” en segundo lugar recibe un mensaje indicando que el “usuario1” ya tiene en uso el archivo, de forma que él únicamente tendrá opción a abrirlo en modo de solo lectura.

Se debe garantizar un sistema de bloqueo “a prueba de fallos” cuando tratamos el almacenamiento de bases de datos basadas en ficheros; que incluyen, por ejemplo, lo ficheros “.pst” (las carpetas personales de “Outlook”).

A menudo, el almacenamiento de ficheros de programa no es posible en modo protegido contra escritura. Así, se requiere una granularidad mayor (algo así como “escritura pero no borrado”, por ejemplo).

Sólo unas pocas aplicaciones con sistemas de bases de datos (como MS SQL) ofrecen la opción de almacenar los datos de usuario en otro servidor bajo un trayecto tipo UNC. En cualquier caso, la comunicación libre de fallos y el almacenamiento es una cuestión muy crítica que queda como responsabilidad del suministrador de la aplicación.

3.2.2.9 Cuestiones relacionadas

El servicio de ficheros en WindowsNT debe abarcar no sólo los requisitos habituales en servicio de ficheros; sino que, además, debe cubrir otra serie de funciones importantes como condición previa para su utilización por parte de productos de terceros.

Protección contra virus: normalmente se implementa mediante la instalación local de un programa antivirus en el servidor de ficheros. Un servicio instalado localmente, es una condición previa para poder revisar el fichero durante el acceso. Esta es la forma en que la mayoría de los suministradores de programas antivirus encaran el problema. La opción alternativa es realizar un examen de las distintas unidades del equipo servidor a través de la red desde otro equipo. En este último caso hay una desventaja inmediata: un incremento de la carga y el retardo.

Citas: El sistema de citas ofrecido por WindowsNT normalmente no se utiliza. Es preciso utilizar un producto de terceros para introducir citas en sistemas de ficheros pertenecientes a usuarios o grupos específicos.

Copias de seguridad: la herramienta incluida en el sistema “NTBACKUP” se usa con poca frecuencia. Los servidores de ficheros bajo WindowsNT normalmente se integran mediante un programa agente (instalado localmente), en un sistema más amplio que asegura la centralización y uniformidad de las políticas de copia de seguridad para cualquier sistema (bases de datos, correo). El tiempo de recuperación en caso de desastre es vital en este contexto. Una característica especial de la herramienta “NTBACKUP” es la posibilidad de hacer copias de ficheros que de otra forma no podrían ser leídos por el usuario.

Almacenamiento: el almacenamiento seguro normalmente se implementa a través del concepto de copias de seguridad. Es más, algunos productos de terceros

Technical description of the migration paths

Page 48 Version: 28.09.2003

permiten el transvase de ficheros poco utilizados a otros sistemas/medios de almacenamiento en aras de una mejor eficiencia económica del sistema.

3.2.3 Migración por reemplazo

3.2.3.1 Introducción

En relación con el sistema de almacenamiento, esta guía asume que es posible la centralización del almacenamiento en, al menos, un servidor NT; y que los ficheros son accedidos en ese momento por los clientes Windows. Si se identificaran otros objetivos de migración, fuera de la línea de productos Microsoft, debemos diferenciar entre la migración de escenarios donde se busca una alternativa al equipo servidor, o donde se ofrece a los clientes una nueva plataforma con un nuevo sistema operativo.

Deben considerarse dos niveles en el caso de la migración del servidor. Por un lado, cada servidor tiene un sistema de ficheros local donde se gestionan todos los ficheros; por otro, al menos un subconjunto de dichos ficheros es exportado a los clientes a través de un servicio y su correspondiente protocolo de red.

Reemplazar un sistema WindowsNT como servidor de ficheros implica, en el primer nivel, exportar los datos y programas existente del sistema viejo al nuevo. Esto también implica el ajuste de los privilegios del sistema para el acceso a los ficheros y directorios, así como adaptar conceptos operativos como, por ejemplo, en lo tocante a las copias de seguridad.

En un segundo nivel debemos replicar las funcionalidades existentes, bien con los clientes en funcionamiento o con una nueva propuesta de arquitectura. Es este segundo nivel la clave de la infraestructura del “sistema de almacenamiento de ficheros”. El análisis se centrará en primer lugar en cuestiones de “privilegios de acceso en el nivel de fichero y directorio” y en “funcionalidades generales del sistema de almacenamiento de ficheros”.

Las siguientes alternativas pueden ser consideradas para la sustitución de un servidor de ficheros NT 4.0:

UNIX/Linux con samba – una copia del sistema de ficheros del servidor NT.

UNIX/Linux con NFS – el sistema de ficheros en red tradicional de UNIX.

UNIX/Linux con OpenAFS – el sistema de ficheros con red con autentificación mediante Kerberos, desarrollado por IBM.

Otros sistemas de ficheros en red alternativos a los propuestos están aún en fase de desarrollo en entornos universitarios, o bien están basados parcialmente en software propietario y no serán objeto de discusión en el presente documento.

3.2.3.2 Comparación de las funcionalidades generales de los sistemas de ficheros en red

Desde una perspectiva funcional, las características de los sistemas de ficheros subyacentes del servidor también afectan a los sistemas de ficheros en red. En relación con los servidores Linux, esta comparación se centra en los sistemas de ficheros XFS o EXT3.

Table 5: Comparison of file servers

En el caso de reemplazar un servidor WindowsNT como elemento de almacenamiento, manteniendo los clientes Windows, Samba es la opción código abierto. Samba se comporta de forma idéntica a un servidor NT desde el punto de vista del cliente Windows. Además, está siendo actualizado con regularidad no sólo por la comunidad, sino por un número creciente de proveedores de servicios IT.

En función de hasta dónde lleguemos con la migración en el lado cliente, NFS y AFS podrían ser las alternativas. Ambos son ampliamente utilizados en redes Unix,

22 Available as a patch for Ext2/3 file systems, for example.

23 Available as a patch for Ext2/3 file systems, for example.

24 TB Terabyte 1012, PB Petabyte 1015, EB Exabyte 1018

25 NFSv3 with XFS file system

Technical description of the migration paths

Page 50 Version: 28.09.2003

si bien es preciso instalar software especial en todos los equipos cliente para poder llevar a cabo la migración; por ejemplo, el cliente NFS incluido entre los “Servicios Unix para Microsoft Windows (SFU 3.0)”. De “OpenAFS.org” es posible descargar un cliente AFS libre y desarrollado como OpenSource. En cualquier caso, la utilización de NFS y AFS en un entorno Windows requiere una serie de cambios conceptuales más profundos en comparación con el entorno original WindowsNT.

Si la seguridad ofrecida por Kerberos, incluida también como parte del directorio activo de Windows2000, es un requisito importante en el proceso de modernización de la infraestructura de IT, podremos evaluar con detalle OpenAFS como una alternativa a Windows2000 si pensamos mantener la línea Windows en el lado cliente.

3.2.3.3 Samba

Las opciones de implementar un sistema de ficheros centralizado para los clientes Windows (únicamente), o para un entorno heterogéneo de clientes; son esencialmente las mismas. No existe una razón de peso que nos permita decantarnos por una u otra solución. En relación a la administración del entorno, cualquiera de las opciones requiere cambios más o menos relevantes. Siendo conservadores en la solución a la migración, los servidores SMB/CIF Samba y Windows2000 ofrecen una mayor posibilidad de reutilización de los conceptos previos.

En muchos aspectos Samba es un clónico del servicio de almacenamiento, impresión y autentificación de WindowsNT. Desde el punto de vista de los usuarios, Samba es lo más parecido a un servidor WindowsNT. Desde el punto de vista del administrador, Samba es un servidor UNIX; por ello el manejo de debe adecuarse a la filosofía y posibilidades del nuevo sistema operativo.

Windows2000 como sucesor de Windows NT apenas presenta cambios significativos para los usuarios en su relación con Samba. Para los administradores, la introducción del directorio activo con los componentes DNS, LDAP y Kerberos implica unos cambios sensiblemente más profundos.

Hasta qué punto el cambio o el desarrollo en una dirección u otra resulta más fácil o favorable depende en buena medida de cada cual. La migración a Samba/Linux y aplicaciones OpenSource abre una serie de nuevos grados de libertad. Esta decisión que nos independiza de los estándares y prácticas de los distintos desarrolladores, significa para el administrador no sólo más libertad y autonomía, sino una fuente potencial de errores y problemas. El servidor Samba cumple con los requisitos de almacenamiento como cualquier servidor NT. Los usuarios pueden obtener sus perfiles, “logon scripts” y directorios de usuario desde el servidor Samba. Los programas ejecutables (.exe) pueden almacenarse sin problemas en el servidor Samba y pueden ser arrancados sin problemas desde ahí. Esto es también aplicable a las bases de datos Access o cualquier otro fichero que requiera un sistema de bloqueo diseñado para el acceso concurrente de distintos usuarios.

En contraste con el servidor NT, Samba utiliza únicamente TCP/IP como protocolo de red. Otros servidores código abierto (Mars y Netatalk) están disponibles para

servicios basados en los protocolos SPX/IPX (de Novell) y AppleTalk (de Apple) que permiten el trabajo sobre una base de datos común en un entorno de red heterogéneo. Samba no ofrece ninguna implementación de SMB basada en el antiguo NETBIOS. NETBIOS vía IPX tampoco es soportado.

Las herramientas habituales de cliente para editar/gestionar los ficheros del sistema, siguen estando disponibles. Particularmente, el Explorador y el Gestor de Ficheros, así como cacls, xcacls, etc. pueden seguir utilizándose. El Gestor de Usuarios también puede utilizarse con Samba 3.0. A pesar de que es posible seguir utilizando el Gestor de Servidores, esto resulta menos conveniente, porque implica el abandono de la transparencia en la configuración del servidor (smb.conf).

Las conexiones a las unidades pueden establecerse automáticamente sin modificar los scripts de logon o de modo interactivo, navegando en el Entorno de Red.

El sistema de permisos de Samba y Linux hace posible que procesos especiales (como el antivirus del servidor) tengan acceso local a los ficheros de los usuarios en sus directorios de trabajo. Mientras, el acceso a través de la unidad de red está restringido al usuario solo.

El servidor Samba puede utilizarse para el almacenamiento de ficheros y la autentificación incluso en entornos con servidores de terminales Windows. Aunque Samba no soporta la extensión de objetos SAM para servidores de terminal.

Samba trata los bloqueos de ficheros (tanto a nivel de ficheros como en el rango de bytes) exactamente del mismo modo que lo hace el servidor NT. Esto significa que Samba permite tanto el uso cooperativo de ficheros como el uso de bases de datos basadas en ficheros, de la misma forma que un servidor NT.

Las cuotas de disco (así como las cuotas para otros recursos del sistema) son ofrecidas por el sistema operativo GNU/Linux y, por lo tanto, también están disponibles para el sistema de ficheros ofrecido por el servidor Samba.

Varias herramientas de código abierto están disponibles bajo Linux para realizar copias de seguridad, control de versiones como de archivo. Más aún, los servidores Linux pueden integrarse fácilmente en los conceptos de backup de muchos productos comerciales.

La alta disponibilidad obtenida con NT mediante el cluster de la Edición Enterprise también puede conseguirse con Samba, recurriendo de nuevo a SCSI compartido o a SAN con IP Failover.

Comparando con los resultados de algunos estudios recientes de funcionalidad hay ahora muchas menos restricciones funcionales referentes al uso de Samba. La versión de Samba 3.0 permite el establecimiento de relaciones de confianza entre dominios maestros y de recursos, y la implementación del concepto de dominio de Windows NT. La versión 3.0 también permite utilizar el Gestor de Usuarios de Windows para la administración de usuarios, por ejemplo, para crear nuevos usuarios. La replicación entre controladores de dominio Windows y Samba sigue sin ser posible, por lo que, en un dominio, sólo pueden utilizarse controladores Windows o Samba puros. Si es necesaria la integración de servicios de servidores Windows en un dominio Samba, estos pueden ser integrados como servidores miembros. La replicación SAM en un controlador de dominio Samba puro es posible, sin ningún problema, combinando Samba y OpenLDAP. OpenLDAP es utilizado por Samba para gestionar grupos y usuarios, y también ofrece los mecanismos de replicación necesarios.

Comparación de Sistemas de Ficheros

Tabla 6: comparación de sistemas de ficheros

	NTFS	XFS	EXT3	ResiserFS
Longitud de los nombres de ficheros	256	256	256	256
Juego de caracteres para los nombres de ficheros	Unicode	ISO-Latin	ISO-Latin	ISO-Latin
Presentación de mayúsculas y minúsculas	X	X	X	X
Discriminación de mayúsculas y minúsculas		X	X	X
Cuotas de Disco	X	X	X	X
Encriptación	EFS	X	X	X
Compresión	X	X	X	X
Tamaño máximo de fichero	2 tera	16/64 tera	4 tera	16/64 tera
Longitud máxima del camino	Ilimitada	Ilimitada	Ilimitada	Ilimitada
Registro de Cambios	X			

Almacenamiento local de ficheros con migración de cliente

El análisis de almacenamiento de ficheros se basa en la suposición de que los clientes no almacenan localmente información de usuario. En la migración, se instala un nuevo cliente con las mismas funcionalidades que el anterior, y sin importar ningún dato del cliente antiguo.

Si el número de clientes idénticos a migrar es muy elevado, debe considerarse la opción de migrar mediante un sistema de ficheros de red puro, sin la utilización de discos. Este caso especial de almacenamiento centralizado de ficheros en una red, ofrece muchas ventajas especialmente desde el punto de vista de la administración: Los cambios en los clientes se realizan una única vez en el servidor, y se extienden a todos los clientes que utilizan dicho servidor. La selección del servidor soportando un “cliente sin discos” requiere realizar las mismas consideraciones que también aplican a la selección del sistema servidor para almacenamiento centralizado de ficheros.

Control de acceso: mapeo de los perfiles de permisos de Windows a ACL's POSIX

El modo en el que Samba maneja los derechos de acceso a directorios y ficheros se corresponde en gran medida con los principios ya conocidos de Windows NT. También en Samba, se comparten directorios del servidor a los clientes. Los detalles de los permisos de acceso se determinan sobre la base de los permisos definidos en el sistema de ficheros del servidor para un usuario que se autentifique frente al servidor Samba. Los permisos son por tanto, el resultado de la interacción entre el servidor Samba, el sistema operativo y/o el sistema de ficheros.

Los recursos compartidos y sus características a nivel del servidor – como el path del directorio, permiso para accesos anónimos y protección general contra escritura – son manejados y mostrados típicamente en Samba mediante un fichero de configuración que es único por cada instancia de servidor. La edición de este fichero es también posible (tras una autentificación/autorización de acceso con protocolo cifrado HTTPS) mediante un acceso Web.

En todos los sistemas operativos, los derechos de acceso a directorios y ficheros se gestionan en el componente funcional de sistema de ficheros. Mientras que en FAT, bajo DOS y versiones antiguas de Windows, no existe el concepto de propietario, en UNIX existe desde el principio y bajo Windows desde la introducción del sistema de ficheros NT (NTFS). El sistema de ficheros utiliza las así llamadas listas de control de acceso con el fin de determinar qué usuarios y de qué manera pueden utilizar qué directorios y ficheros.

Bajo UNIX, los derechos de acceso para lectura, escritura y ejecución, se definen como mínimo para el propietario, un grupo de propietarios y el resto de usuarios de sistema. Pueden implementarse restricciones adicionales o la asignación de derechos a otros usuarios o grupos de usuarios, en ciertos sistemas de ficheros UNIX/Linux a través de atributos extendidos y Listas de Control de Acceso POSIX.

Samba, como servidor de ficheros, almacena sus datos en un sistema de ficheros UNIX y accede a los datos utilizando los derechos efectivos del usuario autentificado para el acceso. Aunque el servidor Samba puede teóricamente imponer restricciones adicionales, el servidor nunca podrá ignorar las restricciones del sistema de ficheros. En los dos casos, al trasmitir los derechos de acceso existentes del servidor al cliente y al manifestar cambios iniciados en el lado del cliente, el servidor Samba aplica el esquema de privilegios del sistema de ficheros en el que almacena y gestiona los datos de usuario. Este es el motivo por el que la migración requiere el mapeo del modelo de privilegios de Windows al mundo UNIX. Este proceso de mapeado, así como las características adicionales y restricciones que deben tenerse en cuenta, son descritos a continuación. Los autores de esta guía presuponen, en este contexto, que se utiliza un sistema de ficheros bajo Linux con soporte para POSIX-ACL. Actualmente, existen los sistemas de ficheros XFS, JFS con parches EXT2 y EXT3.

Mapeo de NTFS-ACL al sistema de privilegios Linux

Cuando la ACL de Windows se transfiere a la POSIX ACL de Linux, el sistema de privilegios se reduce en tal medida, que el resultado corresponde en gran medida a la presentación simple de los controles de seguridad.

Los únicos privilegios que reconocen las ACL POSIX son los derechos de lectura, escritura y ejecución. Las ACLs POSIX no proporcionan tipos diferentes para discriminación, tales como escribir datos, añadir datos, escribir atributos y escribir atributos extendidos. Por lo tanto, cuando el sistema de privilegios de Windows se mapea a UNIX, vía Samba, sólo es posible mapear subconjuntos completos de los privilegios de Windows al sistema de ficheros UNIX. Esto quiere decir también, en sentido inverso, que el servidor Samba no puede presentar otras agregaciones de privilegios al cliente Windows.

Tabla 7: privilegios POSIX y agregaciones Windows

[Tabla ]

Para el usuario final, se pueden utilizar diálogos Windows para generar las combinaciones de privilegios POSIX correspondientes a partir de la combinación de los privilegios NTFS apropiados. Téngase en cuenta que el establecimiento de un privilegio NTFS adicional de la lista Windows conlleva el establecimiento de todos los privilegios del agregado POSIX al que el juego de privilegios NTFS pertenece. Si, por ejemplo, el privilegio de Escribir atributos se activa en el diálogo de Entrada de Privilegios para un fichero para el que sólo estaba permitido el acceso de lectura, el servidor Samba añade automáticamente los privilegios para Escribir atributos extendidos, Escribir datos y Añadir datos. Una vez que se sale del diálogo seleccionando OK, se muestra inmediatamente un nuevo rango de privilegios, ampliado de forma significativa, al abrir de nuevo la ventana de diálogo. La ventaja que aporta este comportamiento en la parte del servidor Samba, es que evita la mala interpretación de privilegios simples de presentación.

Todo esto es consistente con la presentación simplificada de la configuración de seguridad. Los permisos de Lectura y Escritura se pueden establecer conjuntamente, por separado y como combinación de Lectura/Ejecución. Este último privilegio no puede establecerse individualmente.

Los privilegios NTFS Borrar subcarpetas/ficheros, Borrar, Cambio de privilegios y Transferir privilegios de propiedad, no pueden ser implementados bajo las ACLs POSIX y, por tanto, no llevan a ningún resultado en el servidor Samba cuando se activan (sobre fondo gris en la tabla)

No obstante, en el caso de Acceso completo y a modo de ejemplo, los privilegios totales de lectura, escritura y ejecución, también se marcan como juego.

Tabla 8: privilegios POSIX y Windows

[Tabla8]

Mapeado de la función de herencia

La implementación POSIX-ACL utiliza únicamente la herencia pasiva. No es posible la herencia activa de tipo NTFS.

Mapeo del sistema de atributos

Los atributos, que no existen bajo Unix, pueden implementarse de diferentes formas. En primer lugar, el flag Protección de escritura no se necesita realmente puesto que está incluido en el sistema normal de privilegios. De esta forma, se muestra automáticamente para los ficheros y directorios para los que no hay permiso de escritura. Los flags Archivo, Oculto y Sistema pueden representarse con el bit no utilizado Ejecutar del sistema de ficheros UNIX, por tanto este flag existe. Los atributos Comprimido y Encriptado no se pueden mapear. Pueden, no obstante, hacerse disponibles mediante otros servicios especiales bajo UNIX.

Mapeo de las funciones de auditoría

El sistema de auditoría es parte integral de Windows. Bajo UNIX puede ser representado mediante otros mecanismos. Para el servidor Samba, la funcionalidad de auditoría puede implementarse utilizando el módulo VFS. El acceso a ficheros y directorios queda entonces registrado por el servidor Samba. A nivel del sistema de ficheros, la auditoría al estilo de Windows no ha sido integrada aún en el núcleo de Linux, a pesar de que se han dado varias implementaciones de aproximación y que se cumplen las condiciones previas en las estructuras existentes para atributos extendidos en el sistema de ficheros Linux. En la práctica, no obstante, esta funcionalidad parece tener tan poca importancia que todos los intentos hechos hasta ahora se abandonaron por falta de interés.

Resumen de las consecuencias más importantes derivadas del uso de Samba con POSIX ACLs

Lo siguiente es de aplicación a la escritura como privilegio abstracto:

- No existe restricción entre “write data” y “append data”

En el caso de las carpetas, no hay diferencia entre crear carpetas o ficheros.

No hay diferencia entre la escritura de carpetas y/o ficheros y atributos

Lo siguiente se aplica en la lectura, como un privilegio abstracto:

No hay diferencia entre la lectura de carpetas y/o ficheros y atributos

La lectura de los privilegios está, en principio, siempre permitida. Ni “la auditoría” ni la “herencia” están, en general, implementadas.

Grupos de usuarios y privilegios de acceso

La asignación de privilegios de acceso a grupos juega un papel de suma importancia, especialmente en conjunción con las versiones, usados comúnmente por los grupos de trabajo.NT discrimina entre grupos locales y globales (del servidor). Los grupos locales se pueden considerar como definiciones de alias que se refieren a uno o más grupos globales. Esto significa que los grupos locales pueden contener varios grupos globales. El anidamiento de grupos no es posible con Samba (ni con UNIX/Linux en general). Samba solo permite a todos los grupos UNIX “estar presentes 1:1” como grupos globales para los clientes Windows y esos grupos globales pueden, por supuesto, formar parte de grupos locales en servidores Windows.

Esto significa que los modelos U-G-L-R y U-G-R, descritos en la sección 3.2.2.4, continúan estando disponibles en esos servidores.

La introducción del concepto de grupos locales también para servidores Linux, no está actualmente prevista, por lo que sólo el modelo U-G-R se utilñiza aquí normalmente. Se puede implementar una funcionalidad equivalente en un sistema de gestión de grupos basado en LDAP, con la correspondiente lógica de negocio.

Valoración de la repercusión para los usuarios

Cuando los ACLs de Windows se “mapean” en los ACLs de POSIX, la fina granularidad con la que los privilegios se pueden modificar bajo Windows, se pierde. En la práctica, no obstante, sólo los privilegios de grupo considerablemente más simples de las configuraciones simples de seguridad se usan en la mayoría de los casos.

Los privilegios de mayor calidad sólo se usan en casos aislados. La diferencia entre los atributos y privilegios de ficheros, en particular, se usan en muy raras ocasiones.

El privilegio de añadir datos, además, será sólo de uso en muy pocos casos. Si un sistema de ficheros Extended 2/3 se usa bajo Linux, este privilegio se puede también establecer para los ficheros seleccionados como un atributo extendido en la línea de comandos.

El mapeo coherente del modelo de los privilegios más simples desde los ACLs POSIX incrementa en media la fiabilidad del entorno de las configuraciones simples de seguridad.

El mapeo de ciertas funciones, como la herencia y la auditoría no es posible.

3.2.4. Migración por continuidad

3.2.4.1. Windows 2000

Esta sección trata Windows 2000 como el sucesor de Windows NT 4 bajo el aspecto de “servicio de ficheros“.

Funcionalidad ampliada

Windows 2000 viene con un número de nuevas características con respecto a los servicios de ficheros. Las siguientes palabras clave deben ser consideradas aquí:

Sistema de ficheros NTFS5

API-HSM

Herencia

Cifrado (EFS)

SMB sobre IP Nativo

Administración dinámica de volumen de datos

Defragmentación

Anidamiento de grupos

Almacenamiento remoto

Servicio de indexación

Rastreo distribuido de enlace

DFS

Carpeta Offline

Redireccionamiento de carpeta

Estos temas se discuten con más detalle a continuación.

NTFS5 file system

El NTFS5 ofrece generalmente las siguientes mejoras:

Por primera vez se puede administrar privilegios de acceso por herencia. Esto significa que los privilegios que se fijan sobre carpetas de más alto nivel son efectivos en carpetas de más bajo nivel y ficheros sin necesidad de escritura inmediata (burn-in). Por tanto se eliminan las desventajas de la escritura inmediata (problema de carga de trabajo, borrado de privilegios especiales en sub-carpetas).

NTFS5 viene con un diario de codificaciones en el que se registran los cambios.

Los volúmenes de datos formateados en NTFS5 incluyen una carpeta oculta llamada “Información del Volumen del Sistema“ que puede ser accedida solamente por el sistema operativo y en la que se administran las funciones adicionales.

NTFS5 ofrece el supuesto API HSM (Interfaz de programación para administración de almacenamiento jerárquico), que puede ser utilizadopor terceros fabricantes.

NTFS5 soporta la encriptación de datos. El sistema de archivos encriptado(EFS) habilita a los usuarios a proteger sus datos de la lectura de terceras personas(incluidos administradores).Se necesita una PKI (Public Key Infrastructure) para este propósito en redes de empresa.

Aunque la integración de cuotas en el sistema de archivos es posible, continua sujeta a las restricciones de NT4.

Protocolos

Windows 2000 también soporta los protocolos mencionados anteriormente. Con Windows 2000, es posible la primera vez desactivar la comunicación vía NetBIOS. Para los servicios de archivos, esto significa que el "Direct Hosting de SMB Over TCP/ IP" utilizará el puerto 445.

Gestión de particiones

Windows 2000 también ofrece la posibilidad de integrar discos duros físicos en el sistema sin asignar letras a las unidades. A estos volúmenes de datos dinámicos puede accederse y hacerse disponibles como carpetas en particiones tradicionales. Windows 2000 es la primera versión que incluye una herramienta para la defragmentación de estas particiones.

Cambios relativos al control de acceso

Pueden realizarse operaciones importantes de control de acceso bajo un directorio activo de Windows 2000 porque pueden asignarse más tipos de grupos y en una mayor cantidad de grados. Grupos de este tipo son únicamente posibles si un directorio activo es usado en"native mode". El nuevo "Dominio Local” y "tipos de grupos universales” están disponibles en "modo nativo". La siguiente tabla muestra las posibilidades de estos grupos.

Group type	Can have the following mem-bers	Can be a member of
Global group	Users and global groups of the same domain	Global groups of the same domain Universal and domain-local groups of each domain
Domain-local group	Users, universal and global group of each domain Domain-local groups of the same domain	Domain-local groups of the same domain
Universal groups	Users, global and universal groups of each domain	Domain-local or universal groups of each domain

A pesar de estos nuevos tipos de grupos, los de distribución y seguridad deben ser discriminados en entornos con un directorio activo y Exchange 2000. A pesar de que el entorno Exchange existe para los grupos de distribución, no permiten ningún control en relacióncon los servicios de ficheros.

Almacenamiento Remoto

El almacenamiento remoto es un nuevo servicio en Windows 2000, habilita el intercambio de ficheros que no se usan durante largo tiempo con unidades de cinta en relación a la funcionalidad HSM(Gestión jerárquica del almacenamiento).

Servicio de indexación

El servicio de indexación puede ser activado opcionalmente en directorios para indexar los ficheros almacenados ahí. El índice habilita una búsqueda rápida para contenidos definidos. Los servicios de indexación permiten indexar los siguientes tipos de documentos en distintos lenguajes:

HTML

Texto

Microsoft Office 95 o superior

Correo y noticias de Internet

Cualquier documento cuyo filtro esté disponible

Seguimiento distribuido de enlaces

El servidor de ficheros de Windows 2000 permite la programación de aplicaciones que puedan enlazar e incrustar objetos de tal manera que tanto la reubicación de los objetos enlazados, como la información sobre el lugar de almacenamiento puedan ser obtenidos del sistema de ficheros. Esto permite asegurar un uso libre de fallos.

Sistema de ficheros distribuido

El sistema de ficheros distribuido (DFS) estaba disponible para Windows NT 4 a través de instalaciones adicionales en el cliente y el servidor. En Windows 2000, estas funciones están integradas como funciones estándar tanto en el cliente como en el servidor. DFS permite que las versiones de las carpetas que son distribuidas a través de varios servidores, puedan ser mostradas al cliente como sub-carpetas de una misma versión. Esto permite un ahorro de letras de unidad, con respecto a las unidades de red asignadas al usuario. En Windows 2000, DFS fue modificado para integrar FRS (Servicio de replicación de ficheros) de modo que cada versión y sus contenidos son replicados en futuras versiones y otros servidores de ficheros. En caso de fallo en el servidor y por tanto en la versión, el cliente puede referenciar las replicas sin necesidad de establecer una nueva conexión. En Windows 2000 la información puede ser guardada y replicada usando el árbol DFS en el directorio activo. Esto significa que el cliente tiene acceso a la conexión de información requerida, casi todo el tiempo.

Conectando

El usuario puede ser ayudado en la búsqueda de versiones publicando las versiones en el directorio activo.

CARPETAS SIN CONEXIÓN Y RELOCALIZACIÓN DE CARPETAS

Son funciones principalmente de cliente (como Windows 2000 Profesional) en lugar de características del servidor de ficheros de Windows 2000. Son mencionados aquí, sin embargo, porque en principio, son relevantes respecto al almacenamiento de datos, porque deben cooperar con el servidor de ficheros. Las carpetas sin conexión, son los sucesores de “mi maletín” en las anteriores versiones de Windows. Los usuarios de agendas, por ejemplo, pueden trabajar sobre carpetas y ficheros que normalmente son almacenados en servidores de ficheros, sin estar conectados a la red. De esta forma, cuando la conexión con el servidor de ficheros es restaurada, los datos son replicados. Debido a este proceso de replicación , las propiedades de los ficheros en ambos lados (cliente y servidor) son muy importantes con el fin de permitir una replicación libre de errores.

Con la función de relocalización de carpetas, las direcciones de Windows 2000 son la causa de que el tamaño de los perfiles de usuario en las estaciones de trabajo pueda crecer tremendamente durante la operación. Esto puede ocurrir cuando el usuario graba datos sobre sus ficheros propios, que pueden ser almacenados mejor en el servidor de ficheros. Windows 2000 habilita el “twisting” o “intercambio” de las carpetas de sistema del perfil de usuario (ficheros propios, datos de aplicación) hacia una ruta de red. Estas carpetas pueden aparecer de manera transparente como carpetas locales. Debido a la relocalización de carpetas en el servidor de ficheros, las métricas deben retomarse para asegurar que sigan existiendo los privilegios de acceso.

Backup de datos

La herramienta incorporada NTBACKUP ha sido modificada de manera que el backup de datos es posible sobre discos(locales o remotos). Esto significa que las unidades de cinta locales son más fácilmente evitadas.

Sucesión de versiones

En la sucesión de productos, las siguientes evoluciones deben ser consideradas:

Windows 2000 Server es el sucesor de Windows NT 4 Server.

Windows 2000 Advanced Server es el sucesor de Windows NT 4 Server Enterprise Edition (ver “Servicios de clustering”).

Windows 2000 Data Center es el primer sistema operativo de Microsoft que esta disponible sólo en conjunto con un hardware especial y solamente de algunos fabricantes. Esta plataforma trata entornos muy especiales de disponibilidad y de carga. No se discute más adelante en esta guía.

Almacenamiento unificado de red (NAS)

Algunos fabricantes han desarrollado, en colaboración con Microsoft, lo que se ha llamado sistemas NAS basados en Windows 2000 Server. Estos sistemas son dedicados a servir ficheros y sus interfaces(entrada/salida) han sido optimizados.

Experiencia práctica

Las siguientes secciones contienen algunas observaciones sobre innovaciones técnicas tratadas previamente.

EFS está típicamente restringido a los ordenadores portátiles que requieren protección de datos contra violaciones de privacidad. El uso de EFS está restringido por la necesidad de PKI (incluso si Windows 2000 Active Directory ofrece esto) a menudo se ve como algo no muy útil debido a la carencia de soporte para el acceso a los mecanismos sobre una base de grupo (la necesidad de grupos específicos de almacenamiento de ficheros sobre servidores de ficheros).

Desactivar la comunicación de los interfaces NETBIOS no es obligatorio y es típicamente aplazado para mantener los requerimientos de compatibilidad hacia abajo.

El uso de ficheros de log y herramientas de configuración de acceso deben tomarse en consideración al concebir un nuevo sistema. Un NT 4 Explorer, por ejemplo, no implementa la función de herencia.

El uso de Windows 2000 debe ser verificado caso a caso con la idea del uso continuado de la herencia de hardware que es usada en NT 4. En la mayoría de los casos debe adquirirse nuevo hardware.

Windows 2003 Server

Esta sección admite que Windows 2003 sucede a Windows 2000 Server (Anteriormente NET Server) en el aspecto de servidor de ficheros.

A continuación serán descritas superficialmente las innovaciones más importantes.

Windows 2003 Server será el primer sistema operativo de Microsoft que estará disponible para arquitecturas de 64-bit.

El soporte oficial de SAN's (Storage Area Networks) se mejora de tal manera que es posible arrancar el sistema desde discos duros en una SAN.

El EFS habilita el acceso a múltiples usuarios a un fichero o recurso. Los grupos siguen siendo desatendidos.

El Volumen Sombra es una nueva funcionalidad: Esto incluye, por un lado, que la estructura de ficheros y carpetas puede ser consultada en un momento estático de tiempo, de manera que el backup de datos es posible sin la necesidad de considerar los ficheros abiertos. Otras nuevas opciones son que los usuarios pueden recuperar ficheros borrados por error de un “snapshot” sin tener que solicitar explícitamente su recuperación. La recuperación del sistema se facilita al administrador.

Sistemas de impresión

Descripción

El resultado de la discusión de los detalles técnicos está a continuación.

Bajo Linux, CUPS es el sistema de impresión predeterminado para la mayoría de distribuciones(SuSE, Debian, RedHat, etc) . CUPS es el sistema escogido tanto en sistemas Linux homogéneos como heterogéneos con clientes basados en Windows. Con clientes basados en Windows, la combinación de CUPS y Samba ofrece un sistema de escala total.

CUPS está diseñado con funcionalidades independientes de la plataforma debido a que implementa IPP (Internet Printing Protocol). De todas formas, CUPS también soporta todos los protocolos de impresión relevantes, como LPR/LPD, Socket/AppSocket, SMB/CIFS y MS-RPC (en conjunción con Samba). La combinación de CUPS y Samba también soporta la descarga automática de controladores a los clientes Windows.

Además, CUPS ofrece diferentes opciones para asegurar la integridad de los datos incluso durante la impresión. Estas opciones incluyen transmisiones cifradas mediante SSL en conjunción con el uso de IPP y autentificación de usuarios vía LDAP o en conjunción con Samba. Esto ofrece ventajas significativas, incluso considerando el acceso a la impresión mediante cuentas de usuarios.

Antes de comenzar un proyecto de migración siempre debe ser analizada la situación del soporte de los diferentes modelos de impresoras utilizadas. Esto es particularmente importante si el proceso de impresión se llevará a cabo completamente en los servidores de impresión, porque el soporte podría no estar asegurado en unos pocos casos aislados.

Incluso en el caso de migración por continuación en el lado de cliente, los clientes Windows 2000 pueden imprimir a través de los servidores CUPS ya que Windows 2000 soporta IPP.

Introducción

El problema de “la impresión” es normalmente subestimado en el mundo de las TI. Y esto es válido para todos los entornos, Windows o UNIX/Linux, por ejemplo. Los problemas de impresión son a menudo la causa de la mayoría de las pérdidas por “fricción”. Una parte sustancial del tiempo de los administradores se utiliza en resolver problemas de impresión rutinarios. Por otro lado, la impresión es, en muchas ocasiones, una parte crítica de la aplicación, donde un fallo puede producir grandes pérdidas económicas y quebraderos de cabeza diversos.

Es bastante común un cierto “caos organizativo” en lo que concierne a los servicios de impresión. “Estructuras crecidas” han llevado a todo tipo de inconsistencias: la mezcla confusa de lenguajes (PostScript, PCL, PreScribe, ESC/P, PDF...) se ha convertido en la regla casi siempre. La a menudo poco amigable coexistencia de protocolos de red y de impresión causa toda clase de problemas: LPR/ LPD, HP JetDirect, SMB/ MS-RPC, usw.

Aunque la migración de los servicios de impresión a una nueva plataforma no tiene porqué ser completamente necesaria, la opción debería ser considerada como una oportunidad para eliminar las deficiencias existentes.

Más allá de las consideraciones técnicas, el factor coste adquiere la misma importancia. Los verdaderos costes de la impresión a nivel de toda la organización (departamento, compañía, grupo, agencia) son normalmente desconocidos. Se pueden conseguir ahorros significativos en este área los cuales sólo son mesurables si se dispone de datos claros.

Los factores de coste más importantes son:

Número de impresoras

Consumo de papel

Consumo de Tóner/tinta

Consumo eléctrico

Las siguientes preguntas deberían ser respondidas antes de empezar la migración:

¿Cuántas impresoras hay en la organización/edificio?

¿Cuánto papel es consumido?

¿Cuánto Tóner/tinta es consumido? ¿Cuál es el coste de esos consumibles al año?

¿A cuánto ascienden los costes del servicio (mantenimiento, reparación)?

¿Cuánto cuesta el help-desk interno de la organización?

¿Cuánto se gasta en electricidad?

¿Cuál es el coste de imprimir una página?

¿Cómo se distribuyen estos costes entre los diferentes tipos de impresora?

¿Es posible un uso más eficiente de los recursos de impresión ya existentes?

Determinar el coste económico requiere un estudio dedicado en la mayoría de casos. Pero este esfuerzo frecuentemente vale la pena. Un análisis exacto de los factores de coste sale a cuenta de todas formas, ya que los potenciales ahorros conseguidos amortizarán dicho análisis en el periodo de un año.

La migración del entorno de impresión implica un cambio significativo, por lo tanto debería ser precedido por un análisis de requisitos, los resultados del cual deben tenerse en consideración cuando la transición sea planeada.

Situación de partida – impresión bajo Windows NT 4

Supondremos que la situación de partida, en el caso que nos ocupa, es aplicable a la mayoría de entornos que anteriormente utilizaran Windows.

Asímismo, asumiremos que el entorno ya existente se basa en uno de los modelos de dominio típicos de NT. Y, concretamente, que los servicios de impresión se basan en Windows NT 4 Server. Los servidores de impresión son miembros de un dominio NT.

La Edición Enterprise permite un servicio de impresión implementado en dos nodos (servidores) en cluster. El fallo de un servidor (nodo) se ve compensado por el nodo restante, el cual asume las responsabilidades del servidor caído. El cliente nota un retraso de segundos en el peor de los casos. De todas formas, la pérdida de los trabajos de impresión ya activos no puede resolverse. El usuario de dicho cluster requiere hardware especial (más en “Servicios de ficheros”).

Se consideran los siguiente ordenadores clientes (de impresión):

Windows NT 4 Workstation

Windows 9x

Se consideran los siguientes dispositivos de impresión:

Impresoras con tarjeta de red

Equipos con impresoras conectadas

La siguiente ilustración muestra una configuración del entorno de impresión típica:

Algunas estaciones de trabajo tienen una impresora conectada localmente al puerto LPT1 (impresora local).

Otras estaciones no tienen impresora conectada directamente pero utilizan las que se encuentran conectadas a la red.

La mayoría de impresoras láser pueden ser equipadas con tarjetas de red. Por el contrario, las impresoras de inyección de tinta suelen necesitar de un adaptador externo a parte para conectarse a un red independientemente.

Figura 6: Entorno de impresión 42

La ilustración muestra los dos tipos fundamentales de flujo de la información. En el primer caso, el cliente imprime a través de la red directamente sobre la impresora, mientras en el segundo, el cliente utiliza una “impresora permitida” de un servidor de impresión. Entonces dicho servidor envía los datos a la impresora.

Estos métodos y sus variantes son discutidos en el siguiente punto.

LPR/LPD bajo Windows NT 4.0

El sistema LPR LPD (Line Printer Redirector – Line Printer Daemon), proveniente del mundo UNIX, se introdujo en Windows con el lanzamiento de Windows NT y se utiliza en los servidores de impresión NT como el estándar de comunicación entre el servidor y el dispositivo de impresión. Este método también es generalmente adecuado para la comunicación entre cliente y servidor o entre cliente y dispositivo de impresión. La desventaja principal de LPR LPD radica en el hecho de que la información de retorno específica de cada modelo de impresora no es procesada.

42 Microsoft Windows NT 4 Resource Kit

Descripción técnica de las vías de migración

3.3.3.2 Otras variantes de red

Otros fabricantes de impresoras de renombre han implementado variantes adicionales bajo Windows NT, tales como:

Monitor de impresión LexMark Mark Vision (Lexmon.dll)

Monitor de puertos de impresoras en red Hewlett-Packard (Hpmon.dll).

A diferencia de LPR, estas variantes pueden usar también otros protocolos de transporte. Se puede usar, por ejemplo:

DLC

e IPX.

Las nuevas variantes de impresión en red permiten normalmente comunicaciones bidireccionales con las impresoras o con los servidores de impresión.

3.3.3.3 Impresión directa desde la estación de trabajo

La impresión directa (referirse a la Figura 6, flecha 1) tiene lugar a través de LPR/ LPD. Esto requiere que el servidor TCP/ IP sea instalado en la estación de trabajo bajo Windows NT 4. Los sistemas Windows 9x requieren un programa fabricado por terceros para este propósito. Se configura un puerto llamado LPR en el ordenador para ello. Deberá introducirse la dirección IP o el correspondiente nombre de máquina (DNS) de la impresora objetivo al efecto. Adicionalmente, deberá seleccionarse un modelo de impresora y el controlador de impresora apropiado. Entonces, el sistema operativo considerará tal impresora como si fuera "local". La comunicación directa entre el cliente y la impresora es bastante poco habitual en Windows NT ya que administrar localmente los terminales aumenta el esfuerzo administrativo de forma considerable.

3.3.3.4 Impresión a través de un servidor de impresión

Imprimir desde la estación de trabajo a través de un servidor de impresión requiere dos flujos de datos:

La transmisión de datos del ordenador al servidor (ver Figura 6, flecha 2a)

La transmisión de datos del servidor a la impresora (ver Figura 6, flecha 2b)

La transmisión de datos del servidor a la impresora se basa habitualmente en LPR/ LPD (ver "Impresión directa desde la estación de trabajo”).

La transmisión de datos entre el ordenador y el servidor de impresión puede efectuarse de diferentes maneras.

Deben cumplirse dos requisitos generales en el extremo del servidor con el fin de permitir que un cliente se dirija a una impresora en particular a través del servidor:

La impresora debe estar configurada en el servidor de impresión(puerto LPR, controlador de impresora).

La impresora debe estar habilitada.

Descripción técnica de las vías de migración

En una red Windows, habilitado significa, entre otras cosas, que la impresora puede ser encontrada al seleccionar con el ratón el servidor de impresión asociado.

La comunicación entre la estación de trabajo y el servidor (instancia de la impresora) es posible en tres formas distintas:

Puede usarse el comando NET USE a efectos de redirigir un puerto local LPT existente a la instancia de la impresora (por ejemplo: net use LPT3 \\servidor\nombre_instancia_impresora). Este método requiere que el usuario instale la impresora (controlador de impresora) en el puerto LPT, configurando por tanto la impresora como una impresora local. Esto es frecuente si se necesita imprimir desde aplicaciones DOS. La información a imprimir se envía sin formato (en bruto). Esto significa que el dispositivo de impresión puede usar directamente los datos recibidos.

Puede configurarse un nuevo puerto LPR que contiene el servidor de impresión y el nombre de la instancia de impresora como dirección de destino. Los datos son igualmente enviados en bruto.

El método llamado “Señalar e Imprimir” puede ser utilizado a efectos de configuración de una impresora de red en una estación de trabajo. La ventaja de este método es que, en condiciones ideales, la configuración manual o la instalación del controlador de la impresora no son necesarios. La información a imprimir se transmite en formato EMF (Enhanced Meta Format). Este formato no puede ser utilizado por el dispositivo de impresión y, por tanto, debe ser procesado por el servidor de impresión. La siguiente sección describe con detalle el método “Señalar e Imprimir”.

3.3.3.5 El método “Señalar e Imprimir”

Microsoft utiliza el protocolo RPC (Remote Procedure Call) para la comunicación entre el cliente y el servidor de impresión e implementa la tecnología llamada Señalar e Imprimir para dicho propósito. Esto permite, por un lado, la transferencia de los controladores de impresora desde el servidor al cliente y, por otro lado, la transferencia de la configuración específica del dispositivo (bandejas de papel, formatos de papel estándar) al cliente. Adicionalmente, este método desplaza parte del proceso de traducción al servidor, aliviando la carga del cliente durante el proceso de impresión. Esta ayuda es particularmente positiva si se usa un servidor de terminales.

Puesto que esta es una tecnología específica de Microsoft, el proceso se describe aquí de forma detallada. Se asume que tanto el cliente como el servidor utilizan Windows NT 4.

Cuando el usuario añade una impresora de red en este entorno de impresión, el primer paso es reconciliar los controladores. Un cliente Windows NT carga el controlador de la impresora desde el servidor si se cumplen simultáneamente las siguientes condiciones:

El servidor de impresión usa Windows NT.

El servidor de impresión tiene el controlador adecuado (plataforma: x86, Alpha, etc. y versión: 3.1, 3.5, 4).

El cliente NT no tiene controlador o bien tiene una versión anterior a la del servidor.

Descripción técnica de las vías de migración

Tras ser descargado, el controlador es instalado en el cliente. Ello implica la creación de entradas en la base de datos de configuración local del cliente.

El proceso de impresión:

La siguiente ilustración (Figura 7) muestra la secuencia del proceso que se describe brevemente a continuación.

Figura 7: El proceso seguido por el método "Señalar e Imprimir"

Paso 1: El usuario decide imprimir un documento desde una aplicación Windows. El usuario lanza el GDI (Graphics Device Interface). El GDI carga el controlador de impresora de la impresora seleccionada. En base a la información del documento procedente de la aplicación y la información del controlador de impresora, la tarea de impresión es traducida al formato EMF en primera instancia. La aplicación lanza el gestor de cola local (Winspool.drv).

Paso 2: Ya que el cliente utiliza Windows NT, el gestor de cola local (Winspool.drv) llama, vía RPC (Remote Procedure Call), el gestor de cola del servidor (Spoolss.exe) que a su vez llama a su servidor de enrutamiento (Spoolss.dll) directamente vía API. El servidor de enrutamiento consulta el

Descripción técnica de las vías de migración

proveedor remoto de impresión (Win32spl.dll) del cliente. El cliente activa el proceso Spoolss.exe en el servidor de impresión vía RPC el cual recibe la tarea de impresión y sus datos vía la red.

Paso 3: El servidor de enrutamiento del servidor recibe la tarea como un EMF (Enhanced Metafile) y lo pasa al proveedor de impresión local. Comparado con el formato en bruto, los datos a imprimir en formato EMF son relativamente independientes del dispositivo de impresión y usualmente limitados a un volumen inferior. Mientras que la primera parte del proceso de traducción tiene lugar en el cliente, la segunda parte se lleva a cabo en el servidor de impresión por parte del procesador de impresión del proveedor local de impresión, el cual escribe (encola) el resultado en el disco duro local.

Paso 4: La tarea encolada se pasa al monitor de impresión (extractor de cola) el cual a su vez llama al monitor de puerto. El monitor de puerto verifica si es posible, y si fuera el caso, de que manera se llevará a cabo la comunicación bidireccional con el dispositivo de impresión y envía la información necesaria.

Paso 5: El dispositivo de impresión recibe los datos, convierte cada página en un mapa de bits y lo imprime en el papel.

En el caso de que el cliente, en el paso 2, no sea un cliente Windows NT o bien sea un cliente Windows NT que utilice una conexión local redirigida (net use LPT), la tarea de impresión es traducida íntegramente en el cliente y enviada en bruto vía el redirector NetBIOS al servicio del servidor de impresión.

La tarea también es enviada en bruto vía TCP/IP al LPD del servidor de impresión si el cliente utiliza LPR.

3.3.3.6 Protocolos de red

La comunicación vía LPR/LPD se basa exclusivamente en TCP/IP.

En contraste con lo anterior, la comunicación entre la estación de trabajo y el servidor de impresión puede basarse en distintos protocolos de transporte:

TCP/IP

NetBEUI

SPX/IPX

La transmisión real de datos de impresión requiere

SMB

ó RPC

Descripción técnica de las vías de migración

3.3.3.7 Control de Acceso

Estos servidores de impresión Windows NT controlan el acceso a las impresoras de red (de liberación) las cuales son controladas por servidores de impresión. Los privilegios para esta operación de liberación están restringidos a los siguientes niveles:

Impresión

Administración de la impresora

Administración de los documentos

3.3.3.8 Herramientas

Las herramientas de administración de los servidores de impresión bajo Windows NT se limitan a la administración de la liberación de impresión y de los controladores de dispositivo. La gestión de los dispositivos de impresión no es posible.

Los fabricantes de impresoras proporcionan herramientas adicionales para la administración de las impresoras (MarkVision de LexMark, JetAdmin de HP, etc.).

De forma similar a las unidades de disco de red, es deseable la conexión automática a las impresoras cuando el usuario se conecte a la red. Esto puede conseguirse vía un script de VB o bien utilizando ciertas herramientas como con2prt.exe.

Podrían utilizarse programas de script (Perl) con el fin de garantizar los privilegios en la liberación de impresiones.

3.3.3.9 Características especiales en fase de producción

Las configuraciones de los dispositivos son únicamente dependientes del dispositivo individual de impresión. Incluso en el caso de modelos idénticos, estas configuraciones pueden diferir debido a un tipo distinto de serie o de características. Parámetros tales como el tamaño de la RAM, las bandejas de papel y el formato de éste deben también ser consideradas dentro de la configuración.

Las impresoras con varias bandejas de papel contienen usualmente diferentes tipos de papel. Con el fin de facilitar la selección correcta, la impresora suele publicarse bajo dos versiones diferentes. Cada instancia incluye una configuración diferente para la bandeja estándar.

Para poder asegurar un soporte óptimo a los usuarios itinerantes, es factible considerar que la conexión a las impresoras este basada en la ubicación del ordenador. Esto puede obtenerse a través de mecanismos adicionales en el script de entrada a la red con la condición de que exista una base de datos que pueda ser consultada y que contenga la asignación de estaciones de trabajo y de dispositivos de impresión.

Los fabricantes ofrecen controladores aparte para una gran variedad de modelos de impresora a pesar de que hay controladores incluidos en Windows NT. Aún cuando los controladores suministrados por Microsoft son probados por Microsoft, éstos fallan frecuentemente a la hora de manejar la funcionalidad (varias bandejas, unidades dobles) que los controladores de los fabricantes proporcionan, por lo que es recomendable usar los de los fabricantes. La implementación de los controladores por los fabricantes se realiza frecuentemente en la forma de ficheros dll adicionales lo cual resulta en un incremento de la complejidad del entorno de impresión. Ello implica realizar una gestión en la selección de los controladores.

Los conceptos de impresión existentes definen con frecuencia prioridades entre postscript y PCL.

En ciertos entornos se usan tamaños de papel y tipos de letra definidos por el usuario.

En un entorno NT, la configuración estándar permite a todos los usuarios acceder a cada nueva impresora instalada. Esto, sin embargo, no es siempre deseable. La asignación de privilegios específicos por usuario, con cada nueva impresora, es considerablemente más complejo en comparación con los servicios de ficheros.

3.3.4 Migración por reemplazo

En esta sección se parte de que la infraestructura de impresión tiene al menos un servidor de impresión, o bien se va a crear uno. Dicho servidor de impresión típicamente trabaja como servidor de colas de impresión central, y es además, capaz de ofrecer servicios adicionales.

Sólo se evaluará, como posible línea de migración, el "Common UNIX Printing System" (CUPS). Este sistema aparece en prácticamente todos los sistemas UNIX. Apple lo ha incorporado recientemente a sus sistema operativo Mac OS X. En Linux, CUPS es el standard de facto de la principales distribuciones (SuSE, Debian, Mandrake, RedHat, etc).

Si el entorno de impresión a migrar consiste en clientes Windows que acceden a un servidor de impresión NT, se analizarán las opciones de migración para el servidor.

Requisitos funcionales

Dado que la impresión se la considera a menudo una tarea “crítica”, la infraestructura técnica y la organización interna deben satisfacer los requisitos solicitados:

Fiabilidad

Es indispensable un mínimo grado de seguridad ante posibles fallos, debe ser fácil usar una alternativa en caso fallo (Los servicios de impresión debe estar disponibles, incluso si no hay un personal técnico especializado disponible)

Representación real

Los criterios de evaluación son, letras sin distorsiones, gráficos claros, reproducción fiel del color.

Calidad de impresión

Se espera una presentación con un mínimo de resolución.

Contabilidad

Debe ser posible controlar los costes por medio de registros detallados e informes.

Cuotas

Este requisito tiene como objetivo poder controlar/limitar los costes

Redirección de trabajos de impresión

Debe ser posible reenviar los trabajos a una impresora alternativa, sin necesidad de pedirle al cliente que vuelva a lanzar la impresión. (Importante: Si la impresora alternativa es de otro tipo, debe ser capaz de procesar el fichero de impresión en cuestión)

Reimpresión

En entornos donde hay un servicio de copias centralizado, a menudo necesitan volver a imprimir trabajos ya terminados. Esta función de reimpresión es necesaria a fin de

implementar la “impresión bajo demanda”, para sacar más copias posteriormente, o para compensar problemas técnicos (tales como atascos de papel o fallos en el suministro eléctrico) y errores de los operadores (tales como usar un papel de color equivocado).

Histórico de trabajos

Esta función permite tener una visión general de todos los procesos de impresión realizados. A final de año debe haber datos relativos a la cantidad total (para planificar el presupuesto), distribución por modelos y ubicación (para optimizar la distribución de recursos), así como los picos de carga (para realizar inversiones sensatas).

Integración con soluciones propietarias

A menudo es necesario integrar soluciones especiales propietarias, nuevas o “viejas”. Debe poder hacerse con un esfuerzo razonable.

Transparencia y control de costes

Indispensables. Tanto durante como después de la migración.

Seguridad

Debe garantizarse que no se interceptan datos confidenciales (Eavesdropping), ni siquiera interceptando ficheros de impresión.

Autenticación

Ciertas impresoras se reservan para ciertos grupos de usuarios, o ciertas configuraciones “caras” (1200 dpi en modo pantalla completa sobre papel fotográfico) deben estar disponibles sólo para ciertos usuarios (o incluso completamente desactivadas)

Impresión programada.

Debe poderse imprimir en otro momento o por la noche (trabajos por lotes, controlados automáticamente)

Supervisión sin un software especial

Un navegador puede ser ideal para supervisar las colas de impresión. Adicionalmente se podría acceder con la línea de comandos “desde cualquier parte”. Idealmente se daría autorización preferentemente a individuos particulares y no a todo el mundo.

Integración en entornos heterogéneos

El software de impresión debe ser multiprotocolo, ya que en la práctica no existe un estándar comúnmente aceptado. La capacidad multiprotocolo debe estar enfocada tanto de cara al cliente (que debería ser capaz de elegir cualquier protocolo para enviar los ficheros de impresión), como de cara a la impresora destino y/o un servidor de impresión de segundo nivel (que a menudo están anticuados y requieren el uso de ciertas convenciones). Y más aún, debe admitir el futuro estándar IPP.

Soporte de los estándares establecidos para la transmisión de datos

Las soluciones técnicas que se propongan deben satisfacer los requisitos funcionales antes mencionados. Uno de los objetivos particularmente importante, es conseguir un sistemas abierto consolidando los estándares, generalmente aceptados, ya existentes.

Los requisitos funcionales mencionados previamente deben ser cumplidos por las soluciones técnicas propuestas. Un objetivo particularmente importante es conseguir la apertura por medio de la consolidación de estándares abiertos existentes generalmente aceptados. El soporte a

protocolos estándar o propietarios (y dispositivos basados en esto) que sean necesarios durante un periodo de transición deberían estar asegurados incluso en el futuro. La funcionalidad de CUPS está diseñada como funcionalidad independiente de la plataforma, debido a la implementación de IPP (Internet Printing Protocol - Protocolo de Impresión por Internet, en adelante IPP). IPP se usa como protocolo entre servidores CUPS, clientes e impresoras avanzadas con soporte IPP directo como medio de comunicación y de transmisión de datos. Los módulos CUPS - los consabidos "backends" - se pueden usar para comunicarse con impresoras convencionales o servidores de impresión. Estos módulos habilitan las comunicaciones basadas en otros protocolos. La figura 8 ilustra el uso de los protocolos en las diversas interfaces. A continuación se describe la funcionalidad.

LPR / LPD

El protocolo tradicional para transmisión de datos de información [de cliente a servidor de impresión, de servidor a servidor y del servidor a la impresora (de red) destino, así como del cliente directamente a la impresora] tiene muchos inconvenientes: no es encriptado, no restringe autorizaciones, no es muy fiable, no es bidireccional (no hay respuesta desde la impresora, por ejemplo), no es un estándar "real" (de ahí las diferentes implementaciones que causan problemas debido a incompatibilidades ocasionales).

IPP

El Protocolo de Impresión por Internet es el estándar de Internet para impresión en redes de área local (LAN) y en grandes redes (WAN, Internet). El protocolo cubre todos los modos de comunicación concebibles, esto es, de cliente a servidor, de servidor a servidor, de servidor a impresora destino y de cliente directo a impresora destino. La última y única especificación de enlace es IPP-1.1. IPP fue diseñado por un grupo de trabajo (PWG) con miembros representativos de los fabricantes de impresoras, sistemas operativos y software de Europa, EE.UU. y Japón, y fue estandarizado por la IETF. El IPP ya está instalado en todas las impresoras de red modernas. Sin embargo, dado que hay modelos LPR / LPD todavía en uso (y que lo seguirán estando en los años venideros), se limitará el cambio a aquellos casos en los que tenga sentido de una manera inmediata.

Nota: Las nuevas versiones del sistema operativo Microsoft Windows incluyen cierto soporte de IPP en el cliente (Windows 98SE, Windows ME, Windows 2000, Windows XP) o pueden ser modernizados sin coste (Windows NT, Windows 95, Windows 98). Esto significa que estos sistemas pueden, "de manera natural", imprimir vía servidor CUPS. A día de hoy, sin embargo, Microsoft sólo ofrece una implementación de IPP versión 1.0 que la IETF nunca "recomendó como estándar", sino que sólo representó un paso intermedio en la discusión, fracasando, por ejemplo, en la definición de la importante cuestión de la encriptación de datos de impresión y la autentificación de usuarios. Un servidor CUPS debe por ello omitir la autentificación si va a ser utilizado directamente desde un cliente Windows. Si se usa CUPS conjuntamente con Samba y si es necesaria la autentificación del cliente Windows, se puede realizar esto último mediante los mecanismos implementados en Samba. Hay clientes CUPS comerciales para Windows disponibles en el mercado, en caso de que las exigencias de seguridad deban ser cubiertas para ciertos entornos.

Descripción técnica de las vías de migración

Página 74 Versión: 28.09.2003

Socket/ AppSocket

AppSocket (a menudo más conocido como "HP JetDirect") es un protocolo de transmisiones de alto rendimiento para archivos de impresión. Es más potente y fiable que el LPR/ LPD: incluye cierta comunicación bidireccional y es más rápido. Para JetDirect hay disponibles herramientas de administración tanto gratuitas como comerciales con las que estructurar grandes redes (como HP WebJet Admin). No obstante, no ofrece ni cifrado de datos de impresión ni autentificación de usuario. En su uso práctico, la información de estado sólo se puede enviar del servidor a la impresora o, en el caso de rutas directas, del cliente a la impresora.

SMB/ CIFS

Los clientes Windows usan este protocolo para enviar trabajos a servidores de impresión (o

a otros ordenadores Windows siempre que estos ofrezcan impresoras "compartidas"). La ruta desde el ordenador con Windows más cercano hasta la impresora de destino (a través de la red) debe por lo tanto transportarse mediante otro protocolo (a menos que dicha impresora de destino esté conectada localmente a una interfaz en paralelo, USB, FireWire o de puerto serie).

MS-RPC

Los clientes Windows bajo NT4 y posteriores pueden utilizar este protocolo para enviar trabajos a un servidor de impresión Windows (NT4 y posterior). Igualmente, se pueden utilizar métodos RPC de instalación automatizada de controladores en los clientes siempre que el servidor disponga de los archivos necesarios (la "carga" de los controladores desde un ordenador cliente al servidor de impresión por parte de un administrador si también se basa en el protocolo RPC). Dado que Samba incorpora SMB/CIFS, también CUPS puede utilizar este protocolo.

Descripción técnica de las vías de migración

Versión: 29.08.2003 Página 75

Funciones multiprotocolo con CUPS (conceptos generales)

Figura 8: Impresión bajo CUPS44

3.3.4.3 Integración en entornos Windows

Nota acerca de la integración de CUPS y Samba

CUPS se integra de forma óptima en Samba: mucho mejor que cualquier otro subsistema de impresión UNIX disponible. Se trata del único sistema de impresión que incorpora sus funciones en una librería (de software). Esto significa que otros programas pueden emplear sus funciones estableciendo enlaces a esta librería; un ejemplo es Samba, que hace uso de esta función. Por defecto, Samba está enlazado a libcups, de este modo un servidor de impresión Samba puede redireccionar sus trabajos a otros servidores de impresión CUPS mediante IPP. Estos servidores de impresión CUPS pueden instalarse en otro sistema servidor dedicado al servicio de impresión o en el mismo servidor que Samba. El IPP se utiliza en este caso de forma que sea totalmente transparente al administrador o usuario y que no necesite de más configuración.

44 A disposición del público en http://www.linuxprinting.org/kpfeifle/Linux-Kongress2002/Tutorial/

Descripción técnica de las vías de migración

Página 76 Versión: 28.09.2003

Tabla 10: Enlazado de clientes a CUPS

Descarga e instalación de controladores por parte de clientes estilo "Seleccionar e imprimir"

La combinación de CUPS y Samba admite la descarga automática de controladores en clientes Windows para dotar a sus usuarios de funciones de "Seleccionar e imprimir". Para ello, ha de configurarse Samba de forma que simule un servidor de impresión NT. La configuración se describe pormenorizadamente en la serie de documentos CÓMO (HowTo's) de Samba. No obstante, sólo hay que llevar a cabo algunos pasos. También los administradores pueden cargar los controladores desde una máquina cliente.

En este caso los controladores de impresión quedan ubicados en el servidor Samba, se instalan en segundo plano de forma automática en el sistema cliente Windows cuando el usuario busque o identifique por primera vez la impresora en el entorno de red y la seleccione (haciendo clic con el botón derecho del ratón) en el menú contextual "Conectar...".

Descripción técnica de las vías de migración

Versión: 29.08.2003 Página 77

Instalación automática de controladores mediante scripts de acceso

El uso de "scripts de acceso" facilita aún más la vida a los usuarios y administradores de un dominio. Sólo hay que incluir la siguiente línea en el script de acceso:

„rundll32 printui.dll,PrintUIEntry /in /n„\\NOMBREDESERVIDORSAMBA\nombre_de_impresora“. La impresora correspondiente al usuario que se registre en el sistema se instala automáticamente (otras opciones relacionadas son la instalación de diversas impresoras, la definición de una impresora por defecto, la eliminación de colas de impresión obsoletas, etc.). Esta opción permite administrar de forma cómoda para el usuario los controladores de impresora y ahorra trabajo al administrador.

Aquellos entornos con prestaciones diferentes pueden ser asignados a diversos grupos de usuarios mediante sus scripts de acceso correspondientes.

Seguridad y autentificación

CUPS también permite establecer comunicaciones cifradas entre sistemas cliente y servidor.

Se puede utilizar SSL 3 o TLS para la transmisión de datos en caso de que se esté empleando IPP.

Los clientes Windows suelen autentificarse mediante Samba con mayor frecuencia que mediante CUPS. Esta autentificación se utiliza automáticamente en caso de que se imprima mediante Samba, ya que éste se encarga de administrar los permisos. En este caso sólo es necesario asegurarse de que el servidor Samba tiene autorización para emplear el servidor de impresión CUPS.

Publicación de impresoras CUPS en LDAP y active directory

Samba puede publicar sus servicios en directorios LDAP y active directory. Esto

por supuesto, también se aplica a impresoras y servidores de impresión CUPS. También es posible profundizar en la integración en entornos AD (o en entornos LDAP, que por lo general simulan entornos AD). Por otra parte, ya se encuentra en una avanzada fase de pruebas beta una próxima versión de CUPS capaz de enlazar servidores LDAP "por sí misma".

Interfaz web multiplataforma

CUPS viene de serie con una interfaz web "instalada" a la que se puede acceder mediante la siguiente dirección: "http://SERVIDOR_CUPS_DE_IMPRESIÓN:631/". La interfaz ofrece a todos los usuarios información y acceso a las funciones del servidor de impresión. El usuario puede controlar por defecto el estado de los trabajos de impresión, cancelarlos, reanudarlos, imprimir antiguos trabajos, etc. (dependiendo de la configuración concreta).

El administrador o el personal del servicio de asistencia puede crear nuevas impresoras (colas), borrar, modificar la configuración, iniciar, detener, cerrar o abrir impresoras (colas), así como cancelar, pausar o reanudar cualquier trabajo de impresión a través de la interfaz web. Las opciones para utilizar esta interfaz pueden restringirse y/o ampliarse configurando el servidor CUPS como sea conveniente.

La interfaz web está sujeta a las mismas comprobaciones de acceso que el resto de recursos de CUPS. Cada prestación del servidor de impresión (acceso a trabajos propios o impresoras concretas, acceso a todas las impresoras o todos los trabajos, etc.) puede ofrecerse con permisos de acceso diferenciados: "El usuario López tiene permiso de administración" a condición de que acceda desde el ordenador A o B", "Todos los usuarios pueden borrar sus propios trabajos de impresión, no así los del resto de usuarios", etc.).

Descripción técnica de las vías de migración

Página 78 Versión: 28.09.2003

3.3.4.4 Adaptabilidad

El sistema de impresión puede modificarse fácilmente de muchas formas, por ejemplo añadiendo filtros y backends, con lo que se amplía la capacidad propia de CUPS.

Filtros

CUPS emplea de forma interna un sistema modular de filtros basado en interfaces abiertas que se puede modificar en cualquier momento. En este contexto se puede utilizar cualquier lenguaje de scripts (Shell, Perl o Python) o de programación (C, C++, Java, etc.). Los scripts envolventes permiten enlazar programas propietarios en formato binario de la forma más sencilla.

BackEnds

El "acoplamiento" de nuevos backends es muy simple. Tanto para adaptaciones propias de un entorno concreto a unos requisitos específicos (como la réplica automática de ciertos trabajos de impresión procedentes de un departamento distante, por ejemplo, para archivar la correspondencia comercial), como para adaptarse a las innovaciones tecnológicas (redes de área local inalámbricas, Bluetooth, FireWire...), esta es una opción muy atractiva.

3.3.4.5 Lenguajes de descripción de página

CUPS utiliza lo que se conoce como descripciones de impresoras PostScript o PPD (PostScript Printer Descriptions) para controlar impresoras. La especificación PPD fue definida originalmente por Adobe y forma parte de las prestaciones de prácticamente cualquier sistema de impresión que controle impresoras PostScript y emplee opciones especificas del dispositivo en cuestión (impresión dúplex, selección de bandejas, asignación de prioridad, enlazado, etc.). Dichos archivos

PPD están a nuestra disposición como CUPS, incluso para aquellas impresoras que no cuentan con intérprete PostScript propio. CUPS utiliza estas descripciones de impresora bien definidas para permitir la realización de los ajustes de configuración necesarios a través de la interfaz web o de las máscaras de configuración de los clientes.

En el caso de impresoras sin capacidad para el uso de PostScript, el servidor CUPS emplea lo que se conoce como "filtros" para convertir los datos proporcionados por el cliente. Bajo Linux, el programa ghostscript ya incluye paquetes de filtros muy completos con los que se puede convertir el PostScript a diversos lenguajes de descripción específicos de numerosos fabricantes y dispositivos. CUPS incluye una versión adaptada de ghostscript.

3.3.4.6 Implementación técnica de las funciones de controlador

Existen dos modelos diferentes para convertir archivos de impresión a mapas de bits compatibles con la impresora. Estos modelos son:

Las funciones de controlador se ejecutan por completo en el cliente.

Esto significa que el cliente prepara el archivo de forma que quede listo para la impresión. El servidor de impresión sólo cumple funciones de gestión de colas de archivos de impresión "en bruto".

Pueden ofrecerse los controladores al cliente para su descarga e instalación automática.

Los datos son procesados en el servidor de impresión.

En este caso, los clientes envían los datos en formato PostScript al servidor de impresión. Los clientes requieren el controlador PostScript correspondiente, que el servidor puede ofrecerles para su instalación automática. El servidor envía los datos

Descripción técnica de las vías de migración

Versión: 29.08.2003 Página 79

procesados a la impresora seleccionada. El procesamiento de impresión para impresoras que no aceptan formato PostScript lo lleva a cabo un software especial (consulte también la sección 3.3.4.5).

El segundo modelo ofrece diversas ventajas frente al primero:

Admite automáticamente todos los dispositivos PostScript con la totalidad de sus opciones de impresión (como bajo Windows NT).

Además, también es compatible con la gran mayoría de las impresoras sin intérprete PostScript habituales (dependiendo de la compatibilidad con ghostscript u otros paquetes de controlador).

Recuento automático

Duración de la impresión, número de copias, impresora empleada, nombre de usuario, identificador de la impresión y dirección IP del envío de cada página impresa quedan registrados. Esta información queda a disposición para su posterior valoración (control de gastos, estadísticas...).

Opción de cuotas

Se pueden as cuotas de impresión de cada dispositivo (en función del número de páginas y/o volumen de datos impreso)

se pueden asignar a los usuarios.

Función de impresión a posteriori

Los trabajos pueden guardarse durante un periodo de tiempo determinado, por lo que están a disposición de los usuarios por si fuera necesario volver a imprimir alguno de ellos (sin que el cliente tenga que buscar, abrir y enviar el archivo de nuevo).

Función de redirección

Los archivos de impresión pueden redireccionarse a otra impresora de destino (incluso en caso de que la impresora original fuera un modelo PostScript y la nueva no disponga de esta prestación).

Las opciones de impresión pueden adaptarse al modelo concreto del nuevo dispositivo.

Centralización de controladores

Todos los clientes utilizan básicamente el mismo controlador PostScript (que sólo se modifica con un archivo ASCII, el "PPD").

No obstante, este modelo también está sujeto a las siguientes restricciones:

Mayor exigencia de recursos

El procesamiento centralizado de datos de impresión en el servidor exige más RAM, CPU y

capacidad de disco duro (estos parámetros pueden determinarse de forma fiable por adelantado si se conocen previamente las futuras exigencias de impresión).

Restricciones menores relacionadas con los modelos de impresoras compatibles

Si bien la mayoría de los modelos de impresoras habituales son compatibles, a veces es posible que se produzca el caso contrario. La base de datos "Linuxprinting.org" contiene una lista de fabricantes y modelos compatibles.

3.3.4.7 Arquitecturas de sistemas de impresión

La lista siguiente esboza las opciones potenciales de la arquitectura en relación al uso de CUPS, haciendo especial hincapié en la seguridad, un requisito fundamental en muchas situaciones de aplicación.

Descripción técnica de las vías de migración

Página 80 Versión: 28.09.2003

Servidor:

Todo ordenador equipado con CUPS que se comunique directamente con una impresora puede ofrecer el servicio de impresión a otros sistemas y, por lo tanto, desempeñar el papel de servidor CUPS. Esto requiere los PPD y filtros correspondientes al procesamiento de archivos compatible

con cada impresora.

Cliente:

Todo ordenador que envíe archivos de impresión se convierte en cliente CUPS. El cliente no requiere ningún filtro ni PPD local. No obstante, si las opciones de impresión empleadas durante la impresión son definidas en el cliente, el servidor envía automáticamente los PPD al cliente.

Administración innecesaria en clientes CUPS nativos:

Los servidores CUPS envían a los clientes la información concerniente a las impresoras instaladas en la red. Los clientes saben así qué impresoras de la red pueden utilizar. Esta información se publica mediante emisión UPD. Un enfoque alternativo consiste en dejar que el cliente consulte a los servidores para obtener la información que necesita. La solicitud de dispositivos disponibles también se puede poner en práctica con servidores separados por routers. Los servidores ubicados en diferentes redes pueden configurarse como BrowseRelay, pueden conseguir los datos relativos a las impresoras disponibles y enviar esta información a los clientes de su propio dominio.

Agrupación para aumentar la seguridad y la asunción de servicios en caso de fallos:

Se pueden configurar dos o más servidores CUPS de forma que ofrezcan servicios de impresión a prueba de fallos. Esto se puede lograr configurándolos con las mismas impresoras y nombres de impresora. Las clases implícitas son generadas automáticamente en los servidores CUPS. Estas clases constan de impresoras con nombres idénticos. El servidor principal atiende al trabajo de impresión del cliente y lo envía a la impresora. Esta configuración también puede implantarse constituyendo las clases a mano. Estas clases pueden incluir impresoras con diversos nombres.

3.3.5 Migración por continuación (o de continuidad)

3.3.5.1 Windows 2000

Esta sección trata sobre Windows 2000, el sucesor de Windows NT4 en lo relativo al "servicio de impresión“.

Funciones ampliadas

Windows 2000 introduce algunas prestaciones nuevas relacionadas con los servicios de impresión. Hemos de mencionar las siguientes palabras clave.

Monitor de puertos TCP/ IP estándar

Impresión a través de Internet

Publicación en active directory.

Las siguientes secciones tratan estos temas en profundidad.

Descripción técnica de las vías de migración

Versión: 29.08.2003 Página 81

Comunicación servidor-impresora

Con Windows 2000, Microsoft introdujo SPM (Monitor de puertos estándar o Standard TCP/ IP Port Monitor).

SPM es compatible con SNMP. El tipo de puerto LPR coexiste junto a SPM. A diferencia de LPR, SPM permite recuperar información de estado detallada.

SPM es capaz de utilizar dos protocolos de servidor de impresión: RAW o LPR. RAW es el protocolo estándar de la mayoría de impresoras.

Publicación en directorios activos

La tecnología de directorio activo permite publicar el modelo de una impresora (en servidores Windows NT o 2000), de forma que el usuario ya no tiene que saber en qué servidor se haya ubicada el dispositivo de impresión; basta con examinar el directorio activo.

Impresión a través de Internet

Windows 2000 cuenta con la opción de publicar impresoras en la web y de permitir su instalación.

Entornos híbridos

Guardar controladores para clientes Windows 2000 y XP en servidores Windows NT

no es posible. En entornos de este tipo, los controladores han de instalarse por separado.

Los controladores para clientes Windows NT se pueden guardar en servidores Windows 2000. No obstante, es posible que la transferencia de los ajustes de un dispositivo específico falle si se utilizan controladores exclusivos de un fabricante concreto (si esto fuera necesario). Esto es así por el cambio de controladores de impresora del modo kernel de NT al modo usuario de Windows

2000.

3.3.5.2 Servidor Windows 2003

En cuanto a la versión Windows 2003, en el momento de redactar esta guía no se conocen nuevas prestaciones con respecto a Windows 2000.

3.4 Servicios de autenticación

3.4.1 Conceptos generales

El análisis detallado desarrollado en las siguientes secciones permite concluir que se puede mantener un sistema de autentificación segura tanto de usuario como de ordenadores, tanto durante una migración de continuidad como en una migración de reemplazo y, por último, incluso en entornos heterogéneos, todo gracias a las herramientas y medios disponibles actualmente. En estos aspectos es donde Samba y OpenLDAP desempeñan un papel fundamental.

En un entorno heterogéneo de sistemas, la alternativa al servidor Windows NT que constituye Samba ofrece funciones similares tanto para clientes Windows como para controladores principales de dominio basados en NT. Samba, en su faceta de base de datos para cuentas de usuario puede utilizar OpenLDAP como servicio de directorio. Samba, junto a OpenLDAP, puede implantar un dominio Windows NT para clientes Windows. En cuanto a la administración de usuarios, grupos e información de máquinas, se puede implantar una solución basada en directorios con todas las ventajas que ello conlleva. Con una solución semejante se evita, por ejemplo,

Descripción técnica de las vías de migración

Página 82 Versión: 28.09.2003

el habitual problema de escalado en Windows NT, que suele exigir la división de una infraestructura en varios dominios.

Samba permite establecer relaciones de confianza entre diversos dominios, así como la implantación de un servicio WINS. Si bien Samba 3.0 también ofrece un programa que emula WINS, lo cierto es que en estos momentos aún no se considera que haya sido puesto a prueba con garantías. Samba admite el concepto de PDC y BDC por razones de compatibilidad. Esta compatibilidad, aún así, está limitada al hecho de que los servidores Samba se presentan ante los clientes Windows como PDC o BDC, dependiendo de la configuración efectuada. Samba por sí mismo no permite emular la base de datos SAM entre PDC y BDC. La emulación de SAM puede, en cualquier caso, dejarse a cargo de OpenLDAP.

En caso de una migración de continuidad, deben tenerse en cuenta algunas restricciones de poca importancia en relación a la autentificación en entornos de sistemas heterogéneos. Estas restricciones atañen a la interacción entre Samba/OpenLDAP y el directorio activo, así como entre Samba/OpenLDAP y la autentificación Kerberos.

Tenga en cuenta que en este contexto no se puede utilizar la autentificación Kerberos de clientes Windows 2000/XP mediante Samba/OpenLDAP. En casos de esta naturaleza ha de utilizarse el protocolo NTLM. Esto no supone ningún problema, siempre que Microsoft siga permitiendo este modelo, por ejemplo para conseguir la integración constante de los clientes Windows NT. Por otra parte, se puede utilizar un servidor Kerberos instalado en Linux con un dominio de directorio activo, de forma que se pueda implantar un sistema de credenciales uniforme para clientes Windows y Linux basado en este último sistema.

En un entorno de sistemas totalmente basado en Linux, la autentificación de usuarios se puede confiar a Kerberos, o bien a la alternativa OpenLDAP.

3.4.2 Situación de partida: Windows NT 4

Esta subsección trata sobre los servicios de autentificación y/o acceso al sistema de los productos de Microsoft. Entre los aspectos examinados se cuentan los siguientes:

Bases de datos de usuarios

Integración de ordenadores y servicios de red

Autenticafición

Con este fin, comenzaremos exponiendo los fundamentos técnicos de un entorno Windows NT sin perder de vista los servicios de acceso a sistemas.

3.4.2.1 Dominio

La unidad estructural "dominio" es la tecnología clave de los servicios de acceso a sistemas bajo

Windows NT. El dominio es una unidad de administración que combina las cuentas de ordenador y usuario mediante una base de datos compartida en un contexto de seguridad común. Esta base de datos se llama SAM (gestor de cuentas de seguridad o Security Accounts Manager). Durante la ejecución, ésta se alamacena en el registro de unos servidores especiales llamados controladores de dominio. Además de usuarios y ordenadores, los grupos son también parte de las tareas de administración de SAM. Cada uno de estos tipos de objetos puede identificarse unívocamente mediante lo que se conoce como SID (identificador de seguridad o security

Descripción técnica de las vías de migración

Versión: 29.08.2003 Página 83

identifier), que no se presenta más de una vez en cada red, ni siquiera en diferentes dominios.

Cada SID cuenta con un nombre de cuenta en SAM que normalmente consiste en un máximo de 15 caracteres alfanuméricos (se permiten algunos caracteres especiales, con lo que se consiguen identificadores de una longitud relativamente grande). El nombre de cuenta en SAM será utilizado por los usuarios a la hora de identificarse. Los ordenadores basados en

Windows NT

Windows 2000

Windows XP

pueden ser miembros de un dominio. Por el contrario, no se puede crear una cuenta de ordenador en un dominio con sistemas como Windows 3.11 ó 9x, por ejemplo.

Cuando un ordenador pasa a formar parte de un dominio, los grupos del dominio (grupos globales) pasan a ser miembros de los grupos locales del ordenador en el SAM que corresponda.

De este modo, el grupo de "usuarios del dominio" se convierte en miembro del grupo local del "usuario". De este modo, los usuarios autorizados a acceder al sistema en un ordenador NT integrado en un dominio pueden acceder localmente a los recursos del ordenador utilizado.

Cada dominio exige, al menos, un controlador de dominio, el PDC (controlador primario de dominio o Primary Domain Controller). El PDC custodia el SAM del dominio, y los contenidos del SAM sólo se pueden modificar en él. Los BDC (controladores secundarios de dominio o Backup Domain Controllers) se utilizan para equilibrar la carga y por razones de seguridad. Los BDC guardan una copia del SAM que se actualiza regularmente cada vez que se modifica el PDC.

La ventaja de la unidad de administración "dominio" es obvia: lo único que se necesita para permitir que los usuarios accedan a los recursos locales o a los de la red es crear una cuenta de usuario en el SAM del dominio, en lugar de en cada sistema. La protección de los recursos, es decir la autorización, se administra por separado en cada uno de los sistemas que ponen sus recursos a disposición de la red. Los usuarios de Windows 9x también pueden acceder a los sistemas del dominio y utilizar los recursos de la red sin necesidad de autentificarse de nuevo.

3.4.2.2 Diversos dominios y relaciones de confianza

Mediante relaciones de confianza, se pueden conectar unos dominios a otros . De este modo, los usuarios o grupos de otros dominios pueden obtener una autorización para acceder a los recursos del propio dominio (por ejemplo, a los servicios de archivos). El objetivo prioritario es permitir así el acceso a recursos de diversos dominios.

Una relación de confianza entre dominios de NT no tiene porque ser bidireccional: aunque el dominio A goce de la confianza del dominio B, no es necesario que también A confíe en B. Y lo que es más, las relaciones de confianza tampoco son transferibles: del hecho de que A confíe en B y B confíe en el dominio C no se desprende que A confíe implícitamente en C. Esto significa que toda relación de confianza ha de crearse explícitamente.

Las siguientes circunstancias han llevado al establecimiento de diversos dominios en entornos informáticos:

Descripción técnica de las vías de migración

Página 84 Versión: 28.09.2003

En muchos casos, se dan soluciones paralelas pero aisladas que han sido desarrolladas en una infraestructura y posteriormente se fusionan mediante relaciones de confianza para compartir procesos de trabajo. Esto también se aplica a los casos en que dos infraestructuras diferentes se fusionan.

Los límites del dominio constituyen límites de seguridad. Los administradores de un dominio A no son necesariamente administradores de un dominio B, donde ambos confían en el otro. En este aspecto, las consideraciones políticas desempeñan un papel importante.

La opción menos aconsejable de delegar tareas se compensa creando varios dominios.

El número de objetos (ordenadores, usuarios, grupos...) del SAM se ve limitado porque durante su funcionamiento el SAM se guarda en el registro de los controladores de dominio, cuyo tamaño también esta limitado. El único remedio consiste en distribuir los objetos en diversos dominios.

El principio de maestro único del PDC restringe las posibilidades de ampliación de un dominio en entornos muy distribuidos y descentralizados porque todo cambio del SAM puede implantarse sólo en el PDC.

Estas circunstancias han llevado al desarrollo de diferentes modelos de dominio, algunos de los cuales fueron una propuesta de la propia Microsoft:

Dominios sencillos

Dominio maestro (los diversos dominios sencillos confían en un dominio maestro, un modelo en el que los dominios con recursos suelen confiar en el dominio de cuentas)

Varios dominios maestros (los diversos dominios de recursos confían en uno, o varios, dominios de cuentas

Dominio de confianza completa (todos los dominios confían en todos)

3.4.2.3 NT como servicio de directorios

En un sentido amplio, los dominios de Windows NT también son servicios de directorio porque los usuarios quedan contenidos en un dominio. Microsoft llama a este esquema NTDS (servicio de directorios Windows NT o Windows NT Directory Service).

El número de atributos de un usuario en un dominio NT es relativamente pequeño, y está más o menos limitado a atributos y propiedades relevantes desde el punto de vista técnico. Por lo tanto, los atributos no son comparables a los del servicio de directorio basado en X.500.

Las propiedades del usuario incluyen, por ejemplo:

Nombre de usuario (nombre de cuenta SAM)

Nombre completo y descripción (técnicamente irrelevante)

Información de cuenta (como desactivación de cuenta, contraseña sin caducidad, caducidad de la cuenta, tipo de cuenta...)

Pertenencia a grupos

Descripción técnica de las vías de migración

Versión: 29.08.2003 Página 85

Parámetros del entorno (script de acceso, directorio de inicio, ruta del perfil albergado en el servidor...)

Horarios válidos para acceder al sistema y ordenadores cliente donde el usuario puede iniciar sesión

RAS (servicio de acceso remoto o Remote Access Service) y parámetros de marcación: permitida, con/sin respuesta...

Además, se guardan los atributos que han de ser gestionados por el sistema operativo, como:

SID

LastLoginTime

etc.

No se preve la posibilidad de modificar esta lista con atributos definidos por el usuario.

Con la introducción de "Windows NT 4 Server Terminal Edition" y de Citrix Metaframe,

la propia Microsoft ha incorporado más propiedades para los usuarios (rutas de perfil y de directorio de inicio adicionales, así como más parámetros Citrix).

No se puede crear una estructura jerárquica del NTDS, ni asignar permisos al nivel de atributos. La flexibilidad de asignar permisos a los usuarios está fuertemente limitada.

3.4.2.4 Delegación

La posibilidad de delegar tareas administrativas en un dominio NT está limitada a:

el uso de grupos de serie (administradores de dominio, cuentas, servidores, copias de seguridad, impresión y operadores de reproducción); no obstante, esta variante sigue siendo muy inflexible

instalar dominios adicionales.

Estas restricciones y carencias son probablemente la razón por la que la delegación y otros comportamientos existentes se han implantado en forma de aplicaciones basadas en navegador.

3.4.2.5 Base de la red

Un dominio de Windows NT puede basarse en los siguientes protocolos de transporte:

TCP/ IP

NetBEUI

SPX/ IPX

La interfaz NetBIOS es necesaria en todos los casos.

En redes TCP/ IP, que en esta guía de migración son consideradas el estándar, la resolución de los nombres NetBIOS (nombres de ordenador y de usuario, más otros tipos de nombres como el grupo de trabajo) es obligatoria para conseguir una comunicación correcta. Un usuario que desee la palabra clave de su dominio, por ejemplo, ha de identificar el PDC y/o conocer su dirección IP.

Descripción técnica de las vías de migración

Página 86 Versión: 28.09.2003

La resolución de los nombres NetBIOS se puede conseguir de diferentes formas en una red Windows:

Mediante emisión (broadcast)

Solicitándosela a un servidor WINS (servicio Windows de nombres de Internet o Windows Internet Name Service)

O bien examinando el archivo LMHOSTS

La solución más elegante de este problema es probablemente utilizando servidores WINS.

Estos son la única manera que permite resolver nombres más allá de las fronteras constituidas por las subredes IP, los contenidos dinámicos y el uso contenido de emisiones. El servicio WINS suele implantarse en los controladores de dominio.

El servicio de navegación en redes Windows se implanta independientemente del protocolo de transporte elegido. En principio, todos los sistemas operativos Windows pueden albergar el servicio de navegación. Dicho servicio permite enviar una lista de todos los ordenadores activos de la red al cliente que la solicite (mediante la orden "nueva vista", por ejemplo). Si esta lista ha de tener validez más allá de la subred IP, el servicio de navegación ha de tener acceso a la información del servidor de dominios maestro o "domain master browser" de la red local. Esto es posible gracias al uso de WINS.

3.4.2.6 Réplica de archivos

Los controladores de dominio (PDC y BDC) proporcionan scripts y directrices de acceso al sistema en su publicación NETLOGON, que el usuario solicita cada vez que accede al sistema.

El contenido de esta publicación ha de ser idéntico en todos los controladores del dominio para garantizar que el usuario siempre trabaja en el mismo entorno. Para conseguirlo, los servidores han de intercambiar sus contenidos. El servicio de réplica de directorios LMRepl garantiza que el contenido del servidor que está exportando se copia en todos los servidores que están importando. Los intercambios de contenido se pueden efectuar únicamente en el servidor que exporta.

3.4.2.7 Herramientas de administración

Windows NT 4 viene equipado con herramientas gráficas, como el gestor de usuarios y el gestor de servidores, que sirven para administrar usuarios, grupos y máquinas. Además, el "NT Resource Kit" incluye herramientas que pueden ejecutarse en la línea de comandos y que se pueden utilizar para crear scripts de administración automática. Por otra parte, se puede administrar el dominio mediante interfaz web. Esto exige utilizar Internet Information Server (IIS) de Microsoft.

El carácter poco agradable para el usuario de las herramientas de serie animó a algunos desarrolladores a diseñar otros programas. Estas herramientas hacen uso principalmente de las APIs de Windows NT.

Descripción técnica de las vías de migración

Versión: 29.08.2003 Página 87

La propia Microsoft añadió la consola de gestión Microsoft Management Console (MMC), que en último término quedó integrada en Windows 2000. Otra prestación añadida por Microsoft fue la ADSI (interfaz de servicios de directorio activo o Active Directory Service Interface), una interfaz COM con la que también se pueden administrar dominios Windows NT.

3.4.2.8 Alojamiento de contraseñas

Las contraseñas de los usuarios (y sus ordenadores) se guardan en un dominio del SAM ubicado en los controladores de dominio. La contraseña se guarda en un valor hash en lugar de en texto plano. Además, Windows NT permite además cifrar el propio SAM (SYSKEY.EXE). Los valores hash de las contraseñas se generan siguiendo diversos métodos que se han seguido desarrollando:

LM (gestor de LAN)

NTLM

NTLMv2

En sistemas NT que no actúan como controladores de dominio, la información de acceso al sistema de los últimos usuarios registrados se alberga temporalmente para que se pueda iniciar una sesión aunque no se pueda contactar con un controlador de dominio (un problema típico de los portátiles). Esta información también se guarda como valor hash.

3.4.2.9 Mecanismo de autentificación

La autentificación en un entorno de dominio NT se basa en el mecanismo NTLM.

Pongamos por ejemplo la siguiente situación: un dominio de recursos confía en un dominio de cuentas y se emplea un entorno WINS. Un usuario enciende una estación de trabajo NT de Windows miembro de los dominios de recursos, y accede al dominio de cuentas. La imagen que aparece a continuación (figura 9) ilustra esta situación.

Descripción técnica de las vías de migración

Página 88 Versión: 28.09.2003

Figura 9: Situación de acceso al sistema

Cuando la máquina Windows NT arranca, solicita mediante WINS una lista de los controladores de dominio (DC) del dominio de recursos. En primer lugar, se envía una solicitud de acceso mediante broadcast. Si ningún DC de los dominios de recursos responde, la solicitud de acceso a la red se envía al DC de la lista solicitada. La información de acceso se contrasta por un "canal seguro" con el DC que primero responda.

A continuación, la máquina NT solicita una lista de dominios fiables al DC de los dominios de recursos.

Después de que el usuario haya seleccionado el dominio de cuentas de la máscara de acceso al sistema e introducido su nombre y contraseña, se produce el proceso de registro de la cuenta de usuario. El cliente NT envía la información de acceso para que se "apruebe" su acceso en el DC del dominio de recursos donde la máquina cuenta con un canal seguro. El DC del dominio de recursos envía esta petición a un DC del dominio de cuentas (primero localmente y, después, en modo direccional a través del canal seguro). La información de acceso, ya comprobada, vuelve a través del DC del dominio de recursos al cliente NT. El cliente NT establece así una conexión directa con el DC del dominio de cuentas para cargar el script de acceso, las directrices del sistema y el perfil de usuario allí albergado.

También ha de tenerse en cuenta el proceso de acceso siguiente: cuando el usuario se conecta a recursos (como un dispositivo de almacenamiento de archivos montado en un servidor de archivos, por ejemplo con el comando “net use”), el servidor de archivos ha de comprobar la información de acceso poniéndose en contacto con los controladores de dominio una vez más.

3.4.2.10 Autentificación única

El concepto de dominio de Windows NT permite establecer un procedimiento por el que es posible, dentro de la familia Microsoft, autentificarse una única vez. El usuario introduce sus datos una vez en su estación de trabajo Windows NT

Descripción técnica de las vías de migración

Versión: 29.08.2003 Página 89

y, siempre que los recursos y/o servidores sean miembros de su dominio o de uno que confíe en el propio, puede acceder a servicios como:

Archivos e impresión

Exchange

SQL

Intranet (web, Internet Information Server, ...)

Algunos desarrolladores de software pueden implantar sus productos de forma que siga siendo posible la autentificación única. De todos modos, han de instalar sus aplicaciones en servidores Windows NT 4 miembros del dominio.

3.4.2.11 Directivas

En dominios Windows NT se pueden publicar directivas que rijan el uso de contraseñas (fecha de caducidad, longitud mínima, reintroducción de contraseñas incorrectas...), de asignación de permisos a usuarios o grupos (cambio de la hora del sistema, acceso local, etc.).

3.4.2.12 Auditorías

En dominios Windows NT se puede activar una función de auditoría de accesos logrados y/o intentados. Esto permite, por ejemplo, controlar todo movimiento de

inicio y cierre de sesiones

usuarios de permisos

administración de usuarios y grupos

directrices de seguridad.

3.4.2.13 Smart Card (potente mecanismo de autenticación)

El lanzamiento de "Smart Card Base Components" para Windows NT 4 y Windows 9x permitió el desarrollo de aplicaciones de Windows por parte de terceros con funciones Smart Card. Estos desarrolladores ofrecen soluciones para obtener una autentificación muy estricta.

3.4.3 Migración de sustitución: Linux, Samba y OpenLDAP

Cuando se planee hacer una migración total se deben tener en cuenta sobre todo los requisitos de un servicio de autentificación en un entorno heterogéneo de sistemas con clientes Linux y Windows. Es obvio que en este caso sería muy ventajoso el uso de un servicio de directorio, incluido el directorio activo de Windows 2000 y posteriores. Además, la combinación de Linux, Samba y OpenLDAP que se trata a continuación ha demostrado ser una solución de autentificación probada con éxito mucho antes de que existiese el directorio activo. Esto significa que es difícil diferenciar claramente entre el uso de un servicio de directorio como servicio de integración

Descripción técnica de las vías de migración

Página 90 Versión: 28.09.2003

y como servicio de autentificación (consulte el capítulo 3.7 para conocer todos los detalles).

3.4.3.1 Autentificación con Linux, OpenLDAP y Samba

Samba puede ofrecer a los clientes Windows funciones similares a las de un controlador primario de dominio basado en Windows NT (por ejemplo, aunque no sólo, servicios de archivos, impresión y autentificación). Samba, en su papel de base de datos para cuentas de usuarios puede emplear OpenLDAP como servicio de directorios. En este aspecto, la combinación de Samba y OpenLDAP constituye una especie de híbrido de los dominios y directorios activos de Windows NT. Desde el punto de vista de los clientes Windows, se trata de un dominio de Windows NT. En cuanto a la administración de información sobre usuarios, grupos y anfitriones, actúa como una solución basada enteramente en directorios, con todas las ventajas derivadas de este planteamiento. Con una solución Samba/OpenLDAP se evita, en concreto, el problema de ampliación habitual de Windows NT, que suele exigir que la infraestructura se divida en diferentes dominios.

3.4.3.2 Sincronización de contraseñas

Si se utilizan Linux y OpenLDAP como servicio de directorio para clientes Windows conjuntamente con Samba, la autentificación de los clientes Windows se efectúa mediante el protocolo NTLM. Por ello las contraseñas cifradas han de guardarse en el mismo directorio que la base de datos del SAM bajo Windows NT/2000/2003. Con esta restricción cualitativa (sin autentificación Kerberos para clientes Windows 2000/ XP), se hace posible la implantación de una función de autentificación global para clientes Windows sobre la base de Linux, OpenLDAP y Samba.

En este contexto, parece existir un problema a simple vista, en el sentido de que UNIX y Linux usan un algoritmo de cifrado de contraseñas diferente al de Windows NT/ 2000. En el caso de una solución basada en OpenLDAP y Samba, las contraseñas de UNIX y Windows han de guardarse, por lo tanto, en el directorio LDAP y sincronizarlas con las demás. Desde el punto de vista técnico, esto no es un gran problema, dado que se puede configurar Samba para que cambie la contraseña UNIX siempre que se modifique la contraseña del cliente Windows. Por el contrario,

el mecanismo PAM (Pluggable Authentication Module) se puede utilizar para configurar los programas UNIX de forma que también cambien la contraseña Windows siempre que se modifique la de UNIX. Con una configuración apropiada, la sincronización de contraseñas no supone ningún problema. Además, la autentificación de servicios basados en UNIX es posible, igual que con el directorio activo, mediante Kerberos. Las dos versiones de Kerberos, "MIT Kerberos" y "Heimdal" Kerberos son equivalentes para Linux. Cuando se utiliza Kerberos, la sincronización de contraseñas también puede garantizarse con los mecanismos mencionados anteriormente (una forma de sincronización de contraseñas similar debe garantizarse internamente mediante Active Directory para permitir tanto la autentificación con Kerberos como el acceso de clientes antiguos por NTLM).

Descripción técnica de las vías de migración

Versión: 29.08.2003 Página 91

3.4.3.3 Relaciones de confianza

Samba 3.0 admite las relaciones de confianza habituales en Windows NT. Éstas pueden establecerse tanto entre dominios Windows y Samba como entre dos dominios basados en Samba.

3.4.3.4 Servicio WINS

Samba incluye un servicio WINS incorporado. Gracias a Samba 3.0, también tenemos a nuestra disposición un programa de réplicas WINS. No obstante, este programa aún no ha sido probado suficientemente a día de hoy.

3.4.3.5 Restricciones relacionadas con el uso de OpenLDAP y Samba

Como ya se ha mencionado, Samba desempeña el papel desde el punto de vista de los clientes Windows de un servidor basado en Windows NT. Esto significa que las prestaciones de administración de clientes recientemente introducidas en Windows mediante directorios activos aún no están disponibles. Sobre todo no son compatibles los objetos de políticas de grupo o Group Policy Objects (GPO) y la distribución de software por directorio activo. En su aplicación práctica, no obstante, suele ser totalmente apropiado sustituir estas prestaciones con otras técnicas.

GPO

Samba admite las que se conocen como políticas de sistema, que se pueden utilizar para definir ajustes de registro de usuarios, grupos y ordenadores clientes. Las políticas de sistema también permiten utilizar gran parte de los ajustes disponibles mediante GPO (restricciones de la interfaz de usuario de Windows, selección de programas que se pueden utilizar, etc.). La herramienta "editreg" viene integrada en Samba, y permite la edición dinámica de las políticas de sistema.

Además, las políticas locales pueden utilizarse en un entorno Samba, que en principio puede efectuar los mismos ajustes que GPO. Dado que las políticas locales pueden guardarse fácilmente en el sistema de archivos, pueden sincronizarse fácilmente a partir de un prototipo con un gran número de clientes.

Distribución de software

Las funciones de distribución de software que ofrecen los directorios activos están limitadas a software disponible en formato paquetes MSI. Aún así, en la mayoría de los casos se opta por una solución de distribución de software más completa. En este ámbito se hayan disponibles diversas soluciones comerciales que funcionan incluso sin un directorio activo y a menudo corren sobre el sistema operativo Linux. Samba admite perfiles basados en servidor, así se hace posible configurar perfiles obligatorios con los que la configuración de la interfaz de usuario y las aplicaciones se ofrecen ya confeccionadas al usuario.

Los scripts de acceso al sistema se pueden utilizar para determinar numerosos ajustes de servidor, grupo y usuario en clientes Windows.

Descripción técnica de las vías de migración

Página 92 Versión: 28.09.2003

3.4.3.6 Combinación de OpenLDAP y directorios activos

En aquellos casos en los que las prestaciones de un directorio activo son indispensables, se pueden copiar los datos de usuario y grupo del OpenLDAP al directorio activo. A continuación, los usuarios y los grupos han de actualizarse únicamente en el directorio OpenLDAP, pero también están disponibles en el directorio activo, de forma que las propiedades relacionadas (como los GPO) puedan utilizarse, pero manteniendo una única ubicación de administración. En una situación como esta se puede configurar Windows de forma que un servidor Kerberos estándar (sobre Linux) se utilice para ambas partes del entorno. No obstante, esto está sujeto a la restricción que supone para los clientes basados en Windows 95/98/NT no poder autentificarse en el directorio activo y Kerberos. En el caso de que se necesite una combinación como la mencionada, recomendamos la autentificación de estos clientes en Samba y OpenLDAP.

3.4.3.7 Herramientas para la migración de Windows NT a Samba y OpenLDAP

Algunas herramientas que forman parte de Samba permiten exportar la base de datos de usuarios de un controlador de dominio basado en Windows e importarla desde el directorio OpenLDAP. Este método permite un proceso de migración totalmente transparente tanto a usuarios como a sistemas cliente. Por lo tanto, ya no es necesario reintroducir a los clientes en el dominio migrado, y los usuarios pueden seguir utilizando sus nombres y contraseñas de autentificación bajo NT.

Durante el proceso de migración, todos los servicios diferentes del de autentificación han de eliminarse de los controladores de dominio y pasarse a servidores miembros del mismo. En el siguiente paso, los controladores de dominio basados en Windows NT pueden migrarse a Samba y OpenLDAP. Durante un periodo de transición, los servidores miembros basados en Windows pueden seguir utilizándose en el dominio migrado a Samba y OpenLDAP, y se pueden ir pasando progresivamente a Samba.

3.4.3.8 PDC y BDC en dominios Samba

Por bien de la compatibilidad con dominios Windows NT, Samba también es compatible con el concepto de PDC y BDC. Esta compatibilidad está limitada, de todos modos, al hecho de que los servidores Samba se presentan a los clientes Windows como PDC o BDC, dependiendo de la configuración efectuada. Samba por sí mismo no es capaz de replicar la base de datos SAM entre PDC y BDC. No obstante, la réplica puede efectuarse por OpenLDAP guardando el SAM en un directorio LDAP.

El servidor Samba configurado como PDC suele tener permiso de escritura en el servidor maestro OpenLDAP, por lo tanto tiene la autorización necesaria para hacer cambios en la base de datos de usuarios. Los BDC se configuran de forma que tengan sólo acceso de lectura en el servidor OpenLDAP esclavo, que suele ejecutarse en el mismo ordenador que el BDC Samba. Cuando la base de datos SAM se cambia en el PDC, éste guarda los cambios en el directorio LDAP.

Éste se transfiere a continuación mediante réplica LDAP a los BDC, de forma que la base de datos modificada también esté actualizada en los últimos.

Por otra parte, el contenido de los volúmenes compartidos netlogon (los que albergan por ejemplo, las políticas y scripts de acceso al sistema) también se mantienen sincronizados en el dominio Windows NT.

Bajo Linux, esto se puede conseguir con el programa rsync, por ejemplo.

Descripción técnica de las vías de migración

Versión: 29.08.2003 Página 93

3.4.3.9 Samba como miembro de un dominio de directorio activo

Por otra parte, Samba es capaz de utilizar las etiquetas Kerberos de un servidor de directorio activo para autenticarse. Esto significa que se puede utilizar Samba como servidor miembro de pleno derecho en dominios AD.

3.4.3.10 Herramientas de administración

La administración de usuarios y grupos en dominios basados en Samba y OpenLDAP se puede realizar mediante las herramientas de administración de Windows NT (usrmgr.exe). A pesar de ello, las ventajas especiales de la solución basada en servicios de directorio (como los diversos niveles de permisos o la estructura de directorios anidada) no se pueden utilizar en este caso porque dichas prestaciones no son compatibles con Windows NT. En cuanto a las herramientas de administración de OpenLDAP, consulte por favor el capítulo 3.7.4.7.

3.4.4 Migración por continuación

3.4.4.1 Windows 2000

Respecto a los servicios de acceso al sistema, no se puede decir que Windows 2000 sea una simple "actualización" del sistema operativo. No sólo es la actualización y el proceso de instalación un proceso completo y complejo, el cambio fundamental de arquitectura orientándola hacia los "servicios de directorio activo" es otra novedad que abarca diferentes aspectos.

En este punto de la guía no vamos a describir el servicio de inicio de sesión de Windows 2000 como un tema independiente de los directorios activos sino como protagonista del servicio de directorio. Aquí encontramos los mismos problemas relacionados con la distinción clara entre directorio activo como infraestructura y como parte del servicio de autenticación. Diríjase también al capítulo 3.7.5, que también trata sobre el reciente producto Windows Server 2003.

3.5 Servicios de red

3.5.1 Conceptos generales

El resultado del análisis de detalles técnicos que presentamos a continuación sugiere que se puede efectuar la migración sin problema alguno. No hay que esperar restricciones en entornos de sistemas heterogéneos ni homogéneos (migración por contiuidad o migración completa)).

Descripción técnica de las vías de migración

Página 94 Versión: 28.09.2003

3.5.2 Situación de partida: servicios de red bajo Windows NT

Esta subsección trata sobre los siguientes servicios de red:

WINS

DNS

DHCP

Los sistemas cliente y servidor se diferencian cuando es necesario.

En un sentido amplio, los siguientes servicios

RAS (servicio de acceso remoto o Remote Access Service) y enrutado

Proxy web

Pasarela SNA

también pueden considerarse servicios de red. Microsoft ofrece productos de servidor separados o productos adicionales (como el SNA Server 4.0 o el Proxy Server 2.0). Estos productos no se tratarán en esta subsección.

En lugar de eso, sólo abordaremos brevemente las nuevas prestaciones de los servicios de red mencionados anteriormente relacionadas con la introducción de Windows 2000.

3.5.2.1 Servicio Windows de nombres de Internet o Windows Internet Name Service (WINS)

El servicio Windows de nombres de Internet de Microsoft (WINS) puede instalarse en los sistemas operativos Windows NT 4 Server. WINS es un servicio compatible con RFC's que permite la traducción de nombres NetBIOS en direcciones IP, y al mismo tiempo también constituye un servicio que acaba con la necesidad de traducir nombres NetBIOS mediante la emisión local del archivo LMHOSTS.

WINS permite así la resolución de nombres NetBIOS más allá de las subredes IP. WINS se puede utilizar de forma tanto dinámica como estática. La forma dinámica significa que los clientes WINS pueden presentarse a sí mismos dinámicamente. La forma estática significa que los administradores introducen los nombres y direcciones IP manualmente.

WINS guarda la información en una base de datos (Jet-Engine, wins.mdb) cuyo contenido puede combinarse en diversos servidores WINS. Para ello, los servidores WINS se configuran para que "empujen" y/o "tiren" de los miembros de la red. El contenido se guarda según el principio de varios maestros. Esto significa que todo servidor WINS puede introducir registros. Además, también se puede utilizar un proxy WINS. Un ordenador que desempeña la función de proxy WINS no guarda una base de datos propia, sino que recibe solicitudes de los clientes y se las envía a un servidor WINS maestro.

Todos los sistemas operativos Windows lanzados hasta ahora (desde Windows 9x hasta Windows XP y todos los sistemas para servidor) pueden actuar como cliente WINS.

El mismo cliente WINS se puede configurar en función del tipo de nodo para determinar si ha de resolver los nombres NetBIOS y cómo debe hacerlo.

El espacio de nombres NetBIOS es un espacio de nombres plano y, más que estar restringido a nombres de ordenador, también cubre nombres de usuario, servicios, nombres de dominios o grupos de trabajo Windows, etc.

La tabla que se muestra debajo (tabla 11) presenta los tipos de nombres NetBIOS que se pueden identificar por el byte 16 del nombre NetBIOS.

Se discriminan nombres únicos y nombres de grupo. Los nombres de grupo se pueden utilizar y, por tanto, introducir al mismo tiempo por varios ordenadores.

La tabla siguiente muestra los identificadores únicos.

Tabla 11. Identificaciones únicas de nombres NetBIOS.

Byte 16	es identificador único para
<00>	el nombre NetBIOS del ordenador
<03>	el servicio de mensaje tanto para el ordenador como para el usuario conectado
<1B>	el “domain master browser” que se hace disponible por el PDC de un dominio
<06>	un RAS (Remote Access Service) en un ordenador
<1F>	un servicio NetDDE en un ordenador
<20>	el servicio servidor de un ordenador (particularmente importante en el caso de liberaciones de directorios)
<21>	un ordenador con un cliente RAS
<BE>	un agente monitor de red
<BF>	un ordenador con la llamada “utilidad de monitor de red”

La tabla siguiente muestra las identificaciones que pueden usar varios ordenadores.

Tabla 12: Identificaciones multivalor de nombre NetBIOS.

Byte 16	es identificador multivalor para
<1C>	un nombre de un dominio
<1D>	el nombre de los “master browsers”
<1E>	un nombre de grupo normal
<20>	un nombre de grupo especial (llamado el grupo internet)
_MSBROWSE_	en lugar de un único byte 16, se puede añadir “_MSBROWSE_” al nombre de dominio para que pueda conocerlo otro “master browser”

Domain Name System (DNS)

Domain Name System (DNS) es un servicio que se puede instalar en los sistemas operativos Windows NT 4.0 Server. Soporta las RFC 1033, 1034, 1035, 1101, 1123, 1183 y 1536 y es compatible con la implementación Berkeley Internet Name Domain (BIND).

El DNS (Servidor de Nombres de Dominios) de un servidor Windows NT 4 soporta BIND en versión 4.9.4.

DNS es el estándar internet que posibilita, entre otras cosas, la resolución de nombres de ordenadores en una dirección IP y viceversa (búsqueda inversa) dentro de un espacio de nombres jerárquico. El uso de un servidor DNS elimina la necesidad de utilizar listas de entradas locales en un fichero HOSTS.

La jerarquía del espacio de nombres está reflejada en el separador “.” en la notación de los nombres. El denominado nombre de dominio totalmente cualificado (FQDN, fully qualified domain name) consta de dos partes: la primera, antes del primer punto, identifica el nombre del servidor, y la segunda parte el dominio DNS. Por ejemplo ordenador1.microsoft.com describe el ordenador con el nombre 'ordenador1' en el dominio microsoft.com. No es un requisito obligatorio que el FQDN conste de tres partes. Los caracteres válidos en el FQDN son las letras a - z, A – Z y el signo menos.

Desde que el DNS es un estándar internet, no es posible la elección libre de un nombre de dominio. Los dominios deben ser registrados con los órganos de la administración relevantes nacionales o internacionales. Sin embargo si el espacio de nombre DNS es visible sólo internamente a una organización es posible utilizar nombres no registrados. Los nombres o zonas registrados no deben ser utilizados, evitando con este enfoque que las zonas registradas por otros usuarios u organizaciones sean usadas.

El DNS incluye mecanismos que permiten el particionamiento de la base de datos asociada, para adaptarse a entornos distribuidos. De una parte la resolución del nombre puede ser delegada para dominios especiales, y por otra la administración y replicación (transferencia de zona) pude ser controlada por medio de creación de zonas.

La implementación bajo Windows NT 4 es BIND 4.9.4, teniendo en cuenta que el DNS trabaja como un sistema totalmente estático (es decir no soporta entradas dinámicas) y por tanto los cambios pueden ser hechos únicamente en el servidor primario de una zona (principio de master-simple).

Una característica especial de la implementación DNS bajo Windows NT 4 es la posibilidad de salir del servicio DNS y utilizar de forma complementaria un servidor WINS para la resolución de nombres.

El DNS soporta no sólo las entradas de nombres de ordenadores, sino además registro de recursos adicionales. La siguiente tabla muestra los tipos de registros de recursos soportados en Windows NT

Tipo de Registro	Descripción Breve
A	Entrada de Dirección (la clásica entrada para pasar un servidor a una dirección IP)
AFSDB	Entrada especial para el Sistema de Ficheros Andrew (AFS)
CNAME	Alias (o nombre canónico)
HINFO	Entrada especial para información de hardware, de acuerdo a la RFC 1700
ISDN	Entrada para ISDN (Red Digital de Servicios Integrados, RDSI) conjuntamente con el tipo RT (route through)

Tipo de registro	Descripción breve
MB, MG, MINFO, MR	Entradas especiales para buzones de correo, grupos de correo, información de cuentas de mail.
MX	Entrada para enrutado de correo vía SMTP (Protocolo de Transferencia de Mensaje Simple).
NS	Entrada para un servidor DNS (servidor de nombre) de un DNS de dominio.
PTR	Entrada de dirección reservada (registro de recurso de puntero) para resolver una dirección ip dentro de un nombre de host.
RP	Entrada para la persona responsable de un dominio especial DNS.
RT	El registro de recurso enrutador especifica un host intermedio que encamina paquetes al host destino. La entrada RT es usada conjuntamente con los registros de recursos ISDN y X25. Esto es sintácticamente y semánticamente similar al tipo de registro MX y es utilizado de igual forma.
SOA	Entrada para el servidor primario DNS (empezar con autoridad, privilegios).
TXT	Entrada para información de texto.
WINS	Entrada de la dirección de IP del servidor WINS para ser adicionalmente usado con resolución avanzada.
WINS_R	Entrada búsqueda reservada vía servidor WINS.
WKS	Entrada para servicio well-know.
X.25	Entrada para una dirección X.121

Todos los sistemas operativos Windows lanzados hasta hoy (desde Windows 9x hasta Windows XP y todos los sistemas operativos Servidor) pueden implementar un cliente DNS. Los sistemas con Windows 2000 o superior también soportan DNS Dinámico (DDNS) como cliente. Con referencia a DDNS, por favor consulte el capítulo 3.5.2.3.

Protocolo dinámico de configuración de host (DHCP)

DHCP es un estándar de la industria para configuración dinámica de protocolo ip de ordenadores y otros elementos de TCP/IP (como son impresoras de red). DHCP está basado en las RFCs 1533, 1534, 1541 y 1542.

La implementación de Windows NT 4 Server soporta las opciones de acuerdo a la RFC 1541 las cuales se muestran en la tabla de abajo. Las opciones impresas en negrita son utilizadas por clientes DCHP Windows NT 4 y superiores.

Tabla 14: Opciones DHCP

Nº	Nombre opción	Descripción

Página reservada para la tabla 14 (continuación)

Otra posibilidad es el uso de un agente “conmutador” de DHCP. Un ordenador que proporciona este servicio no mantiene una base de datos en sí; recibe solicitudes de los clientes y las pasa a un servidor DHCP de mayor escala.

Servicios de Red bajo Linux.

Los servicios que constituyen la infraestructura de las redes basadas en TCP/IP (DNS, DHCP, NTP, enrutamiento, VPN y filtrado) pueden ser implementados por medio de software de código abierto (OSS). La disponibilidad de estos servicios como OSS puede entenderse a la luz de la historia del desarrollo de internet. La característica más destacada de la world wide web la constituye el hecho de que todos los ordenadores conectados a ésta hablen el mismo lenguaje. Este lenguaje está formado por la familia completa de protocolos que se agrupan bajo el término TCP/IP. Un requisito vital es que el entendimiento de este lenguaje sea el mismo para todos, con el objeto de asegurar una comunicación fluida entre sistemas muy variados por todo el mundo. Con el objeto de garantizarlo, la mayoría de los estándares de protocolos internet oficialmente adoptados por la 'Internet Engineering Task Force' (IETF) están soportados por implementaciones OSS. En base a estas Implementaciones de Referencia, los fabricantes pueden desarrollar independientemente software plenamente compatible. Los protocolos de internet son independientes de fabricantes y constituyen estándares abiertos, tanto en términos de definición, como por sus implementaciones OSS. Esta característica especial de los protocolos internet ha sido la razón decisiva para que TCP/IP haya prevalecido por encima de los protocolos de red propietarios que simultáneamente existían en el mercado.

Aunque los requisitos de compatibilidad sean muy limitados en el caso de redes locales debido al número limitado de sistemas involucrados, mantener estándares abiertos es de la máxima importancia. Especialmente en los casos de modificaciones específicas y/o modificaciones de estándares por parte de un fabricante, existe siempre un riesgo de alcanzar una situación de 'cautividad'. Por un lado, los lazos con este fabricante son reforzados y pueden conducir incluso a una dependencia, y por otro, hay que considerar la capacidad de definición que se otorga al fabricante respecto a futuros desarrollos o a la interoperabilidad con sistemas de terceras partes.

Teniendo en cuenta estas consideraciones, siempre debemos comprobar si las mejoras ligadas a una modificación específica de un estándar por parte de un fabricante es asumible con una perspectiva a más largo plazo. Aunque las Implementaciones de Referencia, largamente probadas durante todos estos años no incluyan necesariamente todas y cada una de las características posibles, están garantizando una compatibilidad sostenida con todos los sistemas capaces de ser integrados en la red.

3.5.3.1 Sistema de nombres de dominio (DNS)

La implementación de referencia del estándar para el sistema de nombres de dominio que está definido en una serie de documentos RFC es BIND (Berkeley Internet Name Domain), el cuál se actualiza y se mantiene por el Internet Software Consortium (ISC) independientemente de fabricantes o empresas. La última versión es la 9.2.x. De todos modos, la línea de versiones 8.3.x todavía cuenta con la mayor parte de las instalaciones básicas de servidores DNS, y todavía se mantiene por parte de ISC. Las versiones 4.9.8 y anteriores ya no se usan.

Bind 9 soporta, entre otras cosas, DNS dinámico (DDNS), DNSSEC e Ipv6.

Se puede conectar BIND 9 a fuentes de datos externas para información de zona mediante un conjunto de interfaces de bases de datos BackEnd. También existe una interfaz simple (SDB) que puede, por ejemplo, ser usada para implementar acceso de sólo lectura a bases de datos LDAP o SQL. La conexión LDAP, por ejemplo, es posible tanto utilizando implementaciones SDB como con objeto de clases predefinidas que permitan implementar esta conexión.

ISC BIND también puede ser utilizado conjuntamente con Windows NT/ Windows 2000. BIND 9, en particular, soporta la actualización dinámica de registros de servicios y puede realizar los servicios correspondientes para servidores Windows 2000.

3.5.3.2. Protocolo de configuración dinámica de host (DHCP)

La implementación de referencia de el DHCP también ha sido desarrollada y actualizada por el ISC. El protocolo y el software tienen las siguientes funciones y ofrecen las siguientes opciones:

Asignación automática de direcciones IP y nombres de ordenadores a los clientes. DHCP permite tanto la asignación de direcciones IP estáticas (en base a la dirección MAC de la tarjeta de red) como de la asignación dinámica de una dirección libre de un rango de direcciones previamente definido.

Transmisión automática de información que tenga que ver con la infraestructura de red. DHCP puede, por ejemplo, ser utilizado para la administración central y distribución a todos los clientes del nombre del dominio y el servidor de nombres, la ruta por defecto y la máscara de red.

Además, un gran número de campos opcionales y definibles libremente sobre la configuración del host, pueden devolverse vía el demonio DHCP (dhcpd). El dhcpd del ISC puede, por ejemplo, usarse para transmitir cualquier tipo de opciones que pueden ser usadas por los clientes Windows.

Además, el dhcpd puede funcionar como bootpd y de esta manera enviar cualquier información necesaria para arrancar un cliente por la red.

El dhcpd de ISC habilita tanto la administración de clientes individuales como configuraciones colectivas de clases y subredes en la información liberada. Además, la asignación condicional de los datos de configuración del host por declaraciones IF es posible en la configuración del dhcpd del ISC.El dhcpd puede ser utilizado en una configuración tolerante a fallos tanto para el balanceo de la carga como para la Alta Disponibilidad (HA). Las áreas IP administradas dinámicamente están coordinadas, por lo tanto, entre los servidores que se sustituyen mutuamente.

El dhcpd de ISC se configura de la manera estándar UNIX mediante un fichero de configuración ASCII. Está disponible un parche para que la configuración del servidor dhcpd de ISC se importe de un almacén LDAP. La implementación sigue el borrador del esquema LDAP para DHCP de la IETF.

3.5.3.3 Servicio de nombres de internet Windows (WINS)

Siguiendo con la migración del SO, la resolución de nombres para los servicios Windows y ordenadores es llevado a cabo por el nmbd del paquete Samba. Esto significa que los servicios de exploración basados en difusión utilizados comúnmente en Windows pueden ser prestados como cliente y como local, o como explorador global de dominio por un lado. Por otro lado, sin embargo, nmbd puede actuar también como WINS y en este modo, coordinar el explorador a través de los límites de los segmentos de red, que normalmente están conectados por enrutadores que no permiten el traspaso de paquetes de multidifusión a través de ellos.

Protocolo de sincronización horaria(NTP)

Muchas aplicaciones en red necesitan un alto grado de sincronización. El Protocolo de sincronización horaria (NTP) se utiliza para sincronizar los relojes de los ordenadores en la red local con una precisión de milisegundos. Con una conexión a Internet permanente, la hora de referencia puede ser sincronizada con la hora oficial con una precisión de milisegundos. Alternativamente, las fuentes de referencia estándar incluyen, pero no están limitadas a, DCF77 y GPS.

La implementación de referencia del estándar está desarrollada y mantenida por el Network Time Protocol Project. El software puede ser usado también sobre Windows NT.

3.5.4 Siguiendo con la migración – servicios de red sobre Windows 2000

La siguiente sección describe brevemente las nuevas características de los servicios de red mencionados antes a propósito de la llegada de Windows 2000.

3.5.4.1 WINS

En lo que respecta a WINS, Windows 2000 no ofrece ninguna nueva característica en su arquitectura. Windows 2000 simplemente viene con una mejor gestión de la base de datos WINS.

3.5.4.2 DNS

El servicio DNS ha tenido los cambios de mayor envergadura como resultado del lanzamiento de Windows 2000. La razón principal para esto es que el Directorio Activo de Windows utiliza DNS para la resolución primaria y/o no funcionaría sin DNS. Un directorio activo utiliza DNS para varios propósitos, incluyendo, pero no limitados a, la búsqueda de servicios relacionados con la autenticación y exploración (Servicio LDAP,

Servicio Global de Catálogo y Keberos KDC). Como condición previa para el establecimiento de servicios, el DNS debe soportar los también llamados Registros SRV de acuerdo con el RFC 2052. Dado que el DNS previo funcionaba estáticamente (el establecimiento de servicios debía hacerse manualmente), se implementó una función para el registro dinámico en Windows 2000, también con la perspectiva planeada de la futura omisión del WINS. Los ordenadores pueden introducir sus registros A y SRV dinámicamente. La implementación sigue el RFC 2136 (Actualización Dinámica) en este contexto. Los ordenadores con Windows 2000 o superior pueden registrarse a sí mismos dinámicamente (implementación en el cliente DHCP). Windows NT y 9x no pueden hacer esto, necesitan la ayuda de un servicio DHCP de Windows 2000. El registro dinámico implica un cambio en la arquitectura de las implementaciones anteriores de DNS, donde un servidor DNS (el primario) puede escribir los contenidos de zona. Microsoft implementa un principio de multi-maestro integrando DNS en el directorio activo. Las entradas DNS son entonces objetos de la base de datos en el directorio activo y se replican de este modo. El registro dinámico sin AD no existe. El registro dinámico está sujeto a mecanismos de seguridad para asegurarse que sólo los ordenadores que pueden autentificarse a sí mismos (como los Windows 2000 del dominio pertinente) pueden registrarse. Windows 2000 soporta la también llamada “Actualización Segura” siguiendo la GSS API de acuerdo al RFC 2078; no están implementadas las RFCs 2535 (Extensiones de seguridad para los sistemas de nombres de dominio) ó 2137 (Actualización dinámica segura del sistema de nombres de dominio) .

3.5.4.3 DHCP

En lo que respecta a DHCP, Windows 2000 ofrece algunas características nuevas aparte de la mencionadas. Sobre Windows 2000, los actuales RFCs 2131 (Protocolo de configuración dinámica del host, anteriormente RFC 1541) y 2132 (Opciones DHCP y extensiones del vendedor BOOTP) están soportados. Además están soportadas ahora la mejora en la gestión, alcances del Multicast, opciones específicas para DHCP del usuario y fabricante así como BOOTP dinámico.

Otra nueva característica es la integración de DHCP y DNS dentro de la red Windows 2000. Los clientes con Windows NT 4 o anteriores no soportan el registro dinámico de sus nombres DNS dentro del DNS dinámico de Windows 2000. Si estos clientes obtienen su configuración IP de un servidor DHCP Windows 2000, el servidor DHCP debe realizar el registro en el DNS.

El cliente DHCP de Windows 2000 puede crear él mismo su configuración IP si no hay un servidor DHCP en la red. La dirección IP de una red de clase B 169.254.0.0 con la máscara de subred 255.255.0.0 se utilizan para este caso.

3.6 Intervención del sistema y servicios de gestión

3.6.1 Descripción

Debe notarse que, debido al hecho que sólo están disponibles un rango limitado de herramientas para la gestión del sistema en Windows NT, y que su funcionalidad es limitada, se suele utilizar un conjunto de herramientas de otros fabricantes, muchas de las cuales también están disponibles para sistemas Linux.DESCRIPCIÓN TECNICA DE LAS VIAS DE MIGRACIÓN

Aparte de numerosas herramientas ya incluidas, tales como cron/at, Linux incluye más productos COLS así como soluciones OSS para la administración del sistema. Por ejemplo, Nagios, es una herramienta para visualización y servicio de auditoria. Un sistema complejo, altamente integrado y adecuado para todas las tareas de admintración de sistema aún no esta disponible como una solución OSS.

Microsoft también mejoró sus conjuntos de herramientas con la continuación de sus linea de producto. Entre las herramientas que se pueden mencionar en éste contexto estan el 'Microsoft Operations Manager' y el 'Application Center'.

Situación inicial – Systems Management Server bajo Windows NT 4

El System Management Server (SMS) fue distribuido más o menos al mismo tiempo que Windows NT 4. SMS versión 1.2 puede ser considerada como la última versión de esta generación. La versión 2.0 fué lanzada en 1999. A continuación se describe la funcionalidad de esta versión.

SMS integra varias funcionalidades basicas que otros fabricantes también cubren por un producto integrado y en una forma comparable. Estas funcionalidades son:

Inventario

Control remoto

Distribución de software

Windows NT Server 4.0, a partir del Service Pack 4, y Microsoft SQL Server 6.5, a partir del Service Pack 4, son requerimientos para utilizar el software del servidor.

SMS 2.0 puede ser utilizado en grandes entornos con más de 100.000 clientes. Ya que puede ser incrustado en la estructura de dominio de Windows, niveles de seguridad granular estan disponibles. SMS también soporta entornos NDS y Bindery de Novell Netware.

SMS 2.0 incluye una distribución de software electronica que instala y desinstala software de una forma bastante automatica., ideal en caso de no tener que realizar trabajo localmente y sin que ocurran errorres en el lado del usuario. La distribución de software puede ser realizada en un formato basado en reglas. Los administradores determinan la configuración de software al añadir y/o quitar computadores, usuarios o grupos de usuarios de listas en base a un criterio definido. SMS registra el estado de las instalaciones de software y actualizaciones del sistema operativo sin que los administradores de sistemas sean informados si el software fué instalado correctamente. SMS instala software sin ser supervisado y sin intervención del usuario. La instalación con derechos de administrador es posible incluso para un usuario autentificado en la computadora con privilegios muy inferiores. Las computadoras basadas en NT no necesitan autentificación de usuario, por lo tanto ésta característica es adecuada para distribución a horas diferentes a las regulares de jornada laboral. SMS permite la distribucuón de sofware, controlada por tiempo, a cualquier combinación de usuarios, grupos de usuarios, segmentos de red TCP/IP y computadoras. SMS 2.0 determina dinamicamente los objetivos de distribución en base a perfiles para grupos y las puede aplicar a todos los sitios.

DESCRIPCIÓN TECNICA DE LAS VIAS DE MIGRACIÓN

Cuando nuevos usuarios se unen a un grupo, el software adecuado puede ser enviado automaticamente en base a su perfil. La llamada función de distribución de paquete estructurado considera la topología de red para así asegurar la distribución eficiente de software a conexiones lentas. Así los servidores del sitio hacen de enrutadores que distribuyen el software de forma inteligente y estructurada. Esta aproximación se asegura de que una distribución que use una conexión WAN se realice una única vez. SMS 2.0 puede distribuir software utilizando Courier Sender en CD-ROM u otro medio. Cuando el medio (por ejemplo, el CD-ROM) llega al usuario y se inserta en su sistema, el proceso automatico arranca. Se suministra un programa de instalación que permite la compilación de paquetes de software. Permite a los administradores de sistemas la modificación de paquetes de instalación y escribir codigo para compilar paquetes para aplicaciones basadas en Windows. El Instalador SMS incluye una función de registro de la instalación además de tecnologias auxiliares para la distribución de software. El instalador usa tecnologia instantanea.

SMS 2.0 puede preparar inventarios de equipos y programas. En un proceso basado en CIM de inventariado de equipos, SMS 2.0 colecciona datos en formato CIM (Common Information Model) lo cual le da acceso a muy diferentes fuentes, incluyendo Microsoft Win32, SNMP y DMI. SMS colecciona datos muy amplios de inventariado, que pueden ser filtrados mediante opciones. El proceso de inventariado de programas colecciona información exacta relativa a cada aplicación en cada computadora. SMS 2.0 busca la información relativa a la versión en cada archivo ejecutable del computador del cliente, antes que en una base de datos predefinida. Los datos de inventario pueden ser utilizados como una base de datos para la distribución de programas basado en reglas.

El dispositivo de control remoto permite ejecución remota de aplicaciones, comunicación con los usuarios por medio de ventanas interactivas y el rearranque de computadoras. Más aún, la pantalla, el teclado y el ratón pueden ser controlados remotamente.

SMS 2.0 viene con las siguientes funcionalidades de manejo de red: se puede utilizar SMS para mostrar y visualizar la topologia de red y que clientes y sistemas operativos han sido usados. SMS prepara la visualización de un mapa de los servidores de la red y demás dispositivos, para así poder dar soporte a los administradores del sistema en sus tareas de manejo de la red y sus problemas asociados. La monitorización de las comunicaciones de los datos permite el descubrimiento de problemas en la red, tales como protocolos que no son necesarios, direcciones IP que han sido asignadas dos veces, así como intentos no autorizados de acceso a Internet. El monitor de red puede interpretar automaticamente los resultados.

SMS 2.0 ofrece herramientas para el analisis, monitorización y control de las aplicaciones tanto en los servidores como en las estaciones de trabajo (medicion de software). El uso de programas puede ser clasificado y monitorizado en base a usuarios, grupos, estaciones de trabajo, tiempo o cupo de licencias. Aún más, el uso de ciertas aplicaciones puede ser controlado, se pueden definir cupos eventuales, o se pueden determinar aplicaciones no autorizadas. Ésta característica también permite monitorizar si las reglas son cumplidas en cualquier cliente o servidor. Los programas de medición de software también detectan versiones diferentes de programas y pueden averiguar si hay agentes desactivados, de esta forma es posible una protección exhaustiva contra la manipulación. Las estadisticas de utilización se pueden usar para determinar los requerimientos de licencias y medir los cargos y honorarios de departamentos individuales como una función del uso de aplicaciones (manejo de licencias).DESCRIPCIÓN TECNICA DE LAS VIAS DE MIGRACIÓN

La Monitorización de Servidor es realizada por HealthMon. HealthMon determina los datos de rendimiento de los procesos en Windows NT Server y Microsoft BackOffice Server. Umbrales de valores criticos o de mensajes de alerta pueden determinarse en la consola de HealthMon y de esta forma se reciben en tiempo real información de estado y excepciones. Esta información puede ser agrupada de acuerdo con los recursos, a nivel de sistema, de acuerdo con las aplicaciones y procesos de Microsoft.

Migración de reemplazo – Linux

El manejo del sistema para sistemas operativos OSS se basa en la funcionalidad basica de un sistema operativo de red multiusuario. Un administrador, en su terminal remoto, puede trabajar en cualquier computador Linux/BSD (sin importar si es cliente o servidor) de exactamente la misma forma que en una computadora local. También es perfectamente adecuada la interfaz grafica de usuario, para el control remoto de computadoras, gracias a la separación sistematica del servidor (con pantalla, teclado y ratón) y el software del cliente, que muestra sus ventanas e iconos/caracteres y que recibe entradas del servidor via una conexión de red, bien localmente o más lejos. Más características incluyen el Secure Shell (ssh) y un completo equipamieno de herramientas con cron/at para el control de tiempo y poderosos interpretes de linea de comandos, utilidades y lenguajes de programación interpretados para la automatización de tareas rutinarias de cualquier nivel de complejidad. No se necesita más soporte de software para el control remoto de sistemas OSS.

Los sistemas OSS ofrecen, además, componentes adicionales para un manejo centralizado en redes heterogeneas. En el nivel más alto de la escala, Linux puede ser integrado en la administración de sistemas con Tivoli o con OpenView. Hay una gran variedad de opciones para automatizar o dar un soporte especifico a tareas de administracion del sistema entre estas soluciones, que realmente no forman parte del OSS y funciones simples que utilizan las herramientas del sistema.

Administración de software

Varios suministradores ofrecen soluciones comerciales para el inventariado (inventarios), distribución y actualización, así como el manejo de la configuración de componentes de software. Algunas de estas soluciones son también adecuadas a sistemas heterogeneos con un componente Windows. Una solución integrada, lista para producción, no existe en software Open Source, especialmente para entornos heterogeneos. Sin embargo, herramientas de administración de paquetes (RPM y APT) facilitan una sencilla centralización de inventariado (inventarios), distribución y/o actualización del software. Especialmente, la funcionalidad de manejo de paquetes de Debian es perfectamente adecuada para un control centralizado de software ya que puede trabajar con una jerarquia de almacenes centrales de software y porque muestra un comportamiento muy robusto para la actualización.

En el area de seguridad, Tripwire es la herramienta preferida para la monitorización y el control de inventario.DESCRIPCIÓN TECNICA DE LAS VIAS DE MIGRACIÓN

Administración de la red

Un amplio rango de programas con diferentes puntos focales existen para el manejo de redes TCP/IP.

La herramienta de monitorización “Nagios” esta especializada en la visualización de la topologia de red y en la monitorización de los servicios, incluso en servidores con otros sistemas operativos. Nagios responde a errores o eventos en una manera basada en reglas, por ejemplo, basandose en valores de umbrales definibles. Escalada de mensajes e integración de diferentes canales de mensajes (tales como correo o SMS) son posibles en este contexto.

Nagios utiliza conectores para la monitorización activa y pasiva de los más variados servicios y parametros del sistema. Por ejemplo, es posible monitorizar servicios tipicos de red, tales como Web, correo y LDAP, así como diferentes RDBMs o Samba. Otros conectores capacitan la monitorización de parametros del sistema, como la carga de la CPU, espacio en disco duro, así como datos sensores de maquinaria (temperatura, suministro de potencia y velocidad del ventilador). Existen puentes a otros sistemas, tales como MRTG/RRD, para el uso de SNMP para monitorización. Interfaces simples y plantillas posibilitan el rapido desarrollo de conectores definidos por el usuario.

MRTG/RRD se especializa en la monitorización y analisis del trafico de red. MRTG usa el Simple Network Management Protocol para obtener y almacenar datos de trafico de los más variados componentes de la red.La evaluación y conversión a graficos puede entonces ser elaborada bien internamente por MRTG o externamente por RRD. Mas de 350 plantillas estan disponibles para que MRTG pueda conectarse directamente a los más variados componentes y servicios que usan SNMP.

NeTraMet , que también utiliza SNMP, es otra herramienta para el analisis y visualización del trafico.

Scotty es otra herramienta para la visualización y manejo de redes locales. Scotty tambien trabaja con SNMP y también posibilita la edición de parametros accesibles por SNMP en componentes de red remotos.

Snort se especializa en la busqueda de patrones extraños en el trafico de red, para así detectar intentos de intrusión y otros casos de uso no autorizado. Como un “Sistema Ligero de Detección de Intrusión”, Snort es un componente valiosopara el manejo del sistema en la red.

Manejo del servidor

Linux incluye, por ejemplo, Ulimits, Quotas y Contabilidad de Proceso para los propositos de administración del servidor. Estas funciones se utilizan para monitorizar y restringir los recursos del sistema a usuarios individuales o a procesos. La herramienta “Nagios” introducida antes en relación con el manejo de red, se utiliza para monitorizar servicios y parametros locales del sistema.

Los servicios de servidores OSS utilizan una API común para registrar mensajes via syslogd. Este servicio de registro posibilita la monitorzación central, organizada jerarquicamente, de toda la infraestructura Linux/ BSD/ UNIX. Los servidores de Windows tambien pueden ser integrados en un sistema central de Syslog. Gran cantidad de herramientas y conceptos estan disponibles para la evaluación automatica de los archivos de registro. Un buen resumen se puede encontrar en http://www.counterpane.com/log-analysis.html

DESCRIPCIÓN TECNICA DE LAS VIAS DE MIGRACIÓN

Herramientas del sistema, tales como strace, lsof, fuser y netstat, ofrecen excelentes funciones analiticas para operaciones de detección de errores y su analisis, además de los servicios regulares de protocolos. Estas funciones se necesitan ocasionalmente para la administración del servidor.

Sistemas de mayor complejidad

En el campo de la administración de sistemas, no solamente existe el Simple Network Management Protocol, tambien el Common Information Model (CIM) con el Web Based Enterprise Management (WBEM) basado en éste para una aproximación más completa hacia una administración del sistema estandarizada en redes heterogeneas. CIM/ WBEM, como SNMP, son descritos por estandares abiertos, y estan disponibles en las implementaciones referidas como software Open Source. Sin embargo, actualmente estos componentes son utilizados principalmente en el ambito de productos comerciales. La convenencia de soluciones puras de Open Source aún tienen que ser demostradas en este area.

Conclusiones

Respecto a la administración de sistemas, los sistemas operativos OSS siguen el camino de UNIX, en linea con su origen. Los sistemas OSS como multiusuarios y de red, vienen con un amplio rango de funciones para una administración centralizada y, en algunas areas, son el modelo más que una alternativa sustitutoria a una solución Windows. La migración significa también cambios conceptuales para los administradores y la organización de procesos, especialmente respecto a la seguridad. El alto grado de seguridad y confianza generalmente asociado con sistemas Linux no es el menor resultado en la administración de sistemas.

Un proyecto de migración implica amplios cambios a los que estan a cargo de la administración del sistema. Tanto las características analiticas como las opciones de ajuste y corrección los sistemas OSS dan a los administradores mucha más libertad que la que se puede encontrar en un sistema cerrado Windows. Esta libertad puede utilizarse para liberarse de fabricantes y suministradores de servicios externos, mientras que al mismo tiempo se incrementa la cualificación del personal propio. La transparencia de los sistemas abiertos OSS contribuye a una comprensión fundamental y de largo alcance de la funcionalidad y dependencias de los diferentes componentes en una infraestructura IT moderna.

Continuando con la migración – Windows 2000

Microsoft Operations Manager

Microsoft Operations Manager (MOM) se basa en un desarrollo de la compañía NetIQ y soporta la administración de sistemas servidores basados en Windows 2000, enfatizando los eventos, monitorización del rendimiento y administración.

Actualmente Microsoft Operations Manager esta disponible como versión MOM 2000 e incluye las siguientes funcionalidades:DESCRIPCIÓN TECNICA DE LAS VIAS DE MIGRACIÓN

MOM colecciona varios eventos del sistema y de las aplicaciones de sistemas basados en Windows que suceden en un entorno IT distribuido y compila estos eventos en un almacen central. El resultado es la administración de eventos distribuida. Los administradores pueden utilizar los eventos obtenidos como un resumen general de la disponibilidad de servidores y servicios. Dentro de MOM se pueden definir reglas. Las reglas desarrolladas de esta manera pueden utilizarse para hacer que el sistema responda automaticamente a flujos de entrada de datos. Esto se realiza en respuesta a un proceso predefinido basado en un escenario de error particular o bién para un evento especifico.

Estas reglas permiten a MOM el responder a ciertas pautas de eventos y desencadenar eventos o mensajes de alerta al administrador. Cada regla MOM puede ser configurada de tal manera que genera mensajes de advertencia especificos con diferentes niveles de seguridad aasignados a cada uno de los mensajes. Una adveertencia puede ser generada en respuesta a un evento único o multiples eventos originados en diferentes fuentes. En cualquier momento, un administrador puede seguir el desarrollo de advertencias o alertas y sus correspondientes eventos.Mas aún, las advertencias pueden desencadenar tanto mensajes de correo como paginas e interrupciones de SNMP (Simple Network Management Protocol). MOM posibilita la introducción de la monitorizacion de la ejecución de los sistemas conectados. Para este proposito, umbrales de ejecución, pueden ser definidos y monitorizados. El desarrollo de la ejecución del sistema y de la aplicación puede ser monitorizado adaptando o incluyendo reglas con el proposito de futuras referencias o bien para el planeamiento de la capacidad. Incluso se pueden determinar valores de umbrales locales y agregados que consecuentemente, conduzcan a cambios en la ejecución y así disparen mensajes de advertencia y eventos que requieran la intervención del administrador.

El portafolio de servicios a ser menejados puede expandirse por Management Packs. Management Packs contiene reglas MOM preconfiguradas. Cada paquete suministra reglas a ciertas aplicaciones o servicios. MOM incluye por defecto un Management Pack que puede ser utilizado para controlar los servicios de Windows mas relevantes, incluyendo el servicio de directorio activo y el Internet Information Services (IIS). Más Management Packs son ofrecidos por Microsoft y otros fabricantes.

Microsoft ofrece Management Packs para los siguientes productos:

Exchange 2000 y 5.5

SQL 2000 y 7.0

Commerce Server 2000

Internet Acceleration and Security Server 2000

Host Integration Server 2000

Application Center 2000

Site Server 3.0

Proxy 2.0

SNA 4.0

MOM posibilita que los datos obtenidos puedan ser procesados y presentados en forma de informes. Una herramienta grafica generadora de informes permite el acceso a diagramas e informes preconfigurados.Los informes generados permiten a los administradores comprobar el estado de los sistemas y de los servicios en la red. Se pueden añadir nuevos informes mediante la utilización de paquetes de gestión suministrados por Microsoft o por terceros. MOM permite, en particular, generar instantáneas basadas en HTML (Hypertext Markup Language, Lenguaje de Marcas de Hipertexto) de todos los informes desarrollados. Estos datos se pueden exportar a un servidor web para su posterior consulta desde un navegador de Internet.

Para su instalación se necesita Windows 2000 Server. Aunque se recomienda utilizar MS SQL Server 2000 como gestor de bases de datos, también se puede utilizar Access.

Application Center

Microsoft Application Center 2000 es una herramienta de distribución y gestión de aplicaciones web de alta disponibilidad creadas para el sistema operativo Microsoft Windows 2000 Server. Application Center 2000 simplifica la administración de grupos de servidores.

Servicios de Directorio.

Aspectos Generales.

Dado que un servicio de directorio no es una parte integral de Windows NT con respecto al punto de partida, la siguiente discusión no tratará la sustitución o la continuidad de un servicio de directorio ya existente. Sin embargo, el servicio de directorio juega un papel importante con respecto a la migración tanto por sustitución como de continuidad. La migración a Windows 2000 y especialmente la migración a Exchange 2000 casi de forma inevitable significa introducir el directorio activo. En el caso de la migración por sustitución, la utilización de un servicio de directorio utilizando en este caso OpenLDAP como una solución OSS, ofrece muchas ventajas, especialmente con vistas a la implementación de servicios de autenticación amigables.

Esto significa que las discusiones técnicas que se presentan a continuación se centrarán en mirar hacia el futuro, analizando las características especiales relativas a la introducción del respectivo servicio de directorio y/o sus posibles aplicaciones. Un aspecto especial es este contexto es el efecto integrador del directorio activo (AD, active directory).

De forma resumida se podría decir que el AD se debería implementar sólo en una configuración mínima, a menos que se pudiera evitar por completo. En situaciones con requisitos superiores se deberían utilizar otros productos y soluciones, como los metadirectorios.

Más aún, se debería seleccionar con cuidado el momento para transferir el directorio activo al modo nativo con el fin de mantener posibles opciones.

Aspectos Básicos

Un servicio de directorio se puede utilizar para tener disponible información de todo tipo a través de toda la red. Un servicio de directorio consiste en una base de datos en la cual se almacena la información y un protocolo de red que permite recuperar la información o su edición. Actualmente, el protocolo utilizado habitualmente es Lightweight Directory Access Protocol (LDAP). LDAP se elaboró inicialmente para permitir un acceso sencillo a los servicios de directorio basados en X-500. Actualmente un servidor LDAP se puede entender como la combinación de una base de datos y la implementación del protocolo. LDAP versión 3 se define en la RFC 2251.

Una característica típica de un servicio de directorio es la estructura jerárquica de la información que contiene, de forma similar a un sistema de ficheros. Partiendo de un punto raíz, la información se estructura en objetos, cada uno de los cuales tiene un determinado número de atributos en los cuales los valores representan la información real. Cada objeto puede tener subobjetos (con atributos) los cuales, a su vez, pueden tener otros subobjetos.

Los objetos de un servicio de directorio son unidades que se pueden discriminar de otros objetos, como por ejemplo individuos, grupos, ordenadores, impresoras o salas de conferencia dentro de un edificio. El objeto clases del objeto define qué atributos puede tener un objeto y que atributos debe tener un objeto. Una clase que aparece en muchos directorios tiene, por ejemplo, el nombre persona y establece que los objetos de esta clase deben, como mínimo, tener los atributos apellidos y nombre. También se permiten atributos opcionales, como númeroDeTeléfono y descripción. Las clases y los atributos se definen en el denominado esquema del directorio.

La posibilidad de asignar múltiples clases a objetos (incluso de forma retroactiva) conduce a un alto grado de flexibilidad y permite almacenar información coherente en el mismo lugar (por ejemplo en el mismo objeto). Una persona puede tener varias propiedades que forman un contexto coherente y que debe ser definido por diferentes clases (con atributos diferentes y superpuestos). Una persona, por ejemplo, se puede tratar como un usuario de un sistema de ordenadores, como una entrada en el directorio telefónico, como una entrada en la agenda de direcciones o como compañero de otra persona. Si almacenásemos estas propiedades en un directorio, las clases con atributos se deberían definir por la clase propiedad “usuario”, “entrada en el directorio telefónico”, “entrada en la agenda de direcciones” y “compañero”. Para permitir el uso con significado de alguna de estas clases incluso sin las otras clases, probablemente tendrían atributos que también aparecen en las otras clases requeridas, como el nombre de la persona. Sin embargo, cuando las clases se combinan con cada una de las otras, el atributo “nombre” se almacena una única vez.

La posibilidad de implementar estructuras de directorio jerárquicas se adopta normalmente para reflejar la estructura de una organización en el directorio. Con este fin, se utilizan normalmente objetos especiales. Estos objetos se utilizan para estructurar el directorio y se corresponden con unidades organizacionales reales o artificiales. Normalmente la clase utilizada es organizationalUnit (ou). Para conseguir una mayor claridad, el servicio de directorio se suele estructurar en línea con el espacio de nombres DNS que de todas formas existe en las organizaciones. La clase utilizada para ello es domainComponent (dc). En una aplicación práctica, la estructura base está en muchos casos orientada hacia el espacio de nombres DNS, estando la estructura detallada basada en unidades organizacionales o en otros objetos contenedores.

Consideremos el ejemplo de una organización con dos sedes (Oeste y Este). La organización usa el dominio DNS empresa.es y los subdominios oeste.empresa.es y este.empresa.es para ambas sedes.

La organización puede utilizar el objeto empresa.es como la raíz de su directorio. En LDAP, este objeto se denominará dc=empresa.es para dejar claro que la raíz es un objeto de tipo domain component (domainComponent, dc) con el nombre empresa que es un subobjeto del objeto es, que también es del tipo domain component.

Este punto base podría contener otros dos objetos nombrados como dc=oeste y dc=este (similares a los nombres DNS para esas sedes). También nos referimos a estos nombres como nombres relativos de los objetos, debido a que indican de forma ambigua dónde se encuentran en la jerarquía del directorio. El uso de nombres cualificados es una alternativa que sí identifica el lugar exacto de la ocurrencia de los objetos en el directorio. Los nombres serían por tanto dc=oeste,dc=empresa,dc=es y dc=este,dc=empresa,dc=es.

Más aún, supongamos que la organización tiene tres unidades organizativas en cada una de las dos sedes, identificadas como “Producción”, “Ventas” y “Gestión”. Esto significa que para la unidad organizacional “Producción” en la sede Oeste y con vistas a la presentación en este directorio, el objeto ou=producción se crearía como un subobjeto de dc=oeste (nombre cualificado: ou=producción,dc=oeste,dc=empresa,dc=es). Se debería adoptar el mismo procedimiento para las demás unidades en esta y en otras sedes. Los objetos para personas, grupos de personas así como para los ordenadores, se deberían crear dentro de la unidad organizativa “Producción”. Para conseguir una estructura clara, estos objetos se pueden organizar en contenedores (normalmente refiriéndose a ellos con nombres o commonName, cn) con los nombres cn=individuo, cn=grupo, cn=dispositivo. Por último, se generarían las entradas para los objetos reales dentro de estos contenedores. Por ejemplo, se podría crear el siguiente objeto para el empleado “Juan Español”, que trabaja en “Producción” en la sede “Oeste” en el contenedor ch=individuo, ou=producción, dc=Oeste, dc=empresa,dc=es. Por lo tanto, el nombre de este objeto sería: cn=español, cd=individuo, ou=producción, dc=oeste, dc=empresa, dc=es.

Esta claro que este servicio de directorio solamente tendría sentido si se utiliza en todas las aplicaciones posibles, cuantas más mejor. Idealmente, el servicio de directorio es la única fuente de información almacenada en la red. Por ejemplo, si la red de una organización incluye servidores Windows y Unix, una aplicación de intranet y un web proxy con autenticación, las cuentas y los privilegios del usuario relativos a los diferentes sistemas, se pueden configurar de forma separada en cada uno de los sistemas. La introducción de un servicio de directorio permitiría almacenar únicamente las cuentas de usuario y sus privilegios en el servicio de directorio central. Todos los sistemas accederían a este servicio de directorio. Al mismo tiempo las agendas electrónicas que se incluyen por ejemplo en los programas de correo electrónico, podrían acceder a este directorio y así proporcionar las direcciones de correo de los miembros de la organización sin necesidad de grabar los datos manualmente una vez más.

Los servicios de directorio también se pueden utilizar para almacenar las claves (las claves son habitualmente un atributo de un objeto persona o cuenta de usuario). También permiten almacenar y gestionar centralizadamente los datos.

Las contraseñas que se almacenan en este directorio deben ser creados y modificados en un punto simple del sistema, pero pueden ser usados en todos los sistemas y por todas las aplicaciones que puedan hacer uso del directorio para autenticación. Es más, las contraseñas almacenadas en el directorio pueden ser usadas para autenticación de acceso a los datos contenidos en el mismo directorio.

El ejemplo de almacenamiento de contraseñas demuestra que un sistema que un sistema de privilegios de mucha precisión (de 'grano fino') debe ser el elegido en orden a controlar el acceso al servicio de directorio y a definir que objetos y atributos pueden ser leídos o modificados y por que usuarios. Por ejemplo es de sentido común que las contraseñas pueden ser cambiadas por sus dueños y por los administradores. Es más, sus dueños deben poder hacer uso de ellas para autenticación. Por contra, ningún otro que pueda acceder al directorio debe ser capaz de leer las contraseñas en absoluto, incluso en el caso de que estas contraseñas estén almacenados en el directorio de forma encriptada. Al mismo tiempo sin embargo, otros usuarios pueden ser autorizados a leer la dirección de correo electrónico de 'objetos' usuarios. En un caso así atributos diferentes (contraseña y dirección de email) del mismo objeto (persona o usuario) deben tener privilegios diferentes. Esta es la razón por la que la mayoría de los servicios de directorio implementan un sistema de Listas de Control de Acceso (ACLs) que pueden ser comparables a las ACLs a nivel de sistemas de ficheros.

A pesar de la práctica común de usar los servcios de directorio para autentticar servicios, esto debe ser considerado como una estrategia cuestionable. Este concepto no permite un método seguro para implementar una función de inscripción ('sign-on') porque todos los sistemas y aplicaciones requieren la autenticación repetidamente (aunque con la misma contraseña). Hay que tener en cuenta que la mayoría de los servicios de directorio no fueron escritos con la idea de suministrar un mecanismo de autenticación seguro, sino como un medio de almacenamiento centralizado de información que se necesita frecuentemente y debe ser distribuida con rapidez a los clientes. Nosotros recomendamos en su lugar el uso de Kerberos.

Usando Kerberos, los nombres de usuario y sus contraseñas no son, de forma opuesta al procedimiento estándar, enviados a cada servidor cuyos servicios son requeridos por un usuario. Esto se remplaza por un registro único por medio de un centro de distribución de claves (Key Distribution Centre, KDC, a veces referido como controlador de dominios Kerberos, Kerberos Domain Controller). A continuación del registro el usuario recibe una 'entrada' (ticket) que es emitida en unas condiciones definidas y que el usuario puede utilizar al objeto de autenticarse en relación al resto de servicios. A partir de que expire la validez de la 'entrada' el usuario debe reautenticarse a si mismo. El uso de kerberos implica que el repositorio de contraseñas debe existir únicamente en un sistema particularmente confiable (p.ej. en un servidor Kerberos). El resto de sistemas no necesitan acceder al repositorio de contraseñas. Las 'entradas' Kerberos pueden utilizarse también para implementar una funcionalidad simple de inscripción -sign-on- ya que las 'entradas' pueden utilizarse para acceder a todos los servicios que estén disponibles en la red (con la condición de que las correspondientes aplicaciones soporten Kerberos).

Una vez que un servicio de directorio se convierte en la base de datos de información principal de una organización, se constituye como un componente de particular importancia de la red, que debe estar caracterizado por un alto grado de disponibilidad. Esta es la razón por la que los servicios de directorio típicamente soportan métodos de replicación que pueden ser utilizados para transferir los directorios completos y sus cambios de un servidor con servicio de directorio a otros servidores. Esta es la razón también de que se ofrezcan habitualmente opciones de balanceo de carga, ya que no todos los clientes deben acceder al mismo servidor de directorio.

Perdón por el retraso. Los exámenes... Esta traducción es del documento german_migration_guide.pdf página 113

Existen dos métodos de réplica, i.e. réplica maestro-esclavo y réplica multi maestro. El método maestro-esclavo significa que los cambios solo pueden ser hechos en un servidor maestro centralizado del directorio el cual copia los cambios a los otros (esclavos). De esta manera los cambios en el directorio contiene el cuello de botella porque estos cambios pueden ser hechos solamente en el servidor central. En el caso de fallo del servidor maestro, los cambios no pueden ser realizados hasta que el sistema se reconfigure y otro servidor realice el trabajo de servidor que estaba haciendo el servidor caido, restaurandose la actividad normal. La réplica multi-master permite cambios en los contenidos de los múltiples servidores, por lo tanto el problema comentado no existe. Por consiguiente, los problemas de consintencia pueden ocurrir en el caso que la granja de servidores hagan cambios críticos al mismo tiempo.

Active directory service (ADS)

Esta sección está destinada a dar una visión general de la tecnología "Active Directory Service". Las siguientes funcionalidades son llamadas:

Directory Service

LDAP

Kerberos

Group guidelines

Delegation

Certificate management

Además esta sección también describe

la aplicación

la arquitectura

la estrategia relevante

Finalmente, las diferencais entre la mínima y máxima configuración de un directorio activo será discutido

Sucesor del servidor Windows NT 4

Con respeto hacia el servidor Windows NT, el directorio activo (AD) puede compararse con el del servidor sucesor.

Esto es así por el hecho en que la rutina de instalación de Windows 2000 como la de Windows NT PDC nos dan una pista sobre el directorio activo. Sin embargo, no sería correcto en este punto decir que la implantación del directorio activo meramente consiste en la llamada de una rutina de instalación en un único servidor. La implantación de un AD requiere un meticuloso y cuidadoso plan de migración.

Decripción Técnica de los Caminos de Migración

La tecnologia de base de los servicios de acceso de usuarios en active directory,posee la misma estructura que Windows NT. El dominio sigue siendo la unidad administrativa que combina las cuentas del ordenador y el usuario a traves de una base de datos compartida en un contexto seguro.Los limites de seguridad del dominio son los contextos de seguridad y la replicacion de la base de datos.

NetBios continua existiendo.Por otra parte, se incluyen todos aquellos ordenadores basados en :

Window NT

Windows 2000

Windows XP

pueden ser miembros de dominio.

Si los sistemas como Windows NT y 9x seran soportados, es necesario asegurarse la ausencia de resolucion de nombres a través de NetBIOS. (como WINS, por ejemplo).

La implementacion de un active directory, es una condicion caracterisitca que en trae el cambio de arquitectura.Por este motivo, una infraestructura de DNS es indispensable, no solo la seleccion de un espacionombre, sino tambien el uso de servidores DNS configurables. Esto implica, por lógica un entorno de red basado en TCP/IP. El planeamiento del proceso de migración y seleccion de posibles escenarios son descriptos en las siguientes secciones.

3.7.3.2 El mecanismo de autenticacion Kerberos

El active directory de Windows 2000 sigue soportando el mecanismo de autenticacion NTLM. Esto es necesario por varias razones, por ejemplo, la simplicidad para validar la registracion de sistemas

como Windows NT o 9x.

La autenticacion mediante Kerberos es una nueva característica.

Sistemas como Windows 2000 o XP, usan en primera instancia los Kerberos por defecto. De todas maneras ingresar a través de NTLM es necesario. Sistemas como Windows NT o 9x, no pueden ser acondicionados para soportar Kerberos. Los controladores de dominio (DC) de Windows 2000 se comunican via Kerberos. En Windows 2000, La version 5 de Kerberos ha sido implementadas con agregados para la autenticacion de llaves publicas. La implementacion sigue las especificaciones provistas en RFCs 1510 y 1964.

El centro de distribucion de llaves kerberos (KDC), es integrado en cada controlador de dominio (DC) del active directory, y utiliza su base datos de usuarios.Kerberos requiere los tiempos de sistema de las computadoras en cuestion, solo para someter a prueba cualquier desviacion.Para asegurarse de esto, un tiempo jerarquico de reconociliacion ha sido implementado en Windows 2000 para las computadoras que son miembro del AD. Kerberos debe ser visto con ciertas reservaciones si NAT (Traslacion de Direcciones de Red) es usado, a causa de la carga de paquetes IP encriptados que contengan direcciones IP.

Kerberos es mas flexible y mas eficiente que NTLM. En el caso de NTLM, un servidor de aplicaciones debe siempre contactar al controlador de dominio para autenticar al cliente. En el caso de Kerberos, el servidor de aplicaciones puede chequear la informacion de validacion de usuario, con los clientes presentes a este.Bajo NTLM, los servidores pueden chequear la identidad en el servidor (autenticacion mutua).Windows debe despersonalizar el cliente para que acceda a los recursos. NTLM y Kerberos pueden proveer el servicio con la informacion necesario para hacer impersonal al cliente localmente. A NTLM le es imposible manejar de forma distribuida el FrontEND y el BackEnd ubicados en distintas computadoras, mientras que Kerberos ofrece ofrece un mecanismo proxy (autenticacion delegada). Kerberos puede generar operaciones determinadas, transitivas,bidireccionales seguras entre dominios.

El protocolo Kerberos esta formado por tres subprotocolos. El protocolo por el cual el Centro de Distribucion de Llaves (KDC),otorga al cliente en el momento de la sesion una llave,ademas de un TGT (Un comprobante de acceso seguro), llama al servicio de Autenticacion de Intercambio (AS Exchange). El subprotocolo, que utiliza KDC para asegurar la llave de sesion mas un comprobante por el servicio es llamado Servicio de Comprobante-Seguro (TGS Exchange).El subprotocolo por el el cliente envia el comprobante para acceder al servicio es llamado Servicio Cliente/Servidor (CS Exchange).

3.7.3.3 Nuevas caracterisitcas concernientes a la estructura.

Como se ha mencionado, la estructura de las unidades de dominio, siguen existiendo aun en active directory.En el active directory, el dominoio debe ser tomado por parte de una estructura completa (bosque) y los respectivos arboloes estructurales (arbol), con una estructura jerarquiza en un espacio de nombre DNS.Los dominios individuales, esta conectados unos con otros en forma birideccional, Kerbneros Transitivo Seguro (Comunicacion Segura). (Las comunicaciones seguras a traves de NTLM, conocidas desde Windows NT, pueden seguir siendo usadas).Si nos referimos al active directory, mas bien indica al bosque que a arboles individuales o dominios.La ilustracion debajo (Figura 10) muestra una estructura de dominio en Windows NT, en la cual dos cuentas de dominio y cinco dominios de recursos estan conectados unos con otros mediante comunicacion segura.Microsoft presenta los dominios de Windows 2000 como triangulos, los dominios basados en Windows NT como elipses. Este cambio es adoptado para el propósito de esta guia. La siguiente figura lo muestra:

Figura 10: Ejemplo de una estructura de dominios NT

En active directory, el bosque mostrado debajo (Figura 10) podria ser concebible y consistente de siete dominios. Los bosques consisten en dos arboles en los cuales los dominios tienen una estructura jerarquiza, y donde estos ultimos estan conectados unos con otros a traves de Kerberos, ambos de manera transitiva (A asegura B y B asegura C, por ende A tambien asegura C) de una manera bidireccional. (A asegura B, por ende B asegura A).

El active directory, se hace disponible a traves de controladores de dominio (DCs). Las distinciones entre PDC y BDC ha sido descontinuada. Esto refleja la nueva caracteristica de arquitectura, por ejemplo los controladores de dominio de Windows 2000 estan sujesto a un principio multi-maestro: La mayoria de los cambios aplicados en AD, pueden ser portados (escritos) por cualquier Controlador de dominio.El principio multi-maestro no puede ser aplicados a todos los cambios. Propietarios de controladores de dominio especiales, llamados FSCMO ,(Operacion Maestra unica y Flexible), existen para este proposito

Estos FSCMO pueden ser:

-Emulador de PDC

-Maestro de Infraestructura

Maestro de RID

Maestro de Esquema

Maestro de nombrado del Dominio.

Estas funciones se pueden colocar en controladores de dominio escogidos específicamente.

Las siguientes funciones:

Maestro de Esquema (responsable del esquema del directorio)

Maestro de nombrado del Dominio (responsable en caso de cambios en el espacio de nombres)

son roles únicos dentro de la estructura completa (bosque).

Las siguientes funciones:

Emulador de PDC

Maestro de Infraestructura (responsable de actualizaciones de SIDs y de nombres cualificados que crucen límites de dominios)

Maestro de RID (responsable de la concesión de fondos de RID a otros DCs)

son únicas en cada dominio.

El emulador de PDC es responsable de funciones importantes, tales como:

Actualización de contraseñas para clientes de nivel inferior (NT 4.0, 9x) y asociados de los controladores de dominio de respaldo de Windows NT

Generador de la hora de la red (PDC del dominio maestro únicamente)

Servicio de visualización del dominio maestro (NetBIOS)

Un bosque adicionalmente se puede estructurar por sitios. Los tamaños pueden (o mejor dicho, deberían) reflejar la estructura física de red y corresponder a los anchos de banda disponibles entre los lugares (Hamburgo, Berlín, Bonn, etc.). El propósito primario de esta organización estructural es controlar los procesos de replicación entre controladores de dominio.

La topología del sitio elegida puede ser independiente de la estructura de dominio. La ilustración inferior (Figura 12) muestra un ejemplo de topología.

La tan nombrada estructura OU (OU aceptada como unidad organizacional) es una nueva característica estructural descrita en la sección relacionandonos con el servicio de directorio.

3.7.3.4 DNS espacio de nombres e infraestructura

Una infraestructura de DNS es indispensable para el servicio de directorio activo de Windows 2000. Las siguientes preguntas se deben contestar en este contexto.

¿Qué espacio de nombres DNS debe asignarse al DA (Directorio Activo)

¿Cómo se ha de insertar este espacio de nombres en el DNS existente?

¿Quien administra el espacio de nombres existente?

¿Sobre qué plataforma (sistema operativo: Windows 2000, UNIX) estará disponible el DNS?

¿Qué relación con la NetBIOS del espacio de nombres debe considerarse?

Responder a estas preguntas es con fecuencia bastante difícil, no sólo por razones tecnicas, sino también por razones políticas.

Selecionando la plataforma

La infraestructura DNS para un DA debe caracterizarse por ciertas propiedades, para asegurar claridad en la resolución de nombres y el registro de entradas.

Windows 2000 con su propia implementación de DNS generalmente satisface todos estos requerimientos. Las características del DNS de Windows 2000 incluyen, por ejemplo:

Servicio de gravaciones(RFC 2052)

DNS Dinámico(RFC 2136)

Actualización dinámica segura

Método multi-master gracias a su integración dentro del directorio activo

Integración de WINS

El soporte de RFC 2052 es obligado porque es el único camino de entrada de servicio que puede hacerse en el DNS. El RFC 2052 es soportado por servidores basados en UNIX desde BIND 8.1.2 en adelante. El BIND 8.2.1 ofrece nuevas características y es una versión recomendada.

Espacio de nombres NetBIOS

Los siguientes aspectos deben considerarse con respecto a nombres NetBIOS

El nombre NetBIOS de un dominio Windows 2000 (tal que RES1) puede, en principio, desviarse del nombre más bajo del sufijo DNS (tal que RES001 de res001.behoerde.de). El uso de este sistema de nombres es, sin embargo, generalmente no recomendado.

El espacio de nombres NETBIOS no tiene ningún grado de libertad especialmente en casos donde existen dominios NT que serán actualizados (ver "Migración en el sitio").

Espacio de nombres DNS

La siguiente discusión se basada en la aceptación de que ya existe un entorno DNS en la infraestructura y que éste está disponible en un servidor Unix. Este es un punto de partida relativamente generalizado. Se supone que el nombre del dominio es "BEHOERDE.DE" y que existe el espacio de nombres BEHOERDE.DE se usa sólo internamente. Además, se supone que existe un “punto” dominio raíz interno o que existe una zona en la infraestructura DNS. En la siguiente ilustración se mestra la situación de partida (Figura 13).

Figura 13: Situación de partida

El siguiente paragrafo trata de las posibles soluciones para crear un espacio de nombres con una visión de Directorio Activo de Windows 2000.

Esto ilustra la complejidad de una migración hacia la estructura de Directorio Activo y el compromiso y dependencia a largo plazo de éste. Dominio Maestro: W2K.BEHOERDE.DE

Existe un espacio de nombres DNS interno usado para recibir otro subdominio W2K (como dominio master = primer dominio de Directorio Activo).

Figura 14: Dominio Master: W2K.BEHOERDE.DE

El dominio master ofrece las siguientes ventajas:

No se crea un árbol de nombres nuevo.

Permanecen sin cambio los servidores raíz existentes.

Cualquier plataforma puede ser seccionada por el servicio DNS.

Los espacios de nombres externos e internos permanecen separados por cada uno.

Los inconvenientes a ésta solución son los siguientes:

El Nname del usuario principal es relativamente largo (Benutzername @w2k.behoerde.de) o incluye un 2º nivel de domino.

Si el bosque aumenta (p.e. añadimos al árbol DNS ZUSATZ.DE), uno de los árboles no tendrá un dominio de nivel 2 (tecnicamente no es un problema)

Parte de la resolución del nombre es dependiente de la infraestructura legal.

Dominio Master: BEHOERDE.DE

El espacio de nombres DNS existente es usado para determinar el nombre del dominio master.

Figura 15: Dominio Maestro: BEHOERDE.DE

Este dominio Maestro ofrece las siguientes ventajas:

Los servidores raíz existentes permanecen sin cambios

No se crea ningún árbol de nombres nuevo

El nombre principal del usuario es relativamente corto (Benutzername@behoerde.de)

Si se incrementa el bosque (ej. añadiendo el árbol de DNS ZUSATZ.DE), ambos árboles serán dominios de segundo nivel

Los espacios de nombres internos y externos permanecen separados uno del otro.

Las desventajas de esta solución son las siguientes:

No se puede seleccionar la plataforma para los servicios de DNS

La resolución de nombres depende exclusivamente de la infraestructura heredada.

Dominio Maestro (NEU.DE)

Este enfoque es independiente del espacio de nombres heredado y crea un nuevo árbol de nombres DNS interno. Este nombre elegido, NEU.DE, es único en el mundo y está por tanto registrado oficialmente.

Descripción técnica de las rutas de migración

Este dominio maestro ofrece las siguientes ventajas:

Es creado un nuevo nombre de árbol, por lo que no se heredan cargas históricas.

Los servidores raíz existentes pueden permanecer inalterados.

La plataforma para el servicio de DNS puede ser seleccionada.

El nombre principal del usuario es relativamente corto Benutzername@neu.de)

Si se incrementa la foresta (e.j. más árbol DNS ZUSATZ.DE), ambos árboles son dominio de 2º nivel.

La resolución de nombres es apenas dependiente del legado de la infraestructura.

Los espacios de nombres interno y externo pueden permanecer separados, dependiendo de requerimientos futuros.

Las desventajas de esta solución son la siguientes:

Se crea un nuevo nombre de árbol, por lo que se generan nuevas estructuras y líneas guías adicionales.

Se incremneta la complejidad con relación al DNS y por lo tanto el esfuerzo administrativo.

Dominio maestro y estructura: NEU.DE/ INTRA.NEU.DE

Este acercamiento es independiente del espacio de nombres legado y crea	un nuevo nombre de árbol DNS. Se crea un nuevo subdominio adicional añadido al dominio de 2º nivel NEU.DE.

El dominio de 2º nivel NEU.DE sirve exclusivamente como dominio maestro de la foresta, como la tan mencionada estructura de dominio. Las cuentas de usuario sólo se crean en el INTRA subdominio.APÉNDICE

Figura 17: Maestro y dominio estructurado: NEU.DE/ INTRA.NEU.DE

Los dominios estructurados ofrecen las siguientes ventajas:

Un nuevo nombre en el árbol es creado, así que antiguas cargas no son heredadas.

Los servidores root pueden permanecer sin cambios.

La plataforma para los servicios DNS puede ser elegida.

Si el árbol se hace crecer (e.j. plus DNS arbol ZUSATZ.DE), ambos arboles son dominios de segundo nivel.

Si el número de dominios es aumentado, el nuevo dominio puede ser instalado paralelo al dominio INTRA.

La resolución de nombres apenas depende de la estructura.

Los espacios de nombres internos y externos pueden permanecer separados, dependiendo de los requerimientos.

Las desventajas de esta solución son las siguientes:

Dos dominios son instalados en el directorio activo.

Cuando un nuevo nombre de árbol es creado, también las nuevas estructuras y añadidos son generados.

El nombre de usuario principal es relativamente largo (Benutzername @intra.neu.de).

El número de conexiones cruzadas crece, y así, su complejidad y esfuerzo de administrar.

Dominio Maestro: INTRA.BEHOERDE-ONLINE.DE

Un espacio de nombres DNS externo es usado para recibir otro dominio. El espacio de nombre existente BEHOERDE-ONLINE.DE ha sido usado solamente para propósitos externos. Un dominio INTRA debe ser crado para uso interno solamente.

Este dominio maestro ofrece las siguientes ventajas:

Se crea una nueva rama interna, por lo que no se heredan registros históricos.

Los servidores raíces existentes, permanecen sin cambios.

Se puede selecionar la plataforma para los servicios DNS.

Si se incrementan los árboles de directorios( ej. un nuevo árbol de DNS ZUSATZ.DE), ambos árboles son de dominio de 2º nivel.

La resolución de nombres es muy dependiente de la infraestructura legada.

Las desventajas de esta solución son las siguientes:

El nombre principal del usuario es relativamente largo (Benutzername@intra.behoerde-online.de)

Se crea un nuevo nombre de árbol interno, por lo que se generan nuevas estructuras y líneas guías adicionales.

El número de conecciones cruzadas se incrementa, y por tanto la complejidad y el esfuerzo administrativo.

Los espacios de nombres interno y externo, ya no dependen el uno del otro.

Dominio maestro: AMT.LOCAL

Este planteamiento es independiente del nombre de espacio legado y se	crea un nuevo nombre de árbol DNS interno. El dominio de máximo nivel	LOCAL seleccionado, en estos momentos no está soportado en Internet.	Por lo que	no es posible, el registro oficial del nombre del mismo. Sería	posible usar un nombre de dominio de máximo nivel, protegido bajo el RFC	2606, en lugar de LOCAL, lo cual nunca está en riesgo de ser utilizado	como dominio de máximo nivel por la comunidad internauta.

Pagina 125-

[Figura 19]

Este dominio maestro ofrece las siguientes ventajas.

Un nuevo arbol es creado, por lo que no se heredan las complicaciones históricas.

Los servidores raiz existentes pueden quedar sin cambios.

La plataforma por los servicios DNS pueden elegirse.

El nombre principal del usuario es relativamente corto (username@amt.local).

Si el bosque crece (por ejemplo, agregando en arbol DNS zusatz.de) ambos arboles son dominios de segundo nivel.

La resolución de nombres es dificilmente dependiente en la infraestructura heredada (preexistente)

Las desventajas de esta solución son las siguientes:

Un nuevo arbol es creado, por lo que se generan nuevas estructuras e indicaciones adicionales.

Los espacios de nombres (namespaces) internos y externos permanecen separados uno del otro de forma permanente.

El número de conexiones cruzadas aumenta y por lo tanto tambien aumenta la complejidad y el esfuerzo de administración.

Importante

La selección de espacio de nombres DNS se vuelve mucho más dificil si la administración soberana del espacio de nombres DNS esta fuera de los propios privilegios soberanos. Entonces es frecuentemente necesario subordinar los propios intereses a unos intereses de más alto nivel que pueden volver significativamente más prolongado al proceso de toma de decisiones.

3.7.3.5 Servicio de directorio y esquema

Con el directorio activo de Windows 2000, se introdujo un servicio de directorio orientado hacia el estándar X.500 y que podía ser administrado via LDAP (Lightweight Directory Access Protocol - Protocolo Liviano de Acceso a Directorio).

Se usara un servidor DNS externo para consultar otros dominios. El nombre existente BEHOERDE-ONLINE.DE ha sido usado hasta ahora para propósitos externos. Debe de crearse un dominio INTRA solo para usos internos.

<IMAGEN>

El dominio principal ofrece las siguientes ventajas:

-Se crea una nueva rama de nombres, así que no se heredan cargas anteriores

-Los servidores raíz permanecen sin cambios

-Puede ser seleccionada la plataforma para los servicios de DNS

-Si la ramificación aumenta (p.e. Nuevo árbol DNS de ZUSATZ.DE) ambos arboles son dominios de 2º nivel.

-La resolución de nombres es fuertemente dependiente de la infraestructura existente.

Las desventajas de esta solución son las siguientes:

-El nombre principal del usuario es relativamente largo (usuario@intra.beoherde-online.de)

-Se genera una nueva rama de nombres interna, así que se crean nuevas estructuras y nuevas guias de uso.

-El numero de conexiones cruzadas aumenta y con ello también la complejidad y el esfuerzo de administración.

-Los espacios de nombres internos y externos no son independientes unos de otros.

Dominio principal: AMT.LOCAL

Este asunto es independiente del actual espacio de nombres y crea una nueva rama interna de DNS.

El dominio de mas alto nivel seleccionado no está soportado en Internet

y el registro oficial del nombre elegido no es posible.

En lugar de LOCAL seria posible usar un dominio de alto nivel especificado bajo el RFC2606 que nunca tendrá riesgo de ser usado como dominio de alto nivel en Internet.

<IMAGEN>

Este dominio principal ofrece las siguientes ventajas:

-Se crea un nuevo árbol de direcciones así que no se heredan cargas anteriores

-Los servidores raíz existentes permanecen sin cambios

-Puede ser seleccionada la plataforma de DNS

-El nombre de usuario principal es relativamente corto (usuario@amt.local)

Las desventajas son las siguientes:

-Se genera una nueva rama de nombres interna, así que se crean nuevas estructuras y nuevas guias de uso.

-Los espacios de nombres internos y externos quedan permanentemente separados unos de otros.

-El numero de conexiones cruzadas aumenta y con ello también la complejidad y el esfuerzo de administración.

IMPORTANTE:

La selección del espacio DNS se hace mas mucho más complicada si la administración del DNS esta fuera de los propios privilegios máximos de administración. Si esto pasa es a menudo necesario subordinar los propios...La distribución y/o activación de la ICP (infraestructura de clave pública) está soportada por políticas de grupo. Sin embargo, esto no significa que un concepto separado de administración para claves sea entonces superfluo.

3.7.3.9 Smart Card

El establecimiento de una ICP interna hace posible la autentificación de usuarios por medio de una tarjeta Smart-Card. La entrada por medio de Smart-Cards a ordenadores Windows 2000/XP puede llevarse a cabo sin necesidad de software adicional.

3.7.4 Reemplazando la migración – Samba y OpenLDAP

3.7.4.1 Requisitos funcionales

El requisito clave para un servicio de directorio es asegurar la diseminación rápida de información en la red. Además de esto, el servicio de directorio debería ofrecer las siguientes funciones:

Posibilidad de cambiar la información disponible en el directorio.

Posibilidad de dotar a los objetos en el directorio de una estructura jerárquica.

Uso de esquemas comunes y que se adapten a los estándares para asegurar un alto grado de compatibilidad con el mayor número posible de aplicaciones. Posibilidad de añadir objetos y esquemas propios.

Posibilidad de autentificar usuarios, así como integración con otros servicios de autentificación (Kerberos).

Administración de derechos de acceso.

Uso de estándares abiertos para conseguir un alto grado de compatibilidad, si es posible, con todos los servicios y aplicaciones que puedan hacer uso de la información almacenada en el directorio.

Soporte de procesos y técnicas de replicación.

Uso de protocolos de transmisión seguros para la transmisión de información entre el cliente y el servicio de directorio y durante la replicación.

3.7.4.2 Productos comparados

Si un dominio Windows-NT se va a reemplazar por un servicio de directorio basado en Microsoft Windows o Linux, los siguientes productos son las primeras opciones para elegir:

Directorio activo con Windows 2000/ 2003 Server.

OpenLDAP y Samba (opcionalmente con Kerberos) bajo Linux.

Otros servicios de directorio, como Novell Directory Services o SunONE, no se comentan más en profundidad en este contexto porque requieren la introducción de productos adicionales, incrementando aún más la complejidad de los entornos IT basados en Windows o basados en Linux.

3.7.4.3 Comparación general de las funcionalidades de NTDS, directorio activo y OpenLDAP

Tabla 15. Comparación de servicios de directorio

Función:

Cliente sin software adicional

Posibilidad de implementar una estructura jerárquica del directorio.

Expandibilidad añadiendo atributos y clases de objetos propios.

Conjunto de caracteres para los datos del directorio.

Posibilidad de acceder al directorio mediante un protocolo estandar (LDAP)

Acceso seguro por LDAP mediante SSL/TLS

Soporte del protocolo “starttls”

Soporte para SASL

Autentificación de clientes NT

Autentificación de clientes W2K

Autentificación de clientes Linux

Posibilidad de integrar Kerberos

Posibilidad de usar un servicio Kerberos independiente o de alto nivel

Administración de privilegios de acceso (ACLs) para atributos y objetos

Delegación de tareas administrativas

Replicación maestro/esclavo

Replicación multi-maestro

Nota 45: Si se utiliza Samba para la autentificación de clientes Windows en relación a OpenLDAP, se utiliza el protocolo NT LAN Manager entre el cliente Windows y el servidor Samba.

Nota 46: Si se utiliza Samba para la autentificación de clientes Windows en relación a OpenLDAP, se utiliza el protocolo NT LAN Manager entre el cliente Windows y el servidor Samba.

Nota 47: Kerberos está firmemente integrado en el directorio activo.

Nota 48: Aunque el directorio activo permite la autentificación en relación a un servidor Kerberos externo, entonces ya no es posible usar dominios de directorio activo para la autentificación de ordenadores basados en Windows 95/98/Me/NT.

Nota 49: El directorio activo utiliza replicación maestro/esclavo entre Windows 2000 DC y Windows NT 4 BDC en “modo mixto”.

Nota 50: El directorio activo utiliza replicación multi-maestro en “modo nativo” (en el que se utilizan exclusivamente controladores de dominio basados en Windows 2000/2003).

Nota 51: La replicación multi-maestro en OpenLDAP se considera experimental, y no está activada por omisión.

3.7.4.4 Identificación con Linux / OpenLDAP y Samba

Las fuentes de "identificación" y el "directorio de servicio" pueden estar escasamente separados. De cualquier modo, desde un directorio de servicio puedes siempre llevar a cabo más tareas que la del sevicio de identificación, y desde la identificación es una infraestructura de servicios, el proceso de identificación en la interacción de Linux, Samba y OpenLDAP y tambien en la interación con Windows y ADS que fue explicado en el capítulo 3.4 "Servicios de identificación".

3.7.4.5 Administración central de la información del host con Linux and OpenLDAP

La administración central de la información del host en un directorio facilita la simplificación significativa de inevitables tareas administrativas. Estas tares incluyen:

Inventariado del hardware existente

Creación y administración de los nombres de las entradas DNS

Creación y administración de las configuraciones DHCP

Para los clientes de Windows, las cuentas de las máquinas pueden ser almacenadas junto a la información mencionada.

Además, no es necesario más tiempo para distribuir tales informaciones a otros ordenadores manualmente o por otros procesos porque esta información puede ser distribuida por los sistemas con una copia de la LDAP.

Linux ofrece variedad de programas que pueden ser usados para exportar la información del host directamente un directorio LDAP.

Un patch que habilita la configuración DHCP para sr exportada desde un directorio LDAP existente para el servidor estandar DHCP (ISC DHCPD).

http://home.ntelos.net/~masneyb/dhcp-3.0.1rc11-ldap-patch

Un patch que sustituye archivos locales con LDAP tambien existentes para BIND 9. http://www.venaas.no/dns/bind/bind-sdb/

Samba puede importar información concerning machine accounts directamente del directorio LDAP.

Además, una completa gama de software libre y propietario está disponible, permitiendo la generación transparente del BIND y la configuración DHCP del directorio de la LDAP.

3.7.4.6 Integración de otras aplicaciones

Además del uso del directorio de servicios para el almacenamiento central de usuario, grupo y la información del host , los beneficios de las aplicaciones aumentan con el aumento de otras tantas aplicaciones como sea posible. Una lista completa de aplicaciones compatibles con LDAP no puede ser dada en este punto. Es, de cualquier modo, importante apuntar que más y más aplicaciones soportan LDAP, no solo Outlook y Outlook Express o el paquete OpenOffice. Estas aplicaciones pueden trabajar con ambos OpenLDAP y directorio activo como directorio de servicio.3.7.4.7	Herramientas de administración

Linux ofrece herramientas de administración bajo el estandar LDAP (ldapsearch, ldapadd, ldapmodify) para la iformación guardada en un directorio. Estas herramientas son usadas primordialmente para inicializar un directorio, importar datos, navegar por directorios y la edición automática de un directorio. También están disponibles algunas herramientas basadas en línea de comandos para la administración de usuarios y grupos.

Hay actualmente en desarrollo herramientas gráficas libres para la administración de usuarios y grupos basados en directorios (por ejemplo, el administrador de directorios: http://diradmin.open-it.org/files.php).

Herramientas basadad en la web para la administración de usuarios, grupos y cuentas de máquinas y otros objetos (listas de correo, entradas DNS, etc.) dentro del alcance de los servicios de directorio son igualmente importantes y mucho más flexibles. La ventaja de estas soluciones es que pueden ser usadas con un navegador web independiente del servidor, con la posibilidad de usar transmisión segura de datos (SSL/TLS).

3.7.4.8	Comportamiento en ejecución y consumo de recursos

Linux y OpenLDAP han sido encontrados estables y suficientemente operativos en entornos muy grandes con más de 10.000 usuarios. Samba ha sido encontrado seguro y – comparado con servidores basados en Windows – también se ha encontrado que realiza un consumo menor de recursos en multitud de pruebas y en grandes instalaciones.

3.7.4.9	Aceptación por parte de los usuarios

Los servicios de directorios son inicialmente invisibles para usuarios finales y solo se vuelven apreciables cuando las aplicaciones son enlazadas al directorio. Cuantas más aplicaciones usen el directorio, mayor será la probabilidad de que los usuarios sean confrontados con datos consistentes incrementando así su aceptación.

La migración a la combinación Samba/OpenLDAP puede tener lugar de una forma transparente para usuarios y clientes, por lo que no se verán afectados por el proceso de migración o por cualquier cambio resultante.

Un servicio de directorios beneficia a los administradores con la introducción de un único punto de administración. Este único punto de administración puede ser usado mejor cuanto mejor estén adaptadas las herramientas de administración existentes al perfil de cualificación y a los quehaceres diarios de los administradores.

3.7.5	Continuando la migración – introducción de ADS

La migración de los servicios de acceso desde Windows NT 4 a Windows 2000 directorio activo requiere usualmente pruebas aparte de concepto y prácticas antes de que el camino óptimo pueda ser finalmente determinado. Un posible proceso de migración será esbozado a continuación con la intención de ilustrar los pasos necesarios y las condiciones límite técnicas.3.7.5.1	Secuencia de operaciones

La migración desde Windows NT a Windows 2000 es muy flexible en lo que respecta a la secuencia de operaciones individuales. No es, por ejemplo, necesario migrar los sevicios de acceso primero seguidos de los clientes o vice versa. Tampoco es necesario cambiar un gran número de clientes de Windows NT en masa. Solo si un dominio NT existente es actualizado (actualización en el lugar), el PDC de este dominio deber ser previamente actualizado a Windows 2000.

Hay dos modos en el directorio activo: modos nativo y mezcla. Cambiar al modo nativo no es posible hasta que no haya más BDCs NT a los que deba suministrarse una réplica del SAM. El cambio al modo nativo no puede deshacerse. De todos modos, el modo nativo es necesario para un escenario de migración con reorganización (refiérase a la sección titulada “Variante 2: Actualizar y reorganizar” en el capítulo 3.7.5.3).

Una potencial optimización existe generalmente en lo que respecta a la planificación de la secuencia de operaciones. La explotación de este potencial debería ser orientada al entorno legado.

3.7.5.2	Arquitectura objetivo

El objetivo debería ser una estructura de directorios activos con un dominio o con el menor número de dominios posible. Un número pequeño de dominios significa normalmente un esfuerzo menor durante su operación.

Esto corresponde a las recomendaciones de diseño de Microsoft porque Microsoft prevé un alto grado de flexibilidad de los caminos de migración y un alto grado de opciones de reorganización con respecto a la migración desde NT a Windows 2000.

3.7.5.3	Esbozo de las variantes de migración

Las siguientes variantes de migración son generalmente posibles.

Actualización pura (actualización): la estructura de dominio existente se dejará sin cambios. Esto significa que todos los dominios serán actualizados.

Actualización y reorganización: Uno o más dominios se actualizan. Los restantes dominios NT se ajustan en la estructura.

Nuevo dominio y reorganización: Ningún dominio se actualiza. Uno o más dominios nuevos de un servidor ADS como objetivo de una reorganización de los dominios NT.

Mundos paralelos y migración de recursos: Ningún dominio es actualizado ni reorganizado. Solo los recursos (de datos, impresoras, etc.) se migran (copian).

Variante 1: Actualización pura

Una actualización pura (actualización in situ de todos los dominios) implicaría que la estructura existente de dominios permaneciese sin cambios. Aunque la posterior reorganización es posible (también llamada reorganización intra-selvática), no carece de cierto riesgo (no hay marcha atrás cuando las cuentas se mueven).

Variante 2: Actualización y reorganización

La actualización o migración in situ incluye la actualización de los dominios de cuentas a Windows 2000. Esto es seguido de una reorganización intra-selvática (implicando la disolución de los dominios de recursos).Página 134

Descripción técnica de las rutas de migración

Variante 3: Nuevo dominio más reorganización

Se crea primero un nuevo dominio y/o un nuevo AD (N. T. AD=Active Directory? Lo traducimos por DA?)

Figura 22: Migración ADS (N.T. ADS Active Directory Service SDA??)– nuevo dominio más reorganización

Las cuentas de usuario y los grupos globales del dominio se clonan en el nuevo dominio (destino) (incluyendo el histórico de SID (N.T. SID Security Identifier, IDS??)

Figura 23 Migración ADS – clonando usuarios y grupos

Este camino ofrece las siguientes ventajas:

Migración ininterrumpilble para el usario

Muy buen retroceso

Página 135

La reescritura de privilegios (ReACLing) puede postponerse y no es crítica en tiempo

La desventaja es:

Debe utilizarse un ADS adicional, incluyendo el hardware.

Variante 4: Mundo paralelo y migración de recursos

Se crea primero un nuevo dominio y/o un nuevo ADS

Figura 24: Migración ADS – mundo paralelo y migración de recursos

El mundo paralelo se llena con nuevas cuentas de usuarios y grupos. Se copian los recursos existentes en el nuevo mundo.Figura 25: Migración del Servicio de Directorio Activo (SDA) – llenando el mundo pararelo con cuentas de usuario y grupos.

Este método ofrece las siguientes ventajas:

No hay migración de servidores crítica en el tiempo.

No hay historia de identificadores de seguridad (SID).

Deben conocerse los derechos de acceso y deben ser “replicados” en el nuevo mundo.

La migración de datos puede significar reducción de datos.

Las desventajas son:

La migración de datos requiere un esfuerzo logístico importante en lo que se refiere al acceso común.

Dispositivos adicionales de hardware deben estan disponibles cuando se lleve a cabo la migración de datos.

3.7.5.4 Tareas de migración

La migración al directorio activo de Windows 2000 (reemplazando a NT) o la introducción completamente nueva del directorio activo de Windows 2000 requiere una planificación meticulosa y una validación en entornos de prueba.

Se deben llevar a cabo las siguientes tareas en el ámbito de un proyecto de migración.

Descripción por escrito de la infraestructura heredada.

Identificación de los requisitos para un nuevo entorno.

Determinación del marco de referencia técnico y organizativo.

Evaluación del entorno existente.Idea de la estructura futura global (bosque) y de dominio.

Determinación del espacio de nombres DNS y del espacio de nombres NetBIOS.

Determinación de las localizaciones y posicionamiento de los controladores de dominio.

Desarrollo de una idea global para los nombres.

Conexión con otros servicios de directorio.

Desarrollo de una idea para la estructura de unidades organizativas (UO).

Idea para la migración de servidores de acceso, recursos, aplicaciones y estaciones de trabajo.

3.7.5.5 Directorio activo con un vistazo a Windows 2003.

La arquitectura fundamental del directorio activo se mantiene en el producto que le sucede, Windows 2003.

Sin embargo, deben mencionarse aquí algunos cambios.

Se introduce un tipo adicional de partición junto a los tipos existentes (esquema, configuración, dominio): la partición de aplicación. La replicación de este tipo de partición a todos los controladores de dominio (CDs) en un dominio ya no es obligatoria. Esto significa que se pueden crear particiones propias para las aplicaciones de otros fabricantes, en las cuales se pueden almacenar de forma creciente datos dinámicos. Un control mejorado de estos datos dinámicos es posible entonces con una vista a la replicación. Los datos DNS integrados en el directorio activo se intercambian con tal partición.

Windows 2003 ofrecerá muy probablemente la opción de establecer servidores LDAP separados sin necesidad de instalar un controlador de dominio (CD). Aunque estos servidores LDAP (MADA = Modo de Aplicación del Directorio Activo) vienen con un esquema propio, están sujetos a los servicios de acceso del directorio activo. De este modo, se pueden crear servicios LDAP para las aplicaciones sin depender de los cambios en el esquema del directorio activo.

3.7.5.6 Directorio activo: configuración mínima.

Como ya se ha comentado, el directorio activo en su totalidad ofrece un amplio rango de tecnologías y funcionalidades que generalmente facilitan el desarrollo de nuevas funciones y/o procesos eficaces en entornos IT. La dependencia de productos y tecnologías de Microsoft aumenta en ese caso.

Si esto no es deseable, se puede tomar como objetivo un directorio activo de Windows 2000 con funcionalidad reducida. A continuación se describe como podría parecer una constelación así.

Un directorio activo con una configuración mínima presenta las siguientes propiedades y está sujeto a las siguientes condiciones.

La infraestructura de DNS se basa en una implementación independiente en vez de en la de Windows 2000, y esta implementación independiente satisface

+La infraestructura DNS está basada en una implementación independiente más bien que Windows 200, con esta implementación independiente se reunen los mínimos requerimientos. La entrada manual a los registros SRV en el DNS debe ser necesario.

+No se crea un único “forest”. Las verdaderas relaciones entre los dominios son realizados de la forma convencional.

La meta es que cada antiguo dominio de Windows NT pueda ser administrado con su propio esquema en su propio directorio.

+Además, si el dominio no ha sido cambiado a “modo nativo”, el “riesgo” de reducir las conexiones, ampliar grupos es reducido.

+Adicionalmente, la estructura OU no es incorporada a los dominios. En segundo plano: hasta tal punto una estructura permite funciones adicionales que pueden a pesar de todo ser accesibles.

+El uso de las directrices de grupo estan restringidas por la configuración de seguridad (como por ejemplo password(vocablo de validación, longitud mínima, etc.), privilegios(cambio de hora del sistema, nombre de acceso al sistema local, etc.) revisar configuración (auditorear) en la poítica del dominio por defecto. Estas configuraciones son necesarias para adecuar los reemplazos de configuración de Windows NT.

En segundo plano: La ausencia de un administrador de configuración de clientes mediane una guía de grupo reduce dependiencias.

+Una AD-based PKI (Public Key Infrastructure), que podría, por ejemplo, ser necesario para EFS o Ipsec, generalmente no es usado.

En segundo plano: se evitan las dependencias adicionales que resultan del almacenamiento en el AD

+El uso de un AD-based DFS (Distributed File System)

En segundo plano: se evitan las dependencias adicionales que resultan del almacenamiento en el AD

+Mientras Exchange 200 no es utilizado, las propiedads adicionales de los objetos del usuario se quedan sin utilizar o estan limitados por las propiedades obligatorias.

En segundo plano: la finalidad es no utilizar AD para almacenar datos personales en beneficio de reducir posibles dependencias secundarias (por ejemplo, terceras aplicaciones accediendo a estos datos por medio de KDAP).

+Los objetos de conexión de AD no son utilizados

En segunod plano: la acumulación de información en el AD incrementa las dependencias

+No hay información o liberaciones en el directorio activo.

En segundo plano: los usuarios de esta manera no

Nota: Las características y acciones comentadas anteriormente limitan la eficiencia máxima que puede lograrse con un directorio activo. Este es el precio de una gran independencia.No obstante, el uso de sedes dentro de ADS tiene sentido con el fin de controlar el proceso de replicación entre ubicaciones individuales.

No obstante, si se utiliza Exchange 2000 a nivel de dominio en una organización Exchange única, es inevitable la utilización de un único forest porque las funciones del Global Catalog no estarían disponilbles de otra forma.

Middleware – COM,.NET, J2EE

En los debates técnicos se pone de manifiesto que, si bien la actual tecnología de Microsoft para componentes (COM, DCOM) tiene continuidad, se está dando al mismo tiempo un cambio hacia la plataforma .NET. Esto tiene su contraparte en la Java 2 Enterprise Edition (J2EE) como plataforma alternativa. Diferencias fundamentales entre las dos plataformas, que juegan un papel clave en lo que se tratará a continuación sobre servicios web, son la independencia de plataforma, los lenguajes de programación soportados y la cantidad de proveedores de soluciones. La siguiente tabla (Tabla 16) muestra estas diferencias en mayor detalle.

Tabla 16: Comparación entre J2EE y .NET

Component Object Model (COM)

Gran parte de las tecnologías lanzadas por Microsoft se basan en el Component Object Model (COM). Tecnologías comparables orientadas a componentes son: CORBA (Common Object Request Broker Achitecture), del Object Management Group (OMG), y Java Beans de SUN.COM es un desarrollo evolucionado de OLE (Object Linking and Embedding) utilizado inicialmente para crear documentos combinados. COM es un estándar binario de componentes y por tanto independiente de los lenguajes de programación. COM puede generarse utilizando distitos lenguajes de programación como:

- C++

- C

- Java

- Visual Basic

- Delphi.

Al mismo tiempo, los componentes COM pueden reutilizarse con algunos de estos lenguajes. El único requisito para el lenguaje de programación es que sea posible implementar estructuras de punteros y llamar a funciones, bien explicita o implícitamente, a través de punteros. Los lenguajes orientados a objetos ofrecen mecanismos que simplifican la implementación de componentes COM.

La forma más habitual en que se utilizan componentes COM es en forma de ficheros dll. Otras variantes son:

- Librerías de enlace dinámico (*.DLL, *.OCX)

- Ficheros windows ejecutables (*.EXE)

- Clases Java (*.CLASS)

- Ficheros script (*.SCT, *.WSC).

Con el servicio COM Distribuido (DCOM), COM ofrece una capa de transporte intermedia de protocolo neutral para el uso de componentes remotos en otros ordenadores. DCOM pertenece al estándar Windows NT. La llamada a componentes en máquinas remotas se basa en Llamadas a Procedimientos Remotos (RPCs). Esta función, pertenece por tanto a la capa ISO/OSI 7 (capa de aplicación) y, en teoría, puede utilizar diferente protocolos de transporte (tales como TCP/ IP, IPX/ SPX) así como HTTP. El uso de HTTP es posible a traves del COM Internet Services (CIS) del IIS versión 4, en el que el protocolo DCOM es tunelado por HTTP. La seguridad de DCOM puede administrarse mediante la herramienta DCOM Configuration Utility (DCOMCNFG.exe). Específicamente define que grado de impersonalización debe utilizarse, p.ej. la capacidad de una rutina software para cambiar el contexto de usuario.

El uso de componentes COM sólo es posible bajo Windows. Aplicaciones que utilicen componentes COM tienen que ser adaptadas para portarse a otras plataformas.

La extensión de COM y DCOM bajo Windows 2000 es COM+.

".NET"

Antes de nada debe aclararse alguna de la terminología básica que se utiliza en conjunción con “.NET”. Se utilizarán las definiciones dadas por Microsoft en http://www.microsoft.com/germany/ themen/net/glossar.htm:

.NET:

La plataforma Microsoft para servicios XML que conecta información, dispositivos y usuarios de forma coherente y personalizada.

.NET Framework:

Entorno de desarrollo, provisión y ejecución de servicios web XML y otras aplicaciones. Integra dos componentes principales:

Common Language Runtime

Librerías de clases, tales como ASP.NET, ADO .NET y Formularios Windows.

.NET My Services:

Arquitectura orientada a usuario y colección de servicios XML que simplifican la integración de “islas de datos” independientes. .NET My Services está orientado al usuario más que a un dispositivo concreto, red o aplicación.

.NET Platform:

Consistente en herramientas, servicios Web XML, servidores y experiencia de usuario.

Las siguientes secciones tratan la plataforma NET principalmente como una solución middleware. En cierta forma esto se asemeja a la aproximación de Máquina Virtual Java (JVM) porque la instalación del entorno (por ejemplo en Windows 2000) significa que las interfaces con las partes integrales del sistema operativo (tales como Win32-API) son abstraídas y presentadas de una nueva forma. Esto principalmente tiene consecuencias para el desarrollo de aplicaciones. La siguiente ilustración (Figura 26) da una visión general de los componentes de la plataforma.

Figura 26: Componentes de la plataforma .Net

Las aplicaciones se programan en lenguajes soportados por “.NET” con acceso a la completa librería de clases “.NET”. La plataforma “.NET” soporta un gran número de lenguajes de programación. El compilador traduce el código fuente en un código de comandos (no es código máquina) que se llama lenguaje intermedio (IL). El resultado de esta acción es, por ejemplo, un fichero EXE. Cuando se carga este fichero EXE, el Common Language Runtime (CLR), con su compilador JIT (just-in-time), traduce el fichero EXE a código máquina.

Microsoft ofrece las siguientes herramientas para crear el código fuente:

por un lado un kit gratuito de desarrollo software (SDK) capaz suficientemente de crear programas “.NET”, y Visual Studio.NET, el sucesor del anterior Visual Studio Version 6, por otro.

A diferencia de Java y la JVM, la plataforma .NET solamente puede ser utilizada por sistemas operativos Microsoft.

Java 2 Enterprise Edition (J2EE)

La Java 2 Enterprise Edition incluye un completo abanico de servicios middleware que facilitan el desarrollo de aplicaciones en el lado del servidor. Componentes importantes de J2EE son:

-Enterprise JavaBeans (EJB)

-Enterprise Beans son componentes almacenados en el servidor que implementan la lógica de la aplicación. Los clientes pueden acceder los EJBs. Los Enterprise Beans se instalan en un contenedor EJB en el lado del servidor. El servidor los provee con ciertos servicios y entornos de ejecución.Nombres en Java e Interface de directorio (JNDI)

Este es el nombre y el servicio de directorio que habilita, referencia objetos remotos

para ser almacenados bajo un nombre definido y

para ser almacenados en un lugar definido (binding).

Además, JNDI permite encontrar un objetos límite a través de sus nombres (loopup).

Java IDL / Corba
Java IDL forma una interface con Corba. Java ORBs puede ser implementado usando Java IDL.

El método de invocación remota de Java (RMI) y RMI via IIOP (RMI-IIOP)
RMI es utilizado para distribuir comunicaciones entre objetos. Con RMI-IIOP, J2EE es compatible con CORBA.

A continución se muestras los nuevos servicios disponibles adicionalmente:

Conexión a Bases de Datos Java (JDBC)

Servicio de mensajes Java (JMS)

Java Servlets / Java Server Pages (JSP)

Java Transacción API (JTA)

Java API para XML (JAXP)

y algunos más.

Figura 27: Modelo de capas J2EE

Ofrece una vista general del modelo de capas de J2EE.

Figura 27: Modelo de capas J2EE 3.9 Servicios web (Web services)

3.9.1 Resumen

Los servicios web permiten la integración de diferentes plataformas y aplicaciones basada en estándares y de una manera independiente del fabricante.

Tanto el entorno de trabajo de .NET como J2EE proporcionan una plataforma integrada para el desarrollo de servicios web.

J2EE y .NET son igualmente adecuados para el desarrollo de aplicaciones de este tipo. Otras características comunes son:

Arquitectura de 3 capas (3-tier)

Orientación al componente, optimizados para arquitecturas distribuidas

Orientación a red

Internet como infraestructura central

El navegador de internet como principal interficie de usuario, "clientes enriquecidos" como interficie secundaria

Las diferencias entre las dos plataformas ya fueron esquematizadas junto a la presentación del Framework de .NET.

Debido a su alta flexibilidad y a su independencia tanto de fabricante como de plataforma, J2EE es el sistema a escoger. De esta forma también se siguen las recomendaciones de la SAGA 53.

Pero, ¿qué hay sobre la interoperatividad entre .NET y J2EE? En lo que a servicios web se refiere, dicha interoperatividad debería ser conseguida mediante la adopción por todas las partes implicadas de los estándares correspondientes (XML, SOAP, WSDL, UDDI). El único problema en este contexto es que SOAP, en su versión actual 1.1, todavía permite demasiada libertad, lo que puede significar la pérdida de interoperatividad en la práctica. De todas formas, la interoperatividad debe ser el objetivo de los servicios web. Este es un aspecto a mejorar, sobretodo con la versión 1.2 de SOAP.

3.9.2 Fundamentos

Un servicio web es un servicio el cual puede ser accedido mediante una dirección URL (Uniform Resource Alocator) por un cliente. El requerimiento crucial es que la implementación del servicio es completamente transparente para el cliente. Un web service puede ser considerado como una "caja negra" con cierta funcionalidad la cual puede ser usada de forma flexible sin tener que conocer los detalles de su implementación. Los servicios web ofrecen sus funciones al mundo exterior mediante interficies bién definidas. Dichas interficies son también denominadas Web Service Contract. Dicho contrato está descrito en un lenguaje específicamente desarrollado para ese propósito, esto es, el WebService Description Language (WSDL) (siendo éste un fichero XML). Los desarrolladores pueden usarlo como base para combinar servicios muy variados entre sí.

53 Standars und Architekturen für E-Government-Anwendungen, Version 1.1, KBSt Publication Series, ISSN 0179-7263, Vol. 56, Febrero 2003, http://www.kbst.bund.de/saga

para formar una aplicación completa. Estos servicios pueden ser encontrados usando UDDI (Universal Description Discovery and Integration). UDDI es una especificación basada en estándares para describir y encontrar servicios web, esto es, un repositorio para servicios web. Las primeras implementaciones han sido lanzadas ya por IBM, Microsoft y otros fabricantes.

En contraste con las tecnologías de componentes actualmente en uso, los servicios web no utilizan un protocolo de objetos específico, como pueden ser DCOM, IIOP o RMI, porque su fácil utilización normalmente requiere una infraestructura homogénea tanto en el cliente como en el servidor. Los servicios web se basan en otra aproximación. Se fundamentan en estándares de internet y utilizan el "mínimo común denominador", esto es, HTTP y XML (ver capítulo 3.10). Un cliente envía un mensaje empaquetado en XML vía HTTP a un servidor que contesta a la petición enviando otro mensaje en XML. Esto significa que los servicios web son independientes de lenguajes de programación concretos o de plataformas particulares. Mientras los dos extremos estén de acuerdo en el formato de los mensajes y se comuniquen mediante una secuencia de llamada común, el tipo de implementación del servicio (servicio web) es de una importancia secundaria. Puede usar todas las opciones de la plataforma en la que es utilizado. SOAP es la generalización de este principio. El llamado Simple Object Access Protocol define como deben construirse los mensajes XML y como debe formarse la secuencia de llamada. Esto quiere decir que las aplicaciones más dispares funcionando en plataformas diferentes pueden ser combinadas e integradas en soluciones existentes vía internet. El único prerequisito es que las aplicaciones usen SOAP para comunicarse entre ellas. El propio SOAP puede utilizar diferentes protocolos (como HTTP, SMTP). SOAP es un simple y poco complicado mecanismo para intercambiar información tipada y estructurada entre sistemas en un entorno descentralizado y distribuido usando XML. La desventaja de SOAP es, de todas formas, que es relativamente lento. SOAP está formado por tres partes. El envoltorio SOAP define un entorno de trabajo (framework, N.T.) para cada mensaje. Informa al recipiente del contenido del mensaje, a quién va dirigido y si se trata de un mensaje obligatorio u opcional. Esto se sigue de las reglas que definen, dentro del entorno de SOAP, como son codificados los datos (por ejemplo, números). XML incluye reglas que permiten un alto grado de flexibilidad. SOAP es menos flexible debido a que tiene definido un set de reglas más limitado, aunque esto no supone ningún impedimento.

Los servicios web permiten la integración de diferentes plataformas y aplicaciones de manera independiente del fabricante basándose en estándares.

Ambos, el entorno de trabajo de .NET y J2EE proporcionan una plataforma integrada para el desarrollo de servicios web.

3.9.3 Servicios web .NET

El entorno de trabajo de .NET (ver capítulo 3.8.2) soporta el desarrollo de servicios web profesionales. Esto comporta una reedición de Windows DNA (Distributed interNet Architecture).

.NET incluye su propio nivel de servicio para servicios web. La ilustración siguiente

(Figura 28: Entorno de trabajo Microsoft .NET) muestra la interacción entre los módulos individuales en lo que respecta a servicios web.

Figura 28: Entorno de trabajo de Microsoft .NET

La introducción de ASP.NET, sucesor de Active Server Pages, persigue los siguientes objetivos:

implementar un entorno de desarrollo tan simple y tan variado como sea posible.

ofrecer los servicios web explicados a continuación.

Por otro lado, Visual Studio .NET ofrece una manera relativamente simple de escribir aplicaciones (cliente) que utilicen servicios web basándose en XML y SOAP.

El servidor Internet information Server (IIS) (ver capítulo 3.11.3) es el corazón de los servicios web en Windows.

3.9.4 J2EE

La arquitectura J2EE (ver capítulo 3.8.3) está basada en el lenguaje de programación Java. Los programas escritos en Java ofrecen una ventaja, son independientes de la plataforma donde se utilicen. J2EE fue desarrollada originalmente como una arquitectura para aplicaciones en el lado servidor. La plataforma fue completada posteriormente al añadir soporte para servicios web basados en XML.

La capa de business logic la cual se implementa con componentes EJB (Enterprise Java Beans) cubre los procesos de negocio y la lógica con los datos. Asegura las conexiones a bases de datos mediante JDBC (Java Database Connectivity) y puede también acceder a servicios web externos. Por un lado, el acceso a aplicaciones J2EE puede tener lugar usando servicios web, siendo los servlets los encargados de manejar las consultas. Por el otro lado, los clientes convencionales, como lo son los applets olas aplicaciones, pueden acceder a componentes EJB directamente y en paralelo a otros metódos de la forma habitual. Los navegadores de internet y los dispositivos inalámbricos suelen estar conectados vía Java Server Pages (JSP) a los componentes EJB.

Los diferentes fabricantes, incluyendo a IBM, SUN y BEA entre otros, ofrecen entornos de desarrollo.

3.10 XML (Extensible Markup Language)

XML es considerado como la solución universal para la presentación e intercambio de datos. XML no tiene formato binario sino que se forma de cadenas imprimibles. XML ofrece las siguientes ventajas comparado con HTML (Hypertext Markup Language):

- XML separa la estructura del documento de la presentación. XML no incluye comandos de formato. El formato debe ser definido en una hoja de estilo.

- XML permite la definición de cualquier tipo de estructura con sus propios elementos y atributos

- La validez de la estructura puede ser comprobada por un analizador de XML contra una definición de estructura.

XML espera el denominado "buen formato” la cual se expresa en reglas, tales como: "las mayúsculas y minúsculas se distinguen en los nombres de los elementos".

Los documentos XML incluyen elementos especiales, las denominadas processing instructions (PI), en las cuales se pueden pasar al analizador instrucciones (por ejemplo, hojas de estilo).

Las definiciones de estructuras definen las estructuras válidas de los documentos XML. También son llamadas "vocabulario". Estas definiciones de estructura pueden ser implementadas en ficheros Document Type Definition (DTD) o en esquemas XML.

Se puede definir un espacio de nombres para el XML con el objetivo de evitar la definición ambigua del nombre de los elementos.

XSL (Extensible Style Sheet Languaje) es un lenguaje basado en XML para la transformación de documentos XML en HTML o en otros documentos XML. La transformación XSL es llevada a cabo por un procesador XSL.

XML ya juega un papel importante hoy en día y, en el futuro, todavía tendrá un papel más relevante en futuras aplicaciones de oficina (incluyendo los paquetes de oficina ya disponibles). Especialmente debido a que separa los datos de la presentación, XML permite la presentación, independientemente de la plataforma, de toda clase imaginable de datos (en cualquier forma) sin que los usuarios se tengan que preocupar de la presentación. Esto significará en el futuro un alivio considerable a la hora de trabajar en documentos y datos y un incremento de la productividad en la creación de documentos. Actualmente, los usuarios de paquetes ofimáticos todavía gastan una considerable parte de su tiempo dando a los documentos el formato apropiado.Este trabajo requiere pericia en labores de diseño y esquematización que los usuarios normalmente no tienen. La consecuencia es que se invierte más tiempo en el diseño que en trabajo de oficina en sí mismo. Gracias a la separación entre contenidos y presentación, los usuarios de aplicaciones ofimáticas pueden centrarse nuevamente en su trabajo de verdad y utilizar su tiempo productivamente. La presentación de los contenidos se puede dejar para aquellos responsables de uniformizar y centralizar los requerimientos de todos los usuarios.

XML es lo suficientemente flexible como para adaptarse a nuevas situaciones en cualquier momento.

De acuerdo con SAGA, XML servirá como estándar principal y universal de intercambio de datos entre todos los sistemas de información relevantes para propósitos administrativos 54. Los nuevos equipos que se instalen deberían ser capaces de intercambiar datos usando XML. Los sistemas ya existentes no han de estar preparados para XML necesariamente" 55.

Microsoft y Sun están de acuerdo al respecto: XML es la base para servicios web inteligentes.

3.11 Servidores web

3.11.1 Resumen

Con vistas a una migración de servidor web, el servidor web Apache constituye una alternativa a los productos de Microsoft, Internet Information Server 5.0 y 6.0.

No existen impedimentos técnicos concernientes al uso del servidor web Apache, el cual ofrece las funcionalidades necesarias para ser usado en entornos de producción. Apache ya ha demostrado su capacidad para ser usado en un variado conjunto de escenarios.

De todas formas, el esfuerzo necesario para migrar un proyecto debe ser determinado en detalle en cada caso. En el caso de una migración de páginas en HTML simple y aplicaciones CGI, el esfuerzo vale la pena normalmente.

Por el contrario, la migración de aplicaciones complejas, especialmente para generar contenidos dinámicos basados en tecnología ASP, usualmente requiere la reimplementación de las aplicaciones lo que significa un esfuerzo mayor. Pese a ello, no hay problemas que impidan dicha migración desde el punto de vista técnico ya que se dispone de tecnologías alternativas como PHP o JSP.

3.11.2 Introducción

El servicio web más conocido es la World Wide Web (WWW). La WWW es una aplicación clásica cliente/servidor donde el cliente recibe pasivamente información del servidor. La World Wide Web se basa en HTML (Hyper-

55 Standards und Architekturen für E-Government-Anwendungen, Version 1.1, KBSt Publication

Series, ISSN 0179-7263, Vol. 56, Febrero 2003, http://www.kbst.bund.de/sagaDescripción técnica de las vías de Migración

Protocolo de transferencias de texto) protocolo y el HTML (Hypertext Markup Language) como lenguaje de descripción de páginas. El servidor contesta a las peticiones de los clientes y proporciona los contenidos deseados. Los servidores Web tienen como tarea adicional el envío de contenidos generados dinámicamente, por ejemplo, por una aplicación de bases de datos a los sistemas cliente. Ciertas interfaces permiten incluso el arranque de programas completos en los servidores y la ejecución de acciones. Las acciones son usualmente inicializadas por los sistemas cliente. Esto permite a los clientes disparar ciertos procesos en el servidor. La propagación de las soluciones Internet e intranet lleva a un incremento en la demanda de tareas a ejecutar sobre servidores web, por lo que se desarrollaron diferentes programas y soluciones.

3.11.3 Internet Information Server 4.0

Microsoft Internet Information Server (IIS) es un servidor de aplicaciones y ficheros para para Internet e intranet. IIS 4.0 es parte del servidor Windows NT 4.0 Option Pack. IIS proporciona las funciones básicas de un servidor web sobre la base del sistema operativo Windows NT 4.0.

La interacción satisfactoria entre los extremos cliente y servidor está asegurada mediante el soporte de todos los protocolos de Internet relevantes, es decir:

HTTP 1.1

SMTP

NNTP

FTP.

El soporte HTTP del ISS 4.0 incluye las siguientes características:

Yuxtaposición: esta característica permite el envío de varias peticiones simultáneas por parte del cliente antes de que el servidor conteste.

Mantener vivas: al mantener vivas las conexiones cliente/servidor, un cliente puede usar una sola conexión o, por lo menos, un número pequeño de ellas para enviar bastantes peticiones.

HTTP PUT y DELETE: esta característica permite el suministro o borrado de datos por los usuarios a través de un navegador. La RFC 1867 permite incluso el control de la subida de ficheros usando otros programas.

El soporte SMTP se proporciona implementando un servicio de correo SMTP que permite enviar y recibir mensajes de correo SMTP. Este servicio puede ser usado para la comunicación entre el servidor web y el cliente, por ejemplo.

El servicio integrado NNTP (Network News Transport Protocol) permite la creación de grupos de discusión locales en un único servidor. La obtención externa de noticias o la replicación no están soportados. Descripción técnica de las vías de Migración

3.11.3.1 Aplicaciones Web

El servidor IIS ofrece las siguientes extensiones del servidor:

programas CGI

aplicaciones ISAPI

aplicaciones ASP

Common Gateway Interface (CGI) es un procedimiento para generar contenidos dinámicos. CGI es un interfaz para invocar programas que el servidor pueda utilizar. CGI fue desarrollado originalmente para entornos UNIX y requiere un reparto significativo de recursos de sistema bajo Windows NT. La ventaja de los programas CGI es que pueden ser ejecutados por prácticamente cualquier servidor y son habitualmente sencillos de programar.

Internet Service Application Programming Interface (ISAPI) es un interfaz directo con IIS. Los objetos del servidor pueden accederse vía ISAPI.

IIS 4.0 permite la creación de páginas HTML dinámicas o bien el uso de aplicaciones web a través del uso de Active Server Pages (ASP). La tecnología ASP proporciona un entorno de script en el extremo servidor. Las páginas ASP son ficheros que pueden contener etiquetas HTML convencionales así como comandos de script. Los comandos de script relacionados son ejecutados en el servidor y se usan para generar código HTML. El código HTML estático y dinámico es devuelto al navegador solicitante en la forma de página HTML. El uso de páginas ASP permite el diseño de contenidos interactivos para los usuarios. El acceso a bases de datos puede ser implementado usando páginas ASP.

IIS 4.0 soporta las siguientes tecnologías junto al desarrollo de contenidos web:

Depurador de scripts de Microsoft

Permite la prueba de las aplicaciones ASP.

Interfaz de programación COM

Proporciona a los desarrolladores acceso a los componentes COM los cuales acceden a las funciones de protocolo del ISS.

Máquina virtual Java

Permite la creación y ejecución de componentes java dentro de una máquina virtual.

Objetos de administración de IIS

Proporciona a los desarrolladores acceso la los componentes necesarios para crear utilidades de administración.

Páginas ASP transaccionales

Permite a las páginas ASP y a sus componentes llamados formar parte de una transacción, la cual, sin embargo, debe ser administrada por el servidor de Transacciones de Microsoft (referirse también al capítulo 3.11.3.3).

Aislamiento entre procesos

Permite a las aplicaciones ASP e ISAPI (Internet Server-API) ejecutarseDescripción técnica de las vías de Migración

en procesos separados. Los procesos se ejecutan en paralelo con el proceso principal del servidor.

Carga y descarga de componentes

Esto significa que los desarrolladores web pueden cargar o descargar componentes dinámicamente en una aplicación web.

Autenticación y seguridad

El modelo de seguridad es el mismo para todos los componentes de un servidor NT. Las mismas funciones que están disponibles para los servidores de fichero o de bases de datos pueden ser usados por el ISS. Los dominios de usuarios y grupos existentes pueden ser usados para asignar autorización y privilegios a medida. IIS utiliza la misma base de datos de directorio que los otros servidores Windows NT. Puede darse a los usuarios acceso restringido a los recursos de red, tales como páginas HTML, aplicaciones web y ficheros. Los privilegios del sistema de ficheros NTFS pueden usarse para efectuar una asignación de privilegios de alta granularidad.

El uso de Secure Sockets Layer (SSL) proporciona un método para el intercambio seguro entre los clientes y el servidor. También es posible que el servidor verifique o autentique la identidad del cliente y que el cliente no tenga porque entrar en el servidor.

El servidor de Certificados integrado permite el establecimiento de una instancia de certificación y la provisión de certificaciones X.509 estándares para los clientes.

Componentes adicionales del Internet Information Server

Adicionalmente a los componentes del núcleo del IIS, Microsoft ofrece varios componentes para extender las funcionalidades del servidor web. Los componentes descritos a continuación también forman parte del paquete opcional de Windows NT.

Servidor de Transacciones de Microsoft (STM)

STM es un sistema de proceso de transacciones para el desarrollo, implementación y administración de aplicaciones de servidor distribuidas. El proceso de transacciones puede, por ejemplo, usarse para implementar aplicaciones de negocio distribuidas.

Depurador de scripts de Microsoft

El Depurador de scripts de Microsoft está diseñado para permitir la identificación de errores en los ficheros ASP. El depurador puede ser ejecutado junto a Internet Ex­plorer y puede ser usado para la depuración.

Servidor de Indexado de Microsoft

El servidor de indexado puede usarse como una máquina de búsqueda para contenidos Internet o intranet. El servidor puede indexar el texto de los contenidos almacenados, los cuales pueden ser explorados por los usuarios usando formularios web. Adicionalmente a los documentos HTML puros, el servidor de indexado puede indexar también documentos en formato Microsoft Word y Excel.

Servidor de colas de mensajes de Microsoft

El Servidor de Colas de mensajes de Microsoft (SCMM) permite a los programas de aplicación comunicarse asíncronamente con otros programas a través de la recepción y el envío de mensajes. Descripción técnica de las vías de Migración

Consola de Gestión de Microsoft

La Consola de Gestión de Microsoft (CGM) permite la administración de las más variadas tareas por parte de diferentes programas de administración de redes. La administración de los servidores se efectúa por los llamados "snap-ins" en la consola.

3.11.4 Migración por reemplazo

3.11.4.1 Apache

El servidor web Apache es una aplicación ampliamente usada en la práctica en sistemas basados en Linux. Contando como más del 60% de los productos instalados, Apache es el servidor web más frecuentemente usado56 a nivel mundial. Está disponible gratuitamente, sujeto a la licencia de programa Apache. El servidor web Apache es uno de los proyectos de mayor éxito de la Comunidad de Código Abierto. El proyecto fue desarrollado sobre la base del servidor del NCSA (National Center for Supercomputing Application, Universidad de Illinois) al cual se le añadió un siempre creciente número de parches ("A patchy web server") y que sirvió como base para la primera versión beta en 1995. Hoy en día, ha sido compilado para casi todas las plataformas. El servidor Apache es hoy en día el servidor web más frecuentemente usado en plataformas Linux/UNIX, aún cuando se ejecuta en un completo rango de otras plataformas, incluyendo, por ejemplo, Windows NT o Novell Netware.

Desde la versión 2.0.35 de Abril del 2002, la serie de desarrollo 2.0 del servidor web Apache ha sido lanzada como estable, y es también recomendada por desarrolladores para su uso en producción. La serie de desarrollo 1.3.x es actualmente actualizada en paralelo con la serie nueva 2.0.x, siendo la versión 1.3.27 la última versión disponible.

Consecuente con los términos y condiciones de su licencia y gracias a su gran calidad, el servidor web Apache es también utilizado en productos comerciales. IBM, por ejemplo, suministra Apache como parte de su producto Websphere.

Funcionalidad

El servidor web Apache consiste en un núcleo y en un enorme número de módulos que pueden ser compilados y/o cargados a petición por las aplicaciones específicas. Gracias a su diseño modular, el servidor Apache puede ser actualizado fácilmente y adaptado a los requerimientos cambiantes. El programa estándar que se suministra incluye ya un gran número de diferentes módulos que pueden ser complementados con módulos adicionales (desarrollos propios, por ejemplo). Los módulos de Apache son segmentos de código que se corresponden con la especificación Apachi API y que pueden ser cargados en el servidor web Apache. Los módulos Apache pueden ser enlazados estáticamente de forma permanente o bien cargados dinámicamente vía el fichero de configuración del servido web. Este diseño modular permite la actualización de la funcionalidad del servidor web e incrementa la flexibilidad del sistema de forma significativa. El rendimiento y la velocidad del servidor web se incrementa si se ejecutan los procesos internos en lugar de aplicaciones externas.

56 http://news.netcraft.com/archives/2003/03/ Descripción técnica de las vías de migración

Los abundantes módulos incluyen autenticación, seguridad así como módulos intérpretes para diferentes lenguajes de programación, tales como PHP, Java, Python, Tcl y Perl. Existen dos opciones diferentes para usar los módulos:

En el caso de compilación estática del servidor web, los módulos pueden ser enlazados estáticamente.

Los módulos pueden ser cargados dinámicamente durante el funcionamiento del servidor. La funcionalidad de los denominados OCD (Objetos Compartidos Dinámicos) elimina la necesidad de recompilación en caso de cambio de la configuración del servidor. Un reinicio del servidor es suficiente, siendo incluso posible un grácil reinicio sin interrupción del servicio.

Ya que no se usan las módulos que los que realmente se necesitan, Apache es más pequeño que una versión estándar y requiere una capacidad de memoria inferior. Al mismo tiempo, menos módulos implica una menor exposición por lo que la seguridad del sistema es también mejorada.

A continuación, la tabla (Tabla 17) muestra una pequeña selección de los módulos disponibles.

Tabla 17: Módulos Apache

Módulo	Función
Módulos estándar y adicionales
mod_cgi	Ejecución de scripts CGI (Common Gateway Interface).
mod_dav	Soporte integrado para DAV (Extensiones HTTP para creación Distribuida – WebDAV). Edición de ficheros y directorios vía HTTP en el servidor web. DAV significa "Distributed Authoring and Versioning".
mod_fastcgi	Soporte integrado para FastCGI.
mod_frontpage	Soporte integrado para FrontPage.
mod_iserv	Soporte integrado para Java servlet.
mod_php3	Soporte integrado para PHP 3.
mod_php4	Soporte integrado para PHP 4.
mod_perl	Soporte integrado para Perl.
mod_alias	Proporciona la capacidad de alias y/o redirecciones.
mod_autoindex	Genera índices de directorio.
mod_include	Se requiere para includes en el lado servidor.
mod_mime	Asegura la generación de las correspondientes cabeceras MIME.
mod_log_config	Para mantener uno o más ficheros de registro, con la posibilidad de adaptar los contenidos a los correspondientes requisitos.
mod_deflate	Sirve para comprimir algunos tipos de fichero previo a su envío al navegador. Esto es particularmente útil en caso de anchos de banda limitados. La función de compresión debe ser soportada por los navegadores.
mod_proxy	Añade la funcionalidad de un “proxy” y/o un caché de “proxy” al servidor web.
mod_rewrite	Permite el uso de alias internos y redirecciones externas.
mod_speling	Corrige los errores tipográficos de los usuarios.

Módulos	Función
mod_ssl	Deja disponibles los protocolos SSL (Capa de sockets Seguro) y TLS (Seguridad de capa de transporte).
mod_usertrack	Las cookies HTTP son utilizadas para registrar los comportamientos de usuario.
mod_vhost_alias	Interesante para la configuración a granel de los hosts virtuales, especialmente para el servicio de proveedores.
Módulos de	autentificación
mod_access	Control de acceso base de los nombres de host o direcciones IP.
mod_auth	Para configurar los directorios protegidos por contraseña y documentos. Una muy simple variante de un módulo de autentificación el cual debería ser usado por un reducido grupo de usuarios solamente.
mod_auth_digest	Autentificación de usuario por aceptación MD5, con la contraseña no siendo transmitida como texto plano.
mod_auth-dbm	Autentificación de usuario por archivos Berkeley DB, apropiado para un extenso número de usuarios.
mod_auth_ldap	Autentificación de usuario por LDAP.
mod_auth_kerb	Autentificación de usuario por Kerberos, soporta las versiones 4 y 5.
mod_auth_notes	Autentificación de usuario por Servidor Lotus Notes.
mod_auth_oracle	Autentificación de usuario por base de datos Oracle. Los mas nuevos módulos están además disponibles, por ejemplo, para bases de datos mySQL y Postgres.
mod_auth_smb	Atentificación de usuario por Servidor SMB (Samba, Windows NT)

Este listado de módules disponibles no es exhaustivo. En su lugar, esta diseñado para mostrar justo algunas posibilidades del servidor web Apache.

De todos modos, no todos los módulos del servidor web son gratis. Cada vez mas compañías comerciales ofrecen módulos Apache nativos. Algunos ejemplos son :

Allaire con el motor Macromedia JRun Java Servlet y el servidor de aplicación Macromedia ColdFusion.

Sun Microsystems con su módulo Servidor Activo de Páginas.

Ediciones Relacionadas

El servidor web Apache puede ser complementado por un progrma que habilite la integración de la funcionalidad de búsqueda con un sitio web. Diferentes grupos de software están disponibles con el sistema de busqueda HTDig *57 siendo descrito a continuación como ejemplo de tal grupo. HTDig permite indexación de sitios web completos. El programa utiliza el llamado robot en orden de generar un índice de busqueda el cual puede ser hojeado por un apropiado script CGI. El núcleo de funcionalidades del software es esquematizado en los siguientes puntos.

Generación de un índice de motor de búsqueda (para uno o mas sitios web y/o partes de un sitio web)

Uso de filtros en orden de limitar la función de indexado. Posibles criterios de filtro son los tipos de archivos y URLs específicas.

__________________________

*57 http://www.htdig.org

Programas adicionales externos pueden ser utilizados en mandato de indexar formatos de ficheros (PDF, DOC, etc.)

Existen numerosas opciones de petición, y pueden ser usados diferentes algoritmos de busqueda (palabras, parte de palabras, sinónimos, etc.)

La página de búsqueda y la conrrespondiente lista conseguida puede ser ajustada utilizando simples plantillas de ficheros.

Metafonía de vocales en las cadenas de busqueda están soportadas.

El robot utilizado soporta el estandar de “Exclusión de Robot” y de la “Autentificación Básica WWW” para indexado de contenidos protegidos.

La distribución HTDig esta sujeta a la Licencia General Pública (GPL) y por lo tanto disponible libremente.

Administración.

La configuración del instalado Apache es relativamente simple porque la mayor parte de configuraciones requieren exactas entradas para ser editadas o agregadas en un bien documentado archivo. Este es un simple archivo que puede ser editado utilizando cualquier editor de texto. Algunos comerciales o no comerciales proyectos relativos a la Apache GUI*58 ya exiten para administradores quienes prefieren una interfaz de usuario gráfica.

Migración

Los datos y/o contenidos para ser migrados deben ser distinguidos dentro del alcance de un proyecto de migración. La diferenciación es posible en terminos de:

Archivos HTML

Programas CGI (Perl, PHP, C, etc.)

Módulos de programa utilizando la ISAPI (Interfaz de Programación de Servidor de Aplicación de Internet) del Servidor de Información de Internet.

Paginas de Servidor Activo.

Páginas HTML

Contenidos estáticos, p.ej. Páginas puras HTML pueden ser exportadas al nuevo servidor web sin adaptaciones adicionales, y son causa probable del menor número de problemas y un esfuerzo en conjunto con un cambio en el servidor web.

Interfaz común de puerta de enlace.

Los programas que fueron desarrollados como interfaz común de puerta de enlace (CGI) también utilizan los estandares específicos CGI. Estos estandares definen la manera en la que los programas y servidores interactuan. Este estandar no es un lenguaje específico y esta soportado por el servidor web Apache. Numerosas opciones están disponibles para el desarrollo de programas CGI. Perl es uno de los mas extensamente esparcidos y el mayor portable lenguaje de script. Perl está disponible en MS-DOS, UNIX / Linux, OS/2, Macintosh

______	_____________________

58* http://gui.apache.orgy cualquier variante de Windows, por mencionar algunas. Perl ofrece también una gran cantidad de opciones para la manipulación de texto y datos por desarrolladores web. Las aplicaciones desarrolladas en Perl pueden migrarse fácilmente a Apache. Apache incluye el módulo “mod_perl” que representa la implementación completa de Perl. Más aún, en muchos casos puede lograrse una optimización de la ejecución. Los módulos Perl incrustran un intérprete de Perl en el servidor web Apache, de forma que no es necesario ya iniciar un proceso aparte para ejecutar el código de programa. Y más, la velocidad puede incrementarse significativamente. El portado de aplicaciones Perl requiere mínimos cambios en el código de programa.

PHP es uno de los lenguajes de script que más rápìdo se está extendiendo, estando muy bien soportado en distintos sistemas de bases de datos y con una sintaxis relativamente simple. PHP, como Perl, corre en sistemas muy distintos. Las aplicaciones PHP desarrolladas para Internet Information Server pueden portarse al servidor web Apache con mínimo esfuerzo.

ISAPI

Las aplicaciones que utilizan ISAPI sólo pueden continuar utilizándose, en conjunción con servidores web Apache, si estos se ejecutan en sistemas basados en Windows NT o 2000. Apache incluye compatibilidad ISAPI total como funcionalidad estándar en sistemas Windows. Las aplicaciones sólo tienen que recompilarse en el nuevo entorno Apache. En consecuencia, habitualmente no será necesario modificar código. No obstante, los filtros ISAPI y las extensiones Microsoft para operaciones asíncronas sobre ficheros, no son soportadas.

ASP

Las aplicaciones basadas en tecnología ASP están habitualmente diseñadas para generar contenido web dinámico. Pueden utilizarse distintas bases como:

Visual Basic Script (VBScript)

Jscript

y ActiveX Data Objects (ADO) para acceder a bases de datos.

Con el fin de ejecutar páginas ASP en el servidor web de Apache, se necesita el entorno completo de desarrollo compatible Microsoft (VBScript, JScript, ADO). Sun Microsystems ofrece su producto “Sun One Active Server Pages 4.0” como entorno compatible para la ejecución de páginas ASP desde el servidor web Apache. Este servidor puede correr en bajo el sistema operativo NT y bajo UNIX/Linux también.

El producto soporta:

ASP 3.0

VBScript 5.5

Jscript 5.5.

La migración a un servidor web Apache sobre un sistema Linux requiere, como primer paso, que todos los ficheros ASP sean copiados a la nueva plataforma. Posteriormente, los objetos COM usados por las aplicaciones ASP tienen que identificarse y conciliarse con los soportados bajo Linux. El producto Sun One ASP soporta un gran número de objetos. Si un objeto necesario no es soportado, el COM-to-Java Bridge proporcionado puede utilizarse para implementar la funcionalidad utilizando Java. Además, los cambios que tienen que ver con la notación en mayúscula y minúscula deben ser comprobados bajo la versión de ASP y/o Scripting Engine. En la documentación relacionada puede encontrarse una descripción detallada Lo relativo a la necesaria migración de la base de datos no se trata en esta sección. El capítulo “Bases de Datos” contiene información detallada.

Además de la opción de no cambiar las aplicaciones ASP tal cual existen, es posible también el uso de tecnologías alternativas. Esta aproximación debe utilizarse si la independencia de plataforma es un requisito significativo. No obstante, esto requiere un esfuerzo adicional porque la implementación de aplicaciones en una nueva tecnología habitualmente requiere esfuerzos mayores. Como ventaja, el proceso de migración se puede aprovechar también para optimizar contenidos y aplicaciones.

El uso de tencnología PHP puede ser una alternativa real para muchas aplicaciones. Especialmente la combinación de

Linux

Apache

MySQL

PHP

en los últimos años ha llevado al desarrollo de una plataforma muy podpular (LAMP) para la generación de contenidos web. Si se requiere la conversión de aplicaciones ASP a PHP, un vistazo al contenido del proyecto “ASP-to-PHP” será útil. El proyecto ofrece un convertidor ASP-to-PHP en su página principal y soporte a través de una lista de distribución.

Mas allá de esta opción, puede considerarse también el uso de tecnología basada en Java. Las aplicaciones web basadas en Java son una alternativa interesante a las aplicaciones web basadas en ASP. En el momento presente las aplicaciones Java más habituales siguen las especificaciones Java 2 Standard Edition (J2SE) y Java 2 Enterprise Edition (J2EE) de Sun Microsystems. La tecnología Java descansa en un estándar de la industria y ofrece la ventaja de la independencia de plataforma. Las aplicaciones web J2SE permiten el desarrollo de contenidos dinámicos utilizando Java Server Pages (JSP) y servlets Java . Ambas tecnologías permiten, por ejemplo, el desarrollo de contenidos personalizados y acceso a fuentes de datos externas. El producto Open Source “Tomcat” puede utilizarse en las páginas JSP y servlets. El proyecto Tomcat se desarrolla en el contexto de la Apache Software Foundation.

Descripción técnica de los caminos de migración

(ASF). Tomcat ofrece un entorno de ejecución escalable para páginas JSP y servlets Java y por tanto representa una alternativa muy buena a las soluciones ASP para el caso de aplicaciones que no tengan una lógica de negocio compleja. La version 4.x de Tomcat soporta las especificaciones 2.3 de servlet y 1.2 de JSP.

Los estándares de Java 2 “Enterprise Edition” se pueden usar en escenarios de aplicaciones complejas, que requieren funcionalidades extendidas. El llamado “Enterprise Java Beans (EJBs)” permite la implementación de aplicaciones para procesos de negocio complejos, y reglas que requieren acceso simultáneo a sistemas externos. El entorno J2EE necesita una aplicación servidora que ejecute el EJBs.

El servidor de aplicaciones se debe habilitar para asegurar la gestión de la sesión de los usuarios. Es más, debe ofrecer interfaces adecuados para las aplicaciones externas y debe asegurar el alto grado de disponibilidad requerido (cluster, balanceo de carga, failover). Además de los familiares productos comerciales como IBM Websphere, BEA Weblogic, Oracle Application Server y algunas otras, es también posible utilizar productos Open Source. El proyecto JBoss ofrece un completo servidor de aplicaciones Java basado en Open Source. El servidor de aplicaciones soporta la especificación J2EE. Viene con un servidor web integrado, un motor de servlet y JSP, y soporta Entreprise Java Beans, así como “clustering” y otras funcionalidades

También se ofrecen descripciones detalladas de los procedimientos para migrar aplicaciones ASP a tecnologías basadas en Java, por ejemplo por SUN y Oracle , de manera que no es necesario dar las descripciones en este punto.

Continuando con la migración

3.11.5.1 Internet Information Server 5.0

Características nuevas

El Internet Information Server es parte integral de los servidores Windows 2000. La siguiente versión, i.e Internet Information Server 4.0, trae varias nuevas funcionalidades. La más importante de ellas están recopiladas en la tabla de abajo (Tabla 18).

Table 18: Funcionalidades extendidas del Internet Information Server 5.0

Función	Descripción
Soporte Frontpage	Para hacer posible el desarrollo y la administración de los contenidos web se utiliza Microsoft Frontpage. El administrador utiliza un entorno gráfico amigable para crear y editar los contenidos web en el servidor web.
Soporte de múltiples sitios web	Permite el hospedaje de múltiples sitios web en un servidor y una dirección IP.
Compresión HTTP 1.1	Hace posible la compresión durante la comunicación entre el servidor web y el sistema del cliente con la capacidad de compresión. Esta característica es beneficiosa en el caso de un ancho de banda limitado.
Evaluación PICS	"Platform for Internet Content Selection"65-Rating es una técnica estándar para la evaluación del contenido web del consorcio W3. PICS permite la evaluación del contenido y el filtrado de sitios web acorde con las características de éste. Esto se consigue añadiendo un código PICS a la cabecera HTML del documento, el cual no es visible por el navegador.
Aplicaciones basadas en Web	
Integración XML	En Windows 2000 un convertidor XML está implementado como un componente COM y ofrece una completa solución básica para las aplicaciones.
Componente Windows script	Los desarrolladores pueden utilizar la tecnología de scripting para la reutilización de módulos COM con aplicaciones web.
Determinar las propiedades del navegador	Las propiedades exactas del navegador del cliente pueden ser determinadas por medio de ASP.
Aislamiento de porcesos	El administrador puede aislar indivualmente procesos de las aplicaciones y procesos del kernel al igual que procesos de otras apliciones.
ADSI 2.0	Permite el acceso a los objetos, propiedades y métodos del directorio activo por medio de una interfaz. La integración del servidor web y el directorio activo facilita la asignación de diferentes sitios web en el servidor web del dominio del usuario.
Administración	
Delegación de administración	Facilita la delegación de tareas de administración.
Regular el flujo de procesos	Permite la limitación de tiempo de CPU a una aplicación de red o sitio web. Esta característica puede ser utilizada para asegurarse que el tiempo de CPU está disponible para otros sitios web o aplicaciones que no son web.
DFS	El Distributed File System es un sistema de ficheros que permite la distribución transparente de éstos a múltiples ordenadores. Esta característica puede ser utilizada el el documento maestro como un área donde el contenido web está almacenado en el sistema de ficheros.
Autentificación y seguridad	
Kerberos	La identificación del usuario es posible gracias a Kerberos, mientras que el antiguo método de autentificación de Windows utiliza Windows LAN Manager (NTLM)
Encryption	Utiliza SSL 3.0 y TLS (Trasport Layer Security) para encriptar los datos a transmitir.
Resument de Autentificación	Permite encriptar el password para la autentificación

Descripcion Técnica de las rutas de migración

[Tabla ]

Internet Information Server 6.0

Windows 2003 Server viene con Internet Information Server 6.0 (IIS6.0) y por primera vez, no viene el mecanismo de instalacion descativado por defecto, y sin automatizacion integrada. El Administrador debe especificar el incio del proceso de instalacion y activiar ciertas funcionalidades del servidor.

Esta es la combinacion de tencologias incluidas dentro de la familia de productos de Windows Server 2003.

-Internet Information Server 6.0

-ASP.NET

-ASP

-COM+

-Microsoft Message Queueing (MSMQ)

Las posibilidades de utilizar un servidor de apliaciones sera ofrecida mas adelante.

Nuevas caracterisitas se han implementado para este nuevo rol para Internet Information Server, estas nuevas caracteristicas son tratadas brevemente a continuacion.

Los cambios han sido implementados con una arquitectura de proceso que permitiera la disponibilidad y escalabilidad. Estos activan la detecciona automatica de errores y el reinicio de los procesos cuando es necesario. Paralelo a esto, el servidor web puede recibir peticiones de entrada en cola. IIS 6.0 es capaz de monitorear el estado de los procesos de trabajo, aplicaciones y sitios web. Ademas el driver del nuevo kernel, que ha sido introducido en Windows 2003 Server ha sido diseñado para optimizar los datos a traves del servidor web.

IIS 6.0 puede ser integrado con el framework de autorizacion para Windows 2003 Server. Ademas el administrador de autorizaciones puede ser usado par ala delegacion y autorizacion de acciones. La administracion de IIS 6.0 es ahora implementada en una meta base XML, activando administradores directamente para editar la configuracion.

Otra nueva caracterisitica es la integracion con ASP.NET e IIS, el cual ofrece fucionalidades extendidas para el desarrollo del Framework de .NET para crear aplicaciones. El estandar unicode puede ser usado por desarrolladores y usuarios que deseen internacionalizar las aplicaciones.

Servidor de Portales SharePoint.

Resumen

Esta guia de migracion no discute a Share Point Portal Server bajo aspectos de migracion concreta. El sistema es estudiado primariamente con una vision de futuro

DESCRICIONES TECNICAS DE LAS RUTAS DE MIGRACION

(viene de pagina 160), vision de un uso futuro. Se debe entender dentro del analisis de requerimientos a SharePoint Portal Server como un agregado al concepto de solucion de administracion de portales o como una solucion para el manejo de documentos.

Introducción.

Con SharePoint Portal Server, Microsoft ofrece una plataforma para crear portales web con las siguientes funciones principales.

-Busqueda.

-Manejo de Documentos.

-Trabajo de Grupo

Microsoft has desarrollado un producto que cumple con las clasicas tareas de in portal de intranet de un una compañía. El Share Point Portal Server, esta fuertemente integrado en las aplicaciones de escritorio (Windows Explorer, Aplicaciones de Oficina, navegador) para crear y administrar contenidos totales de una compañía. El Share Point Portal Server, constituye una solucion de portal con un workflow integrado y busqueda de funcionalidades.

Los requerimientos minimos de sistema para Microsoft Windows 2003 Server o Advanced Server asi como tambien Internet Information Service 5.0, y el Protocolo de transferencia simple de correo. El active directory no es obligatorio para el Share Point Portal Server,. El servidor puede ser instalado en Windows NT, on un directorio de dominio inactivo.

El Share Point Portal Server 2001, esta basado en Microsoft's WebStorage System Database. La administracion del servidor es realizada a traves de Microsoft Managment Console (MMC). Areas de trabajo, roles de seguridad, tiempos de desactivacion y configuracion de protocolos, pueden ser personalizados aquí, para mencionar algunos. Encripcion SSL, puede ser activada para utilizar el intercambio seguro de datos via Internet/Extranet.

El Share Point Portal Server, es discutido y descripto en este contexto para analizar los aspectos individuales, relevante al diseño de portales.

Sitio de Ingreso o de Distribucion

Cunado Share Point Portal Server es instalado, un portal llamado “dashboard site” es automaticamente generado. Las siguientes funciones, puede hacerse disponibles a los usuarios del portal web.

-Busqueda de funcionalidades

-Suscripcion para modificacion o agregado de nuevos contenidos

-Chequeo de documentos dentro y fuera, incluyendo versionado.

-Publicacion de Documentos.

El dashboard site usa la tecnología Microsoft's Digital Dashboard, para organizar y mostrar la informacion. Un dashboard digital consiste en la llamada de componentes via web el cual representa la informacion de recursos internos y externos dentro del portal. Otras areas de trabajo Share Point Portal Server, sitios de internet e intranet.

sitios de intranet o Internet, jerarquías de carpetas públicas de Microsoft Exchange 2000 y Exchange Server 5.5, bases de datos de Lotus Notes, sitemas de ficheros locales y sistemas de ficheros de red, pueden ser añadidos a las fuentes externas de contenidos. Las partes de web, pueden ser desarrolladas por los propios usuarios u obtenerse de terceras partes. De todos modos, están disponibles partes de web, por ejemplo, para integrar el correo entrante y saliente de Outlook, calendario y citas. Las partes de web de terceras partes, pueden ser integradas de manera que se puede acceder otros sistemas de informacion (SAP, sistemas CAD, sistema de archivado, etc.) mediante el portal.

La informacion y los documentos pueden asociarse a diferentes categorías dentro del portal. Estas categorías, a su vez pueden adoptar una estructura jerárquica.

Dentro de la pizarra digital, cada usuario puede controlar la organización y presentación de las partes de la web. La pizarra puede accederse desde un navegador web como Microsoft Internet Explorer o Netscape Navigator. Debe activarse Jscript de Microsoft o JavaScript de Netscape, como condición para que funcione la pizarra.

Figura 29: Arquitectura de SharePoint Portal Server

Sistema de gestión documental (DMS)

Las funcionalidades DMS integradas representan otro módulo importante del SharePoint Portal Server. Se ofrecen las siguientes funciones estándar:

Gestión documental

Gestión de versiones

Flujo de autorizaciones

Control de entrada y salidaDescripción Técnica de los Caminos de Migración

-Publicación de Documentos y Perfiles

-Sucripciones

La administracion de la funcionalidad y el proceso de la documentacion (de ingreso y egreso)esta completamente integrada en la Suite de Oficina de Microsoft.El Share Point Portal Server activa consecuentemente el agupamiento jerarquico de documentos.Esta jeararquia esta expresada a taves del sistema de portal basado en la web, de la misma manera que se maneja el administrador de archivos y carpetas del explorador de Windows.Por ende la propagacion de documentos y su respectiva autorizacion estan contemplados aquí tambien.La version final no sera lanzada hasta que se hallan realizado los chequeos respectivos.

Funciones de búsqueda

El Share Point Portal Server ofrece busqueda de informacion y archivos . Diferentes bases de conocimientos (contenidos internos y externos)seran cubiertos por un motor de busqueda y se haran disponible en una busqueda de texto completa.El usuario puede acceder a un mecanismo de busqueda opuesto (busqueda por perfiles), ademas solo sera visualizable la informacion donde el usuario solamente tenga permisos de acceso.

Los llamados iFilters (filtros de indice) son utilizado para el indexado de documentos. Cuando el documento es visualizado o es agregado un contenido externo, el servidor identifica automaticamente el tipo de documento y aplica el Ifilter apropiado.El filtro asegura dentro de la busqueda completa via texto, que contenidos son extraidos.IFilters soporta actualmente, DOC, XLS, XLM,RTF,PDF, MP3 y ZIP.

Conclusiones

Un analisis compresivo de la situacion ACTUAL y la situacion OBJETIVO, debe ser llevada con un grado de adelantamiento, que permita un correcto funcionamiento de una Intranet basada en Web que sera introducida. Un detallado y preciso concepto debe ser puesto de antemano para la implantacion de un Portal o de un personal responsable del mismo. El portal debe ser adaptado a las necesidades de los empleados y a la compañía para ser una plataforma exitosa.

Los requerimientos pueden ser encontrados usualmente para todo portal de soluciones de este tipo,(incluido la administracion de contenidos y soluciones de manejo), de todas maneras no se debe esperar que los portales de manejo, incluido el Share Point Portal Server sea una solucion “armada”. Cada solucion debe ser adaptada a requerimientos especificos en un mayor o menor nivel de complejidad. Dependiendo de la potencia requerida, en algunos casos es pasible el uso de programacion. Un alto grado de analisis y competencia en el diseño de los negocios es necesario para el diseño de Share Point Portal Server y el tipo de complejidad aplicado para DMS, archivos y soluciones de workflow. El Share Point Portal Server debe ser considerado una solucion dependiendo de los resultados de un analisis profundo de los requerimientos.

Descripción Técnica de los Caminos de Migración

Bases de Datos

Las discuciones tecnicas relacionadas a las migracion de bases de datos, ademas de MS SQL Server 200, como producto de continuidad, dentro del mundo opensource, existen fuertes alternativas que justifican la migracion. Relevantes representantes del opensource son MySQL, PostgreSQL, FireBird y SAP. Mas alla de Oracle y DB2 como productos comerciales, los cuales se hallan disponible y en uso en varias agencias, no estan incluidos en la discuciones de esta guia.

El Software OpenSource mencionado ofrece distintas posibilidades, y su versatilidad debe ser analizada contra los requerimientos en cuestion. Cabe destacara que todas las soluciones opensource son independientes de plataformas, lo que quiere decir que hay versiones descargables e instalables para Windows. Esto muestra que estas bases de datos pueden ser utilizadas en migraciones selectivas.

Introduccion

Los sistemas de bases de datos, son utilizados para mantener, administrar y almancenar una gran cantidad de datos.Los sistemas de bases de datos almancenan coherentemente datos en forma individual o grupal.Estan definidas las relaciones que puede haber entre estructuras y grupos de datos. El uso de una estructura de base de dato bien planificada ayuda a evitar la presencia de elementos de datos redundantes.

Los datos de una base de datos no estan disponibles directamente para el usuario. El acceso tiende a generarse a traves de aplicaciones que le dan la forma correcta de visualizar los datos. Esto implica la configurabilidad de las interfaces de visualizacion entre las bases de datos y la aplicación.Un componente de comunicación asegura la comunicación entre el cliente y los sistemas de servidor.Las aplicaciones que son ejecutadas en los sistemas de cliente, pueden acceder a la base de datos via red.Los servidores de bases de datos deben ser capaces de manejar una gran cantidad de clientes que acceden en paralelo.Las tareas en el servidor implican el evitar los errores logicos acorde a la escritura y lectura paralela por los sistemas cliente.

Las bases de datos estan echas usualmente por dos componentes, por ejemplo , la base de datos real y el sistema de manejo de bases de datos (DBMS). Las funcionalidades del (DBMS) son:

-Monitoreo en la relacion de los datos en la base.

-Monitoreo y aseguramiento del correcto almacenamiento de los datos, tomando la regla de relacion de datos en consideracion.

-Restauracion consistente de datos en caso de perdida o error del sistema, o eventos similares.

Descripción Técnica de los Caminos de Migración

Los DBMS definen tambien los comandos y aplicaciones que deben ser ejecutados en relacion con los datos que deben ser utilizados en la base de datos.El lenguaje mas usado comunmente es el Structured Query Language (SQL).

MS SQL Server 7.0

Microsoft SQL Server 7.0 es un sistema basado en SQL, base de datos relacional cliente-servidor.El sistema de base de datos consiste en el medio de almacenamiento real de datos y el sistema de manejo de datos de la base (DBMS).

Arquitectura del Servidor.

El servidor es el componente del MS SQL Server, el cual recibe instrucciones SQL de los clientes y opera las acciones correspondientes.

El cliente envia las peticiones usando un protocolo que al nivel aplicación es especifico para MS SQL Server, y es referido como un Tabular Data Stream (DTS). Versiones 4.2 y 7 son soportadas.Los respectivos paquetes son generados por el proveedor DB OLE, y el ODBC-driver para MS SQL Server. Los paquetes TDS son enviados via protocolo de red usados en el servidor, y por otra parte al cliente. El servicio abierto de datos de MS SQL Server administra los paquetes de datos y llama a funciones relacionales, en el MS SQL Server.

[cuadro]

EL servidor real de bases de datos consiste en dos componentes., el modulo relaciona y el modulo de almacenamiento. Ambos modulos se comunican via OLE DB-API.

Las funciones del modulo relacional consiste en el analisis de las peticiones SQL, la optimizaciones de los planes de ejecucion, y la ejecucion de las operaciones depositadas en el plan de ejecucion.

Las tares del modulo de almacenamiento incluyen lo siguiente:

- Gestión de archivos y del espacio de memoria

-Gestión del buffer de datos y de las operaciones de entrada/salida

-Administración y deshabilitación de transacciones

-Entrada y restauración

-Implementación de las funciones del servicio (Backup, restauración, DBCC y copia masiva)

3.13.3.2 Arquitectura de la base de datos

El dato en la base de datos está estructurado dentro de los componentes lógicos que, por su parte, están almacenados en forma de archivos en el volumen de datos. Cuando trabaja con la base de datos, el usuario principalmente usa los componentes lógicos ( tablas, vistas, procedimientos de almacenamiento etc)

Toodas las instalaciones de MS SQL Server incluyen varias bases de datos, por ejemplo, un total de cuatro sistemas de bases de datos mas una o más bases de datos de usuario. Detrás del sistema de bases de datos, el contenido real de bases de datos debe de ser creado despues de la instalación. Estras productivas bases de datos estan organizadas en forma de difrentes objetos. La tabla inferior contiene los componentes mas importantes que existen como objetos en MS SQL Server.

Tabla 19:

(Continuacion tabla)

...

Microsoft SQL Server no es accedido directamente por el usuario. Se usan aplicaciones especiales para acceder a los datos. Podemos acceder a MS SQL Server de las formas siguientes:

- Programas de MS SQLServer

- Programas de terceras compañías

- Programas desarrollados por agencias públicas.

MS SQL Server es accedido via API(interface de programación de la aplicación) de la base de datos que consiste en las dos partes siguientes: Las declaraciones del lenguaje que son pasadas a las base de datos y un conjunto de funciones o de interfaces y metodos orientados a objetos que envian cada declaracion del lenguaje a la base de datos y procesan los resultados. Las declaraciones del lenguaje usadas por MS SQL Server son Transact-SQL, con todas las declaraciones del nivel de entrada de SQL-92 y demás caracterísiticas SQL-92 ( de los niveles intermedios y superior) soportadas. Además están también diponibles extensiones Transac-SQL especificas de Microsoft.

MS SQL Server soporta dos clases principales de APIs de bases de datos:

- OLE DB- El sistema soporta aplicaciones escritas mediante OLE DB o APIs que usen OLE DB (como ActiveX Data Objets (ADO)). Además, los objetos y componentes que usen OLE DB son también soportados( Como activeX y aplicaciones Windows DAN)

- ODBC – El driver soporta aplicaciones y componentes escritos mediante ODBC

Además, MS SQL Server soporta la librería DB y Embedded SQL

3.13.3.4 Componentes de comuncación.

Están soportados varios métodos de comunicación entre las apliaciones cliente y el servidor. La comunicación en en un ordenador entre servidor y apliación usa tecnologías de expansión de proceso, como la Named Pipes o

DESCRIPCION TECNICA DE LAS RUTAS DE MIGRACION

Memoria Compartida. Las aplicaciones que corren en otro sistema cliente usan la Comunicación InterProcesos de red (IPC). IPC está basado en el API y los protocolos de red. Los siguientes protocolos están disponibles:

TCP/IP

Novell IPX/SPX

Apple Talk

Banyan VINES

3.13.3.5 Escalabilidad

Microsoft SQL Server está diseñado para administrar bases de datos que pueden tener una tamaño de un terabyte o más. MS SQL Server incluye ciertas características diseñadas para aumentar la eficiencia del sistema de base de datos.

MS SQL Server maximiza el grado de acceso paralelo a los datos seleccionando un nivel de bloqueo adecuado. El acceso es optimizado por procesos con bloqueo dinámico en los niveles de línea y/o tabla.

El sistema de base de datos soporta ambientes VLDB (Very Large Database) con volúmenes de base de datos de un terabyte e incluso más. Las órdenes Transact-SQL BACKUP y RESTORE pueden escribir en medios de respaldo múltiples en paralelo y crear respaldos incrementales.

Un optimizador de consulta integrado en MS SQL Server acelera los procesos que manejan consultas. Los planes de ejecución paralela pueden configurarse para el propósito de soportar máquinas multiprocesador de forma de distribuir las consultas SQL.

MS SQL Server soporta consultas distribuidas. Las órdenes Transact-SQL que refieren a fuentes de bases de datos OLE DB heterogéneas pueden ser ejecutadas.

La integridad de los datos durante las actualizaciones (modificaciones) está asegurada por el hecho de que las actualizaciones siempre terminan con un estado consistente. Si ése estado consistente no es alcanzado, toma lugar un rollback al punto inicial (esto es, al último estado consistente).

Además, las transacciones distribuidas son posibles, con un manejador de transacciones manejando ésas transacciones distribuidas.

3.13.3.6 Control de Acceso

MS SQL Server ofrece dos tipos de autenticación de usuario:

Autenticación de SQL Server

Deben existir las cuentas y claves de ingreso adecuadas en el MS SQL Server – ésas no tienen relación con las cuentas de usuario NT. El pedido de ingreso y clave tiene lugar directamente en MS SQL Server.

Autenticación de Windows NT

Aunque las cuentas y grupos de Windows NT deben ser incluidos en MS SQL Server, la autenticación misma toma lugar en el dominio NT.

Página 168 Versión: 29.08.2003

DESCRIPCION TECNICA DE LAS RUTAS DE MIGRACION

El administrador puede decidir si la autenticación tomará lugar a través de Windows NT o en modo híbrido.

3.13.3.7 Integración del Sistema

MS SQL Server soporta la utilización de cuentas de usuario y dominio de Windows NT, de forma que la autenticación de Windows NT está disponible para MS SQL Server. Los usuarios no son autenticados por MS SQL Server, con el servidor realizando una conexión confiable a los sistemas cliente.

Además de la integración con el sistema de autenticación de usuarios de NT, MS SQL Server puede ser conectado íntimamente con los siguientes productos:

Servicio de almacenamiento de datos para el Microsoft Internet Information Server el cual es normalmente utilizado para la generación de contenido web dinámico basado en ASP

Como una característica de almacenamiento de datos para el Sites Server el cual es utilizado para la administración de sitios web

3.13.3.8 Administración

Varias herramientas están disponibles para la administración de MS SQL Server.

MS SQL Server Agent

Posibilita la preparación y planificación de tareas a ser ejecutadas una vez o periódicamente. Mensajes de advertencia pueden ser generados cuando ciertas condiciones del sistema ocurren.

MS SQL Server Profiler

Posibilita el monitoreo y análisis de la carga de red durante las transmisiones desde y hacia un servidor.

MS SQL Server System Monitor

Posibilita la integración con el monitor de sistema de Windows NT el cual monitorea la performance del servidor SQL y la presentación gráfica de ésos datos.

MS SQL Server Enterprise Manager

Esto agrega un componente al Microsoft Management Console (MMC) para manejar el MS SQL Server.

Asistente de Optimización de Indices

Esto posibilita el análisis del uso de índices en órdenes SQL.

Además, los SQL Distributed Management Objects (SQL-DMOs) posibilitan la integración de tareas de automatización dentro de las aplicaciones. Las tareas recurrentes también pueden ser implementadas como trabajos.

3.13.4 Migración de reemplazo

Las bases de datos, o más precisamente, los sistemas de manejo de bases de datos relacionales (RDBMS), han preparado el camino para la utilización de Linux en áreas de aplicaciones empresariales críticas. El Software Workgroup lanzó AdabasD ya en 1997 como una RDBMS completamente comercial (y en aquella época certificada por SAP) para Linux. Oracle e Informix siguieron el ejemplo en 1998, dando un fuerte empujón a la credibilidad de Linux en el

Versión: 29.08.2003 Página 169

DESCRIPCION TECNICA DE LAS RUTAS DE MIGRACION

ambiente profesional. La combinación de Linux, Apache, MySQL y PHP la cual es conocida con el acrónimo “LAMP” ha sido una de las infraestructuras más populares para sitios de comercio web y sitios dinámicos desde el inicio del uso comercial de la Internet. PostgreSQL, Firebird y SAP DB constituyen un rango completo de RDBMS de escala completa con soporte de transacciones, triggers y procedimientos almacenados incluso bajo licencias Open Source. No hay ciertamente carencia de opciones de alta calidad para el uso de Linux y software Open Source en el campo de los sistemas de base de datos.

Los RDBMS juegan un papel especial dentro del marco de una estrategia de migración en que ellos siempre están conectados a aplicaciones donde los datos son manejados por RDBMS. Eso significa que un cambio también requiere por una lado un cambio en los almacenes de datos y por otro lado posiblemente incluso en las aplicaciones.

Dentro de una organización, los datos está idealmente sólo en un sistema de base de datos y en forma normalizada (sin redundancia). El lenguaje de consultas (SQL) utilizado por las aplicaciones en la base de datos está idealmente estandarizado, y cada aplicación debería trabajar correctamente con cualquier RDBMS. La realidad desafortunadamente muestra que en la mayoría de las infraestructuras IT son mantenidas muchas RDBMS con algunas veces datos redundantes en diferentes bases de datos. Eso significa que éso datos son consultados por las diferentes aplicaciones en dialectos SQL diferentes y con extensiones de lenguaje específicas de los fabricantes así como a través de interfaces específicas de los fabricantes. Incluso si la comunicación con la base de datos a través de ODBC o JDBC está estandarizada, e incluso si no se utilizan triggers o procedimientos almacenados, el driver ODBC/JDBC debe ser reemplazado en el extremo cliente en el caso de una migración de la base de datos.

Contra ésas experiencias, la migración ofrece la oportunidad de consolidar software y estructuras de datos aunque éso obviamente no sea fácil de lograr.

Estas consideraciones iniciales sugieren que una alternativa a la continuación de la migración debería considerarse sólo en los siguientes casos:

El RDBMS que está corriendo actualmente bajo Windows está también disponible para un sistema operativo Open Source (como pasa con Oracle sobre Linux). Eso significa que el sistema de base de datos permanece en su lugar como software comercial. En una infraestructura de servidores basados en Linux, ésta variante también ofrece ventajas desde el punto de vista del administrador. Sin embargo, es improbable que una versión Linux sea lanzada para MS SQL.

Las aplicaciones están enlazadas a RDBMS heredados a través de ODBC o JDBC. En ése caso, los datos pueden ser exportado a otro sistema de base de datos y la conexión cliente puede ser redirigida al nuevo RDBMS reemplazando el driver ODBC (en el nivel de sistema con el cliente). Sin embargo, los detalles son un problema en éste caso. Si la aplicación utiliza procedimientos almacenados o triggers, ésos deben ser portados también. (Eso es posible ocasionalmente también sin ningún cambio en el software cliente).

La aplicación es una aplicación Microsoft Access con almacenamiento de datos basados en archivos. En ése caso, los datos pueden ser importados muy fácilmente a un DBMS central y la aplicación Access puede modificarse para usar la interfaz ODBC.

Página 170 Versión: 29.08.2003

DESCRIPCION TECNICA DE LAS RUTAS DE MIGRACION

El cliente está disponible como texto fuente y puede ser adaptado al nuevo RDBMS dentro del marco del proyecto de migración. Aparte de los factores mencionados anteriormente (esto es, triggers y procedimientos almacenados), el esfuerzo de migración también depende de la interfaz de programación utilizada. Si la aplicación de base de datos fue implementada directamente a través de una interfaz del fabricante (como ser SQL empotrado), el esfuerzo de migración será significativamente mayor que en el caso de un nivel de abstracción intermedio, como ser ActiveX Data Objects (ADO).

Finalmente otra opción es cooperar con el fabricante de una aplicación como otra forma de lograr la migración de la base de datos. Muchos proveedores de aplicaciones de base de datos comerciales también consideran como una desventaja de mercado la relación fija con un RDBMS particular, así que también puede asumirse que existe una disposición substancial y creciente para la migración, especialmente hacia un RDBMS Open Source.

Si la migración de la base de datos es posible en general, un RDBMS adecuado deber ser seleccionado como el sistema objetivo. Esta guía de migración se enfoca en bases de datos Open Source como potenciales sistemas objetivo. El resumen abajo (Tabla 20) muestra los sistemas de base de datos actualmente disponibles bajo la licencia Open Source:

Tabla 20: Sistemas de base de datos disponibles bajo la licencia Open Source

Los sistemas hash no tienen organización relacional. Los últimos cuatro sistemas con interfaz SQL son los mejores candidatos para la migración. Esos cuatro sistemas serán descriptos a continuación.

Versión: 29.08.2003 Página 171

DESCRIPCION TECNICA DE LAS RUTAS DE MIGRACION

3.13.4.1 MySQL

MySQL es desarrollada y distribuida por la compañía sueca homónima. La base de datos está sujeta a la GPL y por lo tanto constituye software libre. Ya que las interfaces de programación también están sujetas a la GPL, los programas enlazados a ellas también deben estar sujetos a la GPL tan pronto son distribuidos y/o lanzados al mercado con propósitos comerciales. Alternativamente, MySQL AB también ofrece licencias comerciales las cuales posibilitan que los proveedores de aplicaciones comerciales usen MySQL sin la necesidad de que su propio software esté sujeto a la GPL. MySQL ofrece soporte y acuerdos de servicios normales, capacitación así como servicios de consultoría.

Los fabricantes estiman el número de instalaciones de la base de datos en 4 millones en todo el mundo. Más popular es MySQL junto con Linux, Apache y PHP para la creación de sitios web dinámicos.

MySQL puede utilizar el mismo interfaz (SQL Parser) sobre diferentes motores para el almacenamiento de datos. Con innoDB como motor, MySQL también ofrece soporte para transacciones. Los procedimientos no están disponibles actualmente en MySQL. De acuerdo al fabricante, estarán disponibles a partir de la versión 5.0.

MySQL también puede ser compilada con soporte para OpenSSL en cuyo caso el cliente y el servidor pueden comunicarse a través del protocolo Secure Socket Layer (SSL) utilizando certificados X.509.

Los archivos son típicamente almacenados en el sistema de archivos con MySQL. Las estructuras de datos no utilizan más capacidad de disco que la requerida realmente para almacenar los contenidos. La asignación de espacio en disco para una tabla o base de datos no es necesaria. Un sólo servidor activo de base de datos puede administrar cualquier cantidad de instancias de base de datos.

MySQL es generalmente muy liviana y extremadamente rápida durante todos los accesos de lectura. Es utilizada típicamente para almacenes de datos pequeños y medianos y para aplicaciones simples. Sin embargo, la lista de referencia de MySQL AB muestra que la base de datos también es adecuada para grandes aplicaciones y almacenes de datos y que puede claramente competir con cualquier sistema de base de datos completamente comercial.

3.13.4.2 PostgreSQL

PostgreSQL tiene sus orígenes en la base de datos Postgres diseñada en la UCB en 1986, y está sujeta al copyright BSD. En 1995, el lenguaje de consultas de base de datos fue cambiado a SQL. El desarrollo es llevado a cabo por una gran comunidad diseminada por todo el mundo aplicando métodos puramente open source. En línea con el modelo comunitario, varias compañías ofrecen productos y servicios relacionados a PostgreSQL.

PostgreSQL posibilita que los usuarios definan sus propias funciones en diferentes lenguajes de programación las cuales pueden devolver tanto valores individuales así como tuplas e incluso tablas enteras. Eso significa que ésas funciones ofrecen un rango más amplio de opciones que el ofrecido por los procedimientos definidos por el usuario. Otra característica especial del concepto de PostgreSQL es el concepto de control el cual se extiende más allá de la funcionalidad de los simples triggers. Gracias al amplio proceso comunitario, PostgreSQL trae una rica funcionalidad, es muy flexible y es así adecuado para las más variadas aplicaciones, y constituye un sistema muy seguro. PostgreSQL ofrece, por ejemplo,

Página 172 Versión: 29.08.2003

DESCRIPCION TECNICA DE LAS RUTAS DE MIGRACION

una encriptación muy poderosa tanto para autenticación como para comunicación de datos en base a certificados X.509.

Los datos son almacenados en el sistema de archivos con PostgreSQL. La asignación de espacio para la base de datos o para tablas no es necesaria; la asignación a áreas de memoria diferentes es posible incluso retroactivamente. Un servidor de base de datos puede servir múltiples instancias de la base de datos. PostgreSQL utiliza, de forma similar a Oracle, un sistema de vista el cual en contraste a los mecanismos de bloqueo convencional posibilita el bloqueo de la base de datos incluso durante operaciones en progreso con niveles de performance altos. El sistema de respaldo de datos es consistente en ése contexto.

PostgreSQL es liviano y al mismo tiempo ofrece una funcionalidad poderosa. Es usado típicamente para almacenes de datos medianos. Una herramienta de administración para Windows puede utilizarse para enlazar un Asistente de Migración para bases de da datos Access, de forma que la importación de datos desde Access puede ser automatizada en gran medida.

3.13.4.3 Firebird

Firebird apareció a mediados del año 2000 como un proyecto independiente de la base de datos InterBase, versión 6.0 la cual Borland había liberado como Open Source. Una comunidad pequeña y comprometida está trabajando en el desarrollo posterior de ése sistema de base de datos. La documentación consta principalmente de archivos PDF de Interbase. No es esperable una actualización en éste momento. Algunas interfaces que existen sólo para Interbase serán omitidas durante el curso del desarrollo posterior. Firebird no es aún un candidato adecuado para su uso profesional como RDBMS.

3.13.4.4 SAP DB

El SAP DB fue lanzado como un proyecto de investigación universitario en Technische Universität Berlin. Los inicios incluso llegan hasta 1977. En los 1980, el sistema fue desarrollado más y vendido por Nixdorf bajo el nombre DDB/4. Entonces paso a través de Siemens/Nixdorf al Software Workgroup donde fue continuado bajo del nombre de ADABAS D. En 1997, SAP adquirió los derechos de explotación irrestrictos al Software Workgroup y desde entonces ha continuado desarrollando la base de datos bajo el nombre SAP DB. En el 2000, el SAP DB fue puesto bajo la GPL, sin embargo, sin la reducción de la inversión de SAP en su desarrollo posterior. EL SAP DB es ofrecida por SAP como una plataforma certificada para casi todas las soluciones SAP y es utilizada como tecnología central en muchos productos. La funcionalidad incluye no sólo soporte de transacciones, sino también triggers y procedimientos almacenados.

El principal foco de desarrollo futuro y de trabajo de control de calidad fue puesto en la funcionalidad requerida en conjunción con las soluciones SAP. Ya que la lógica de negocios entera corre en el servidor de aplicaciones SAP, el sistema de base de datos es utilizado principalmente para el almacenamiento y suministro performante de datos relacionales. Los procedimientos almacenados no tienen un rol aquí. De acuerdo con éso, el SAP DB todavía carece de versatilidad y flexibilidad en ése respecto.

El SAP DB utiliza volúmenes para el almacenamiento de datos los cuales son creados en el sistema de archivos o sobre dispositivos crudos los cuales en cada caso son completamente asignados a una instancia de la base de datos.

Versión: 29.08.2003 Página 173

DESCRIPCION TECNICA DE LAS RUTAS DE MIGRACION

La base de datos tiene libertad de reorganización, con la posibilidad de crear respaldos durante operaciones en progreso sin afectar la performance.

El SAP DB es el peso pesado entre las bases de datos Open Source. Es un candidato como objetivo de migración para bases de datos Access sólo en caso excepcionales.

3.13.4.5 Conclusiones provisionales

Un amplio rango de atractivos objetivos de migración son ofrecidos en el área Open Source.

No es posible hacer una decisión general, simple y clara en favor de uno u otro sistema en base de sus respectivas funcionalidades características.

Los cuatro sistemas de base de datos SQL descriptos son independientes de la plataforma. Los cuatros sistemas de base de datos, en particular, pueden ser descargados desde Internet como versiones Windows listas para su instalación.

Para soportar una comparación detallada de los posibles sistemas objetivo de un proyecto de migración, una comparación exacta de la lista de funcionalidades es necesaria con una visión de las funcionalidades de base de datos que son realmente utilizadas en el sistema original.

Una buena visión general puede hallarse en http://www.mysql.com/information/features.

La siguiente tabla (Tabla 21) provee algo de asistencia adicional:

Tabla 21: Visión de los sistemas de base de datos SQL

Página 173 Versión: 29.08.2003 DESCRIPCIÓN TÉCNICA DE LOS MODELOS DE MIGRACIÓN

Versión: 29.08.2003 Página 175

3.13.4.6 Notas

Cuando se importan datos de tipos que no existen con idéntica forma en el sistema de destino, se suele poder identificar un tipo adecuado con un mayor rango de valores. No obstante, tanto durante la importación de datos como durante la transición a una conexión ODBC, se debe garantizar que la interfaz ODBC cuenta con sus propios conceptos y definiciones de tipos de datos.

3.13.4.7 Recomendaciones para lograr la independencia

En aquellos casos en que no se recomienda una migración total, se pueden dar algunas recomendaciones relativas a la programación de la base de datos para facilitar una futura migración.

No se deben utilizar procedimientos almacenados y extensiones exclusivas de cada desarrollador.

Si los programas o las funciones del negocio han de mudarse del cliente al servidor, las arquitecturas de 3 capas son a día de hoy un buen método. Para lograr una implantación independiente de plataformas, Java es un buen candidato tanto para los clientes como para el servidor de aplicaciones (Tomcat).

Para conectar la base de datos, han de utilizarse las interfaces estándares (ODBC, JDBC, etc.), o bien añadir un nivel de abstracción que pueda cambiarse a voluntad a ODBC, JDBC o a otras interfaces sin efectuar cambios en el código del programa.

Las expresiones SQL han de aislarse e implantarse como módulos en el código del programa.

3.13.5 Migración progresiva

3.13.5.1 SQL Server 2000 de Microsoft

MS SQL Server 2000 vio la integración de nuevas funciones web. El desarrollo posterior se ha centrado en las funciones XML y en posibilidades de ampliación mejoradas. Las funciones nuevas más importantes serán descritas en la siguiente sección.

Internet y intranet

La siguiente tabla (tabla 22) muestra las extensiones más importantes de MS SQL

Server 2000 en el campo de soluciones para Internet e intranet.

DESCRIPCIÓN TÉCNICA DE LOS MODELOS DE MIGRACIÓN

Página 176 Versión: 28.09.2003

Tabla 22: Soluciones ampliadas para Internet e intranet con MS SQL Server 2000

La tabla resume las nuevas prestaciones más importantes relativas a las opciones de administración y desarrollo de Microsoft SQL Server 2000.

Tabla 23: Funciones de administración y desarrollo

67 Las funciones ampliadas de la versión Enterprise Edition no se tratan aquí. Se describen en Libros Blancos y otras descripciones técnicas.

DESCRIPCIÓN TÉCNICA DE LOS MODELOS DE MIGRACIÓN

Versión: 29.08.2003 Página 177

3.14 Programas de trabajo en grupo

3.14.1 Conceptos básicos

Las discusiones técnicas relativas a la migración de programas para trabajo en grupo y mensajería se centran tanto en el desempeño de funciones de Exchange 5.5 mediante soluciones alternativas que se pueden instalar en sistemas basados en Linux y en la continuación con Exchange 2000. En cuanto a la migración total, el uso de entornos de sistema heterogéneos con servidores Linux y clientes Windows con Outlook de Microsoft que siguen utilizándose a pleno rendimiento es un aspecto fundamental de los análisis técnicos.

El análisis sugiere que dos de las soluciones estudiadas son especialmente aptas porque cumplen el requisito de conexión en tiempo real. Este tipo de conexión permite el uso sin conflictos de las funciones de trabajo en grupo. Las dos soluciones son Samsung Contact, una solución comercial basada en HPOpenMail por un lado, y en Exchange4Linux por el otro. La última es una solución con servidor disponible como software libre con un conector restrictivo disponible como módulo de software comercial. Exchange4Linux

puede ampliarse hasta un máximo de 500 usuarios y, por lo tanto, es mas adecuada para administraciones públicas más pequeñas. Samsung Contact es especialmente apta para su uso en organismos públicos medianos y grandes. Otra solución de software de código libre es Kroupware, que puede conectarse a Outlook mediante el conector comercial Bynari Connector. Kroupware sigue estando sujeto a una restricción: aún no existe suficiente experiencia en funcionamiento real. El producto comercial OpenExchange de SuSE se puede utilizar en casos donde la conexión en tiempo real no sea un requisito indispensable. Además, la conexión en tiempo real también garantiza que las funciones de Exchange 5.5 quedan cubiertas hasta el último detalle. Una excepción en todos los casos es el uso de fórmulas no cubiertas por ninguna de las soluciones estudiadas. Aparte del uso en sistemas heterogéneos, la implantación en entornos de sistema enteramente basados en Linux siempre desempeña un papel clave y, por lo tanto, la cuestión del software cliente que puede servir como alternativa a Outlook de MS. En este sentido, Samsung

Contact es la única solución que viene con un cliente integrado basado en Java e independiente de plataformas. Si bien los clientes web pueden utilizarse en todas las soluciones estudiadas, su uso está sujeto hasta cierto punto a algunas restricciones funcionales. El uso sin conexión, en concreto, no es posible con estos clientes web. No obstante, las funciones de correo se pueden emplear con todos los clientes compatibles con POP 3 e IMAP. En cuanto a la migración progresiva a Exchange 2000 de MS, se puede resumir diciendo que esta introducción sólo es posible si se combina con la introducción de directorios activos. Esto, por tanto, requiere una decisión estratégica fundamental, por lo que en este punto deberían consultarse una vez las discusiones técnicas de AD del capítulo 3.7.

DESCRIPCIÓN TÉCNICA DE LOS MODELOS DE MIGRACIÓN

Página 178 Versión: 28.09.2003

3.14.2 Introducción

Como ya se ha mencionado en el capítulo 2, se puede suponer que la mayoría de administraciones públicas utilizan Exchange como solución de trabajo en grupo. Esta es la razón por la que la situación de partida se describirá en primer lugar, seguida de una discusión sobre diferentes soluciones de trabajo en grupo que se pueden utilizar sobre sistemas operativos basados en Linux con vistas a una migración total. Se tratarán tanto los proyectos de código abierto enteramente como los productos comerciales. Los enfoques, objetivos y grupos objetivo de los productos son a veces muy diferentes. No obstante, se puede hacer una distinción general entre soluciones basadas totalmente en la web y soluciones clásicas de cliente y servidor. A la vista del gran número de soluciones diferentes, no es posible tratar todas las soluciones disponibles en el mercado. Las soluciones examinadas han sido seleccionadas en función de las diferentes situaciones y requisitos. Exchange 2000 de MS y, en cierta medida, incluso Exchange 2003 de MS serán examinados por su utilidad en migraciones progresivas.

3.14.3 Situación de partida: Exchange 5.5 de Microsoft

Las prestaciones y funciones más importantes de las soluciones de trabajo en grupo de Microsoft se describen aquí tomando como referencia su versión 5.5.

3.14.3.1 Infraestructura básica

Exchange Server de Microsoft requiere una estructura de dominio sobre Windows NT 4 como base para la autenticación.

3.14.3.2 Unidades de la estructura lógica

La unidad estructural más grande de Exchange Server de Microsoft es la organización. Ésta puede extenderse en varios dominios NT. Además, Exchange emplea las ubicaciones como medio de estructuración. Una ubicación combina lógicamente un grupo de servidores Exchange que se comunican entre ellos mediante una conexión rápida de red. Los servidores Exchange de una ubicación sirven a los demás los mensajes de correo electrónico y replican la información de directorios directamente. El encaminamiento de correo entre ubicaciones debe configurarse explícitamente. Una ubicación es una unidad de administración.

3.14.3.3 Componentes básicos

Exchange Server de Microsoft consta de los siguientes componentes básicos:

Directorio de Exchange (servicio de directorios o DS)

Agente de transferencia de mensajes o Message Transfer Agent (MTA)

Almacenamiento de información o Information Store (IS)

Asistente del sistema o System Attendant (SA)

El directorio de Exchange guarda toda la información acerca de los usuarios, las fuentes y la organización en una base de datos (dir.edb). Esto incluye listas de los usuarios de correo electrónico registrados en el servidor, así como los nombres de los servidores y sus configuraciones.

DESCRIPCIÓN TÉCNICA DE LOS MODELOS DE MIGRACIÓN

Versión: 29.08.2003 Página 179

Es importante señalar que toda la información de configuración se guarda en el directorio. El almacén de información consta de dos bases de datos: el "Almacén de Información Privada" (priv.edb) y el "Almacén de Información Pública" (pub.edb). El primero guarda los mensajes y sus adjuntos para aquellos usuarios cuyos buzones están ubicados en el servidor en cuestión. El segundo guarda el contenido de las réplicas de carpetas públicas.

El Agente de transferencia de mensajes (MTA) envía los mensajes a otros servidores, ubicaciones y sistemas externos. Junto al directorio de Exchange, el MTA decide cómo encaminar cada mensaje. El MTA redirecciona los mensajes entrantes al almacén de información. El MTA también convierte mensajes a diversos formatos.

El Asistente del sistema es la unidad de administración de servidores Exchange. Este componente puede utilizarse, por ejemplo, para generar nuevos usuarios de correo electrónico y para llevar a cabo tareas de control y asistencia. El asistente del sistema controla las conexiones de red con otros servidores Exchange y prepara tablas de encaminamiento.

La siguiente tabla (tabla 24) muestra los componentes correspondientes y describe brevemente sus funciones.

Tabla 24: Componentes básicos de Exchange 5.5

DESCRIPCIÓN TÉCNICA DE LOS MODELOS DE MIGRACIÓN

Página 180 Versión: 28.09.2003

Los componentes modulares opcionales, como los diferentes conectores y el servidor de gestión de claves, pueden ampliar las funciones del servidor Exchange. Los conectores se emplean para transmitir mensajes entre diferentes sistemas o ubicaciones.

Conector de ubicaciones y conector para réplicas de directorios (conexión de ubicaciones para conformar un sistema de nivel empresarial)

Conector RAS dinámico (conecta ubicaciones mediante marcación asincrónica)

Servicio de correo de Internet o Internet Mail Service (conecta ubicaciones mediante SMTP o el sistema Exchange e Internet)

Servicio de noticias de Internet o Internet News Service (conecta a Exchange mediante NNTP a las noticias de Internet)

Mail Connector and Directory Synchronization de MS (permite conectar sistemas de correo 3.x de MS)

Conector Schedule+ Free/ Busy de Microsoft

Conector X.400 (conecta ubicaciones de Exchange a sistemas X.400 externos controlando el ancho de banda dedicado)

Conector para cc:Mail (conecta Exchange a sistemas cc:Mail de Lotus).

Se puede distinguir entre conectores internos y externos: los primeros conectan dos ubicaciones de Exchange y constituyen básicamente objetos lógicos que facilitan las tareas de administración; los segundos son además un medio para conectar el servidor Exchange de Microsoft a otros sistemas de correo. Los conectores garantizan la correcta conversión del contenido de los mensajes y de las direcciones de los mensajes. De este modo, los mensajes creados con Exchange se pueden leer en sistemas externos y aquellos cuyo origen se encuentra en sistemas externos pueden ser leídos por los usuarios de Exchange de Microsoft.

El servidor de gestión de claves (KMS) se puede emplear para gestionar claves de transmisión cifrada de mensajes y para adjuntar firmas digitales a los mensajes.

DESCRIPCIÓN TÉCNICA DE LOS MODELOS DE MIGRACIÓN

Versión: 29.08.2003 Página 181

El servidor de chat es otro componente opcional. Sirve para implantar lo que se conoce como "Internet Relay Chats" (IRCs) que, a su vez, permite a grandes números de usuarios comunicarse simultáneamente entre ellos.

El conocido como servicio de scripts de servidor o Server Scripting Service también funciona desde la versión 5.5. Este servicio garantiza que los scripts escritos en un lenguaje como Perl, VB Script o JScript se pueden albergar en una carpeta pública. El servicio garantiza la ejecución de programas tan pronto como ocurren los eventos específicos. Los scripts se pueden utilizar para automatizar tareas.

3.14.3.5 Protocolos compatibles

Exchange admite toda una gama de protocolos diferentes; los más importantes se examinan en la siguiente sección.

El protocolo simple de transmisión de correo o Simple Mail Transfer Protocol (SMTP) es un protocolo estándar para trasmitir mensajes a través de Internet.

El protocolo POP3 se usa para enviar mensajes a ordenadores cliente que no están conectados de forma permanente. Este estándar ha sido diseñado para intercambiar información entre clientes de correo electrónico y servidores conectados sólo a intervalos de tiempo. Los clientes de correo emplean POP3 para leer mensajes y SMTP para enviarlos.

El estándar IMAP4, compatible con la mayoría de los productos de correo electrónico está basado en un enfoque diferente. El mayor punto fuerte de IMAP4 frente a POP3 es su capacidad para cargar mensajes del servidor de forma selectiva. De este modo se puede, por ejemplo, descargar mensajes sin sus adjuntos.

Gracias a la integración con HTTP, los documentos de las carpetas públicas se pueden manipular a través de Internet. El uso de Microsoft Internet Information Server (IIS) y de Exchange Server 5.5 permiten a los usuarios de Outlook Web Access (OWA) acceder a funciones que de otro modo sólo estarían a su disposición mediante el cliente Outlook. La información se genera mediante páginas activas del servidor, de forma que la compatibilidad con HTTP consiste en una extensión de Internet Information Server. HTTP requiere por tanto un Internet Information Server con capacidad ASP. Los usuarios pueden, por ejemplo, ver carpetas públicas y privadas, enviar y recibir correo electrónico, y hacer uso de muchas otras funciones. No obstante, el uso de todas las funciones depende de Internet Explorer de Microsoft. NNTP permite la diseminación de grupos de noticias a nivel mundial. El contenido de los grupos de noticias se envía de servidor a servidor mediante NNTP. El servidor Exchange puede publicar el contenido de los grupos de noticias en carpetas públicas a través de la conexión NNTP. El LDAP permite a los clientes acceder a la información de directorios de los directorios del servidor Exchange de Microsoft.

DESCRIPCIÓN TÉCNICA DE LOS MODELOS DE MIGRACIÓN

Página 182 Versión: 28.09.2003

3.14.3.6 Variantes de productos

Exchange Server 5.5 se utiliza en dos versiones diferentes:

Standard Edition

Enterprise Edition

La edición empresarial es compatible con granjas de intercambio de dos nodos basados en la edición Windows NT 4 Enterprise.

3.14.3.7 Funciones para los usuarios

El usuario tiene a su disposición funciones que resultan de la propiedad de su buzón:

Recepción y envío de correo electrónico

Gestión de tareas

Calendario

Listas de direcciones (agendas generales y contactos personales)

Registros y notas

Esta guía asume que el software cliente habitual es Outlook de Microsoft. Outlook está disponible en versiones 97 (Ver. 8), 98 (Ver. 8.5), 2000 (Ver. 9) y 2002 (Ver. 10, XP).

Outlook y Exchange permiten guardar y editar datos sin conexión y la posibilidad de sincronizarlos a continuación cuando se disponga de conexión a la red (el caso más habitual de los ordenadores portátiles).

La propia Outlook ofrece la función PIM (gestión de información personal o Personal Information Manager), que permite utilizar carpetas personales almacenadas como archivos (*.pst). Los buzones y flujos de trabajo de grupo se pueden poner a disposición de todos los usuarios en carpetas públicas. El uso de carpetas públicas permite el uso compartido de información. Los usuarios que tengan los privilegios de acceso necesarios pueden leer y/o guardar la información almacenada en las carpetas.

3.14.3.8 Client-to-server communication

La comunicación entre cliente y servidor en un entorno común de redes de área local con clientes Outlook se establece mediante MAPI (interfaz de programación de aplicaciones de mensajería o Messaging Application Programming Interface) y, por lo tanto, a través de RPC (llamada de procedimiento remoto o Remote Procedure Calls). Gracias a la compatibilidad con SMTP, POP3, IMAP y HTTP, se pueden solucionar las situaciones de comunicación entre cliente y servidor más variadas.

3.14.3.9 Comunicación entre servidores

La comunicación entre servidores Exchange se puede controlar mediante diferentes conectores. Dos servidores instalados en la misma ubicación se pueden comunicar por RPC.

DESCRIPCIÓN TÉCNICA DE LOS MODELOS DE MIGRACIÓN

Versión: 29.08.2003 Página 183

3.14.3.10 Problemas relacionados

El uso de sistemas de correo implica una mayor exposición a los ataques con virus. Exchange permite a los desarrolladores implantar programas antivirus utilizando la API antivirus específicamente creada con este propósito. La integración de soluciones de FAX en entornos Exchange se logra con aplicaciones de numerosos desarrolladores. El archivado de correo electrónico o la transferencia de objetos de correo no utilizados durante cierto tiempo (gestión de almacenamiento jerárquico o hierarchical storage management, HSM) se puede llevar a cabo con software de terceros.

3.14.4 Migración total

El objetivo concreto de una migración total puede variar según la aplicación de que se trate. Los requisitos que ha de satisfacer un programa de trabajo en grupo han de determinarse con precisión antes de comenzar la migración. La siguiente lista contiene algunos ejemplos de criterios para la selección de soluciones de trabajo en grupo:

¿Qué sistemas cliente han de ser compatibles?

Clientes web únicamente

Clientes Outlook (compatibilidad MAPI)

Sistemas cliente basados en Linux

Clientes de entornos heterogéneos (sistemas basados en Windows y en Linux)

¿Qué funciones de trabajo en grupo ha de proporcionar el nuevo sistema?

¿Qué posibilidades de ampliación han de ofrecer los sistemas?

Etcétera.

La verificación de los requisitos de un nuevo producto de trabajo en grupo es un ejercicio obligatorio que ha de efectuarse antes de emprender el proyecto.

3.14.4.1 phpGroupware

La solución "phpGroupware"68, sujeta a la licencia pública general o GPL es una representante de las soluciones basadas por entero en la web. La generación dinámica de contenido se basa en el lenguaje de script PHP y la publicación de contenidos, siempre que sea posible emplear una base de datos MySQL para la gestión y el almacenamiento de datos, se realiza en un servidor web. No obstante, otros sistemas de bases de datos adecuados son PostgreSQL, Oracle y Sybase, utilizando un directorio LDAP para la solución de direcciones. También hay disponibles diversas tecnologías para la autenticación de usuarios (SQL, SQL_SSL, LDAP, HTTP, NIS y PAM).

68 http://www.phpgroupware.org/

DESCRIPCIÓN TÉCNICA DE LOS MODELOS DE MIGRACIÓN

Página 184 Versión: 28.09.2003

Cualquier servidor de correo compatible con los protocolos SMTP y POP3/IMAP se puede utilizar para ofrecer esta función de correo electrónico. La compatibilidad con reglas de filtrado y perfiles de ausencia basados en el servidor no es a día de hoy una realidad. phpGroupware es un sistema modular y hay numerosos módulos disponibles para integrar. Además de los módulos empleados en la implantación de funciones de trabajo en grupo clásicas, hay disponibles muchos otros módulos.

Tabla 25: Selección de módulos para phpGroupware

Es posible que los administradores activen los módulos de forma opcional. Las interfaces web se basan en un sistema de plantillas con tres tipos de descripciones de diseño diferentes (XML, eTemplates y HTML). Los colores, el tipo de letra y la justificación se definen mediante CSS (hojas de estilo en cascada o Cascading Style Sheets). Un problema es el uso ocasional del lenguaje Javascript en las interfaces de usuario basadas en web porque no todos los navegadores son capaces de generar el código Javascript sin errores. Además, algunas administraciones públicas restringen el uso de Javascript por razones de seguridad.

El uso de una solución totalmente basada en la web tiene muchas ventajas:

Se puede acceder con navegadores web, y dotar al acceso desde el exterior de seguridad mediante HTTPS.

No es necesaria la instalación de un cliente especial.

La independencia de sistemas operativos ofrece ventajas especialmente en entornos de clientes heterogéneos:

El software sólo ha de actualizarse en el servidor.

No obstante, también han de tenerse en cuenta ciertas desventajas:

DESCRIPCIÓN TÉCNICA DE LOS MODELOS DE MIGRACIÓN

Versión: 29.08.2003 Página 185

El acceso a los datos es a veces imposible si los usuarios no están conectados y/o si no tienen acceso a la red correspondiente. Esto constituye un problema especialmente para el personal de asistencia.

No existe la posibilidad de sincronizar con unidades de terminal móvil tipo PDA.

Se puede concluir que la solución presentada no es una alternativa a la solución de Outlook y Exchange. No obstante, el producto de trabajo en grupo presentado aquí puede ser una solución favorable especialmente para organizaciones pequeñas con requisitos más modestos en cuanto a ciertas funciones. Una ventaja es la flexibilidad con que los módulos concretos pueden adaptarse a las necesidades reales de la organización.

PHProjekt también ofrece una solución comparable. Ambos proyectos ofrecen versiones de demostración69 en Internet, de modo que cualquier interesado puede hacerse una idea de sus funciones.

3.14.4.2 Kroupware

La Secretaría Federal Alemana para la Seguridad de la Información (BSI) ha confiado a un consorcio de empresas el desarrollo de una solución libre de trabajo en grupo para utilizarla en la BSI. Esto significa que el software podrá ser utilizado por todos los interesados sin necesidad de pagar cánones en concepto de licencia. El proyecto tiene por objetivo la creación de una solución de trabajo en grupo independiente de plataformas que se pueda utilizar con cliente tanto GNU/Linux como Windows. Las funciones especificadas por la BSI son comparables a la combinación de Outlook y Exchange de Microsoft. El cliente Outlook ha de ser capaz de trabajar junto al nuevo servidor70.

Sistema servidor

El componente principal es el servidor Kolab que, a su vez, accede a diversos componentes libres. La tabla siguiente (tabla 26) muestra los componentes concretos.

Tabla 26: Componentes Kolab

La solución Kroupware está basada en el clásico enfoque cliente/sevidor que permite a los usuarios utilizar funciones de trabajo en grupo de forma asincrónica. Los usuarios pueden, por ejemplo,

PHPGroupware , PHProjekt

70 http://www.kroupware.org/

DESCRIPCIÓN TÉCNICA DE LOS MODELOS DE MIGRACIÓN

Página 186 Versión: 28.09.2003

utilizar correo electrónico, citas y listas de tareas pendientes personales sin conexión mediante el software cliente adecuado. Los cambios en los datos se actualizan a posteriori. El proyecto Kroupware ha sido diseñado para instalaciones de hasta 1.500 usuarios en cada servidor. Sus posibilidades de ampliación se basan en las funciones de granjas de Cyrus IMAPD y OpenLDAP. Las instalaciones con grandes números de de usuarios se han previsto en ambos sistemas, de forma que su uso en grandes infraestructuras debería ser posible. La opción de restauración de datos es otro elemento crucial para un uso productivo. La arquitectura de todo el sistema simplifica las operaciones de recuperación. Los buzones se representan con directorios independientes en el sistema de archivos y son, por lo tanto, fáciles de restaurar. La complejidad depende de las herramientas de copia de seguridad empleadas. Además de los buzones completos, también se pueden restaurar mensajes de correo y citas concretos.

Sistemas cliente

El acceso a las funciones de correo y de trabajo en grupo es posible tanto con clientes Windows como GNU/Linux. Outlook 2000 de Microsoft era el cliente de referencia empleado en los desarrollos, junto a un conector de Bynari utilizado para conectar clientes Outlook al servidor Kolab. Insight Connector de Bynari71 es un producto comercial por el que hay que pagar y que se debe instalar también en los clientes. El conector permite intercambiar datos de colaboración y de calendarios entre el servidor de trabajo en grupo y el cliente Outlook. No obstante se han apreciado algunos problemas de estabilidad al utilizarlo con el conector.

El conector de Konsec72 podría ser una alternativa en el futuro, pero en estos momentos sólo está en fase beta. El cliente GNU/Linux es resultado de versiones adaptadas de KMail, KOrganizer y otros componentes del proyecto de gestión de información personal KDE. El cliente se integra muy bien en la interfaz de usuario KDE y permite un uso intuitivo por parte de los usuarios. El cliente es compatible con los protocolos

POP3 y con IMAP4 sin conexión. El filtrado del correo electrónico entrante (correo basura, por ejemplo) puede implantarse en el cliente.

La siguiente lista muestra las funciones más importantes de la solución de trabajo en grupo.

Las funciones son compatibles con ambos clientes.

Recepción y envío de correo electrónico

Administración de contactos de los usuarios

Agenda global

Calendario y citas de grupo

Recursos compartidos (carpetas públicas)

Notas y listas de tareas pendientes

Listas de recursos ocupados y libres

Confirmación de ausencias

71 http://www.bynari.net/index.php?id=7

72 http://www.konsec.com/KON/de/konnektor.html

DESCRIPCIÓN TÉCNICA DE LOS MODELOS DE MIGRACIÓN

Versión: 29.08.2003 Página 187

Confirmación de lectura

Sincronización con PDAs de Palm.

Seguridad

Los desarrolladores prestaron especial atención a la integración de estándares de seguridad. La comunicación entre sistemas cliente y el servidor puede cifrarse por entero (SSL/TLS). La comunicación cifrada es posible mediante el uso de

IMAPS

SMTP sobre TLS

WebDAVS

El cliente Linux admite seguridad de punto a punto, además de firmas electrónicas que cumplen los estándares internacionales (S/MIME, X.509v3) y que se pueden habilitar mediante el plug-in73 correspondiente.

Administración

Para fines de administración, se pueden configurar grupos de usuarios especiales con privilegios igualmente especiales. Los diferentes grupos son los siguientes:

Administrador

Mantenedor

Usuario

Hasta cierto punto se pueden efectuar tareas administrativas de diferente nivel de privilegios mediante una interfaz web. Las tareas más sencillas se pueden realizar mediante interfaces de usuario. Las actividades de mayor complejidad requieren el ajuste de las configuraciones correspondientes. Las siguientes tareas, por ejemplo, pueden llevarse a término a través de la interfaz web:

Administración de usuarios y agendas

Administración de carpetas públicas

Administración de ciertos servicios del servidor

Confirmación de ausencia

La interfaz web permite en primer lugar el acceso al servicio de directorios. Si se desea hacer más adaptaciones será necesario modificar los componentes correspondientes. Cada usuario puede cambiar ciertos parámetros directamente, por ejemplo modificar sus datos personales y direcciones de correo electrónico.

Migración

73 www.gnupg.org/aegypten

DESCRIPCIÓN TÉCNICA DE LOS MODELOS DE MIGRACIÓN

Página 188 Versión: 28.09.2003

La experiencia de diversos proyectos de migración aún no está disponible. No obstante, los siguientes mecanismos pueden utilizarse en principio para mudar datos existentes:

Exportación de la información de directorios mediante LDIF y adaptación de datos mediante scripts

Migración del correo electrónico al nuevo cliente mediante POP3

Transferencia de datos en formato vCard o iCalender.

Conclusiones

A fecha de hoy no se puede aún hacer declaraciones concretas sobre la idoneidad de la solución Kroupware en usos prácticos. Para ello habrá que esperar a la experiencia aportada por entornos productivos. Kroupware podría llegar a ser una base de trabajo en grupo adecuada para organizaciones de pequeño y medio tamaño. La ventaja reside en el diseño modular de todo el sistema, desarrollado sobre la base de componentes probados y ampliables. La opción de implantar funciones de administración de usuarios en un servicio de directorio central simplifica la administración de los datos. El servicio de directorios también puede emplearse para administrar los datos de otros sistemas (como Samba). La compatibilidad simultánea con clientes Linux y Outlook puede hacer que este sistema sea especialmente apto para su uso en entornos heterogéneos.

3.14.4.3 exchange4linux

El servidor de intercambio de datos para trabajo en grupo Bill Workgroup Data Exchange Server fue desarrollado en la empresa alemana Neuberger & Hughes GmbH. El servidor ha sido publicado como software GPL y se actualiza constantemente. El objetivo del desarrollo era y sigue siendo ofrecer un sistema servidor alternativo para clientes Outlook de Microsoft. Los usuarios del producto tienen diversas opciones para implantar la solución de trabajo en grupo. El sistema servidor puede obtenerse como paquetes de Debian gratuitos y también adquirirse como solución a gran escala en Neuberger & Hughes. La solución todo en uno incluye, además del sistema de trabajo en grupo integrado, el software de acceso "Easygate". Easygate ofrece los servicios de infraestructura más importantes (DHCP, DNS, servidor de archivos, servidor proxy e Internet).

Sistema servidor

Las funciones de trabajo en grupo se pueden implantar mediante diversas unidades de software que interactúan entre ellas. La siguiente tabla (tabla 27) muestra los paquetes de software necesarios para manejar el servidor de trabajo en grupo. El servidor se desarrolló basándolo en el lenguaje de programación Python y emplea Corba (siga leyendo) para comunicarse con los clientes Outlook.

Tabla 27: Componentes de Exchange4linux

También se puede implantar el servidor Bill con un servicio de directorios. Esta opción debería considerarse especialmente en conjunto con Samba, ya que permite administrar usuarios y componentes de trabajo en grupo de forma centralizada en dominios NT. No obstante, esta solución no puede aplicarse con el paquete completo de N&H, ya que Service Provider debe efectuar ciertas modificaciones al servidor Bill.

Sistemas clientes

El servidor de trabajo en grupo Bill ofrece a los clientes Outlook un acceso basado en un controlador de clientes desarrollado por la propia N&H que ha de instalarse en el sistema cliente. Los clientes MAPI emplean Corba para enviar al servidor Bill las órdenes de Outlook correspondientes. Service Provider MAPI de N&H es un producto comercial y, por lo tanto, está sujeto al pago de licencias.

El servidor admite las siguientes funciones en conjunto con el cliente Outlook de Microsoft:

Recepción y envío de correo electrónico

Administración de direcciones de usuarios

Agendas globales

Calendarios y citas de grupo

Recursos compartidos

Gestión de tareas

Notas en carpetas privadas y públicas

Asignación de recursos disponibles y ocupados

Invitaciones, con la posibilidad de aceptar o rechazarlas

Confirmación de ausencia

Sincronización de PDAs mediante Outlook

La compatibilidad con otros productos cliente no es aún posible, aunque se planea la inclusión de un cliente web que permita realizar las funciones de trabajo en grupo más importantes en la próxima versión.

DESCRIPCIÓN TÉCNICA DE LOS MODELOS DE MIGRACIÓN

Versión: 29.08.2003 Página 189

Descripción técnica de las rutas de migración

Seguridad

La transmisión de datos encriptados utilizando los estándares SSL y TLS es posible entre los sistemas. Los correos(e-mails) entrantes, pueden someterse a chequeos en busca de virus en el servidor final con productos de terceros. Las opciones de seguridad se complementan con el uso de reglas de filtrado Server-based como protección ante el correo basura.

Se pueden asignar privilegios de acceso dentro de las carpetas públicas como protección contra accesos no autorizados. Las llamadas Listas de Control de Acceso (ACL) son las utilizadas para implementar los derechos de acceso.

El almacenamiento de datos dentro de un sistema de bases de datos, ofrece también una forma relativamente fácil de recuperar datos borrados por error. La operación de recuperación puede ser llevada a cabo usando herramientas de bases de datos.

Administración

Un frontend basado en web se utiliza para la administración unido al uso de soluciones todo en uno(all-in-one) lo cual habilita la administración de tareas de rutina.Las actividades administrativas más complejas pueden realizarse usando las herramientas Linux convencionales.

Migración

Se han propuesto diferentes planteamientos hacia la migración de datos, en dependencia del escenario de partida.

En el caso de un proyecto de migración muy pequeño (alrededor de 10 usuarios), debería hacerse una copia del buzón de correo y de otros datos en una carpeta personal en los sistemas del cliente en cuestión. Estos datos pueden entonces ser importados hacia los recién creados buzones en los nuevos sistemas. Este método es muy fiable, pero también consume mucho tiempo. En el caso de una migración de hasta 250 usuarios, además deberían usarse otras herramientas. Los datoas de usuarios de Exchange pueden exportarse utilizando la consola del administrador del Exchange y la herramienta “exmerge.exe” de Microsoft. La información concerniente a los buzones de correo de los usuarios es almacenada en un simple fichero CSV. Los contenidos de los buzones pueden guardarse como ficheros PST en cualquier directorio definido por el usuario. El mismo procedimiento debe utilizarse para las carpetas públicas. A partir de aquí, los ficheros CSV pueden ser importados al servidor de grupo de trabajo usando una herramienta de migración distribuida por N&H. Después, los usuarios pueden utilizar el Outlook para importar las copias de los buzones (ficheros PST) al servidor.

En el caso de un proyecto de migración mayor, existen mejores opciones técnicas para la transferencia de datos y que deben estudiarse para cada caso concreto.Conclusiones

la solución de groupware presentada ofrece un magnífico soporte para los clientes Outlook porque todas las funcionalidades de groupware importantes están soportadas, y por lo tanto, están disponibles para los usuarios. La solución está, a día de hoy, optimizada para escenarios con varios cientos de usuarios (maximo de 500) y es utilizada en ambientes productivos de éste sistema.

3.14.4.4 SuSE Linux OpenExchange Server 4

El OpenExchange Server 4 es una mejora considerable del e-mail server 3.1 del Linux SuSE workgroup. Este groupware es una solución todo-en-uno que incluye un sistema operativo completo, bases de datos, así como servidores e-mail y web. La tecnología del sistema operativo está basada en el SuSE Enterprise Server. El sistema está diseñado para una instalación completamente nueva, en lugar de una actualización para sistemas heredados. El distribuidor ofrece a sus clientes una solución con paquetes de software compatibles.

Servidor

No discutiremos aqui sobre paquetes que no estén directamente relacionados con las soluciones de groupware. El producto completo consiste en distintos módulos de software que interactúan para implementar el correo y las funcionalidades de groupware. La tabla abajo mostrada resume los módulos centrales del producto.

Una ventaja particular de la arquitectura modular es la escalabilidad gracias a la posibilidad de distribuir componentes

a diferentes sistemas. El diseño modular también permite la actualización flexible de los sistemas existentes.

Los componentes del servidor ofrecen un amplio abanico de funcionalidades de groupware y correo. Algunas funciones disponibles para los usuarios son las siguientes:

Recepción y envío de e-mails

Calendario

Gestion de direcciones

Gestión de tareas

Funciones de notasGestión de documentos (gestión de versiones y estructura de carpetas)

Gestión de proyectos

Base de datos de conocimiento configurable

Foro de discusión basado en grupos

Estas funcionalidades pueden usarse a través del portal web integrado.

Sistemas cliente

Las funciones de correo y groupware deben ser evaluadas con un ojo puesto en el soporte de diferentes sistemas cliente. Las funciones de correo pueden ser accedidas por cualquier cliente que soporte POP3 o IMAP. Más aún, los usuarios pueden acceder a su coreo utilizando una solución de correo web integrada.

Las funcionalidades groupware pueden usarse de dos maneras diferentes:

Acceso basado en navegador sobre los contenidos del portal web.

Acceso limitado a través del cliente Outlook.

La completa interfaz web permite a los usuarios acceder a todas las funciones listadas anteriormente. Los libros de direcciones basados en LDAP, la posibilidad de asignar privilegios y las funciones de búsqueda están disponibles para los usuarios en todos los módulos funcionales. Si se usa la función de citas, el servidor analiza automáticamente los recursos disponibles durante el periodo en cuestión. La interfaz web ofrece a los usuarios acceso a un gran número de funciones de grupo.

La segunda opción de acceso es utilizar el cliente Microsoft Outlook. Su uso depende de la disponibilidad de software de réplica adicional que debe instalarse en los sistemas cliente. Este proceso de réplica reconcilia los datos de la petición del usuario y, por lo tanto, no tiene lugar en tiempo real, como sería en caso de disponer de un conector. El software permite la integración de correo, contactos, tareas y citas personales. En caso de conflicto, el usuario decidirá de caso en caso cómo resolverlo. La réplica de los datos se lleva a cabo usando SOAP junto con HTTP y permite la reconciliación de los datos del servidor con los datos de la base de datos Outlook. El empleo de Outlook permite también la réplica en PDAs. No se soporta la interfaz MAPI de Microsoft para Outlook.

Actualmente, Outlook no permite citas de grupo porque Outlook no incluye las funcionalidades adicionales del servidor OpenExchange, como la delegación de tareas. Más aún, el libro de direcciones MAPI global tampoco está soportado. Por lo tanto, no es posible implementar una aplicación real de tiempo real. Sin embargo y según datos del fabricante, esta opción está en desarrollo.

Seguridad

Se puede usar OpenSSL para cifrar la transmisión de datos. OpenSSL implementa el cifrado de datos entre aplicaciones y componentes. Es posible la transmisión segura de POP3 e IMAP a través de túneles SSL y, para SMTP, a través de TLS.Puede usarse un analizador de virus para mejorar la seguridad en el correo electrónico identificando correos, incluyendo los adjuntos, que pudieran estar infectados. Pueden usarse filtros SIEVE para filtrar correos spam. Si fuera necesario, los filtros de correo pueden emplearse para restringir el tamaño de los mensajes y para aplicar filtros adicionales definidos por el usuario.

Administración

Se ofrece una interfaz web para las tareas de administración. El administrador puede decidir qué datos pueden editar los usuarios. Los usuarios pueden cambiar su clave de acceso y generar mensajes de ausencia utilizando la interfaz web. Esto reduce la carga de trabajo de los administradores. Éstos pueden utilizar opciones avanzadas para configurar los componentes groupware, el correo y la seguridad. Además, existen formas tradicionales (herramientas de línea de comandos y ficheros de configuración) para la administración.

Migración

El entorno de trabajo en grupo de SuSE Linux ofrece soporte especial para la migración desde Microsoft Exchange 5.5 a OpenExchange Server 4. Los miembros del SuSE Workgroup o los colaboradores de SuSE analizan el sistema en su entorno de funcionamiento y preparan una propuesta de migración. Para ello, utilizan tanto programas de Microsoft como desarrollos propios.

Se pueden migrar los siguientes datos:

Listas de usuarios, incluyendo los privilegios.

Los correos, tanto locales como globales.

Tareas

Contactos

Citas

Notas

Los datos relacionados con funcionalidades no presentes en OpenExchange no se incluyen en la migración. Estas funciones incluyen, por ejemplo, diarios, tareas recurrentes, categorías y subcarpetas propias del usuario.

Conclusiones

La solución groupware desarrollada por SuSE Linux AG constituye a sistema de trabajo en grupo modular donde cada componente está basado en aplicaciones Open Source muy usadas y comprobadas. Se integró el paquete comercial „Comfire“ como componente groupware, ofreciendo a los usuarios un amplio abanico de funcionalidades groupware. El usuario puede acceder a la información usando el interfaz web o el cliente Outlook. Éstos tienen acceso basado en navegador a todos los componentes de la solución OpenExchange. Sin embargo, esta función está limitada para los usuarios de Outlook, ya que no pueden acceder utilizando acceso en tiempo real ni tienen soporte MAPI real. Esto significa que la funcionalidad para los usuarios de Outlook está limitada.Samsung Contact

Samsung Contact (SC) es una solución groupware exhaustiva que fue diseñada para ser usada en empresas de diferentes tamaños. El sistema permite administrar desde varios cientos a varios miles de usuarios en un servidor. La funcionalidad software es bastante compatible con el producto Microsoft Exchange. Todos los componentes del servidor están disponibles para Linux (RedHat, SuSE) y para la mayoría de los derivados de UNIX (AIX, HP-UX, Solaris). Para el lado cliente, existe soporte para varios sistemas operativos. El cliente SC Java se puede ejecutar sobre Linux y Windows. Podemos usar un navegador web en cualquier plataforma que cuente con uno. Se incluye un proveedor MAPI, que proporciona acceso a toda la funcionalidad Outlook (98, 2000, XP).

Samsung Contact se basa en la extendida y fiable tecnología OpenMail, de Hewlett-Packard (HP).Samsung se estableció en Korea y llevan en el mercado más de 15 años. En noviembre del 2001, Samsung SDS adquirió todos los derechos para continuar el desarrollo de este producto, así como el equipo de desarrollo pertinente de HP.

Sistema servidor

La ilustración de abajo (figura 31) explica los principios de la aquitectura del sistema.

Figura 31: Arquitectura de Samsung Contact

El servidor consiste en una serie de componentes independientes los cuales pueden ser también distribuídos

en múltiples servidores siguiendo una escala horizontal. Además, algunas instancias completamente independientes

pueden ser ejecutadas en un servidor. la tabla de abajo resume los procesos del servidor y sus diferentes tareas.

El agente de transporte de correo (MTA) utilizado por defecto es sendmail. También es generalmente posible

utilizar postfix. Se recomienda Apache como servidor web y entorno de administración.

Samsung Contact permite tanto la instalación en un único servidor como la instalación distribuída en varios lugares.

De cualquier manera, el buzón de correo de un usuario siempre es asignado a un único servidor. Este directorio puede

reproducirse en base de envergadura de sitio. Los Directorios compartidos públicos conocidos del entorno

Microsoft Exchange son implementados vía bulletin boards (BB). Estos también pueden reproducirse con envergadura de sitio, lo cual es especialente favorable en casos conexiones entre sitios con poco ancho de banda.

Para enlazar aplicaciones externas a la solución de groupware, hay disponibles un API especial y el Servicio de

Enlace de Aplicaciones. Esta interfaz es empleada por ejemplo, por la compañía VIPcom (www.vipcomag.de) y por Ferrari (www.ferrari-electronic.de) para enlazar un sistema de mensajería unificada (voz, fax).

El diseño del sistema Samsung Contact fue optimizado con vistas a la capacidad de alta disponibilidad. La mayoría

de los parámetros del sistema pueden cambiarse sin interrumpir operaciones y sin la necesidad de reiniciar todo

el sistema. Es recomendable, la manipulación del sistema en un cluster HA a fin de evitar posibles fallos de hardware

en un nodo de correo. La solución que proporciona HP, HP Services Guard, se recomienda tradicionalmente para este

propósito. Cualquier software de cluster puede, en general, adaptarse al Samsung Contact siempre y cuando dicho

software permita tomar control de un nodo de almacenamiento conjunto. (Red Hat Adavanced Server, Steeleye, Polyserve, Failsafe, Linux Heartbeat).

Clientes

Samsung Contact ofrece una amplia gama de clientes soportados. Además, también está disponible un proveedor MAPI

para conectar clientes Microsoft Outlook y un cliente de groupware desarrollado en Java y la correspondiente intefaz

web. El cliente se conecta por defecto via protocolo UAL. Esto es un simple protocolo de socket para el cual existe

APIs de código abierto tanto en C como en Java. El proveedor MAPI de Samsung y el cliente web usan la API de C,

mientras que el cliente en Java emplea lógicamente el API de Java.

Aparte de los clientes Samsung, se pueden pedirlos contenidos de los buzones de correo y los protocolos estándar

POP3 o IMAP. Esto significa, que cualquier cliente de correo con soporte para POP3 o IMAP puede usarse para

recivir o enviar mails (Eudora, Evolution, Mozilla, Netscape, Outlook Express, K-mail). Existe una versión modificada

del cliente web para permitir el acceso WAP.

Los clientes Outlook pueden usarse gracias a la implemetación de la MAPI en el Samsung Contact. Todas las funciones

del servidor Exchange también están representadas. Esto también incluye todas las características de groupware

importantes. SC permite asignar privilegios a otros usuarios para acceder a directorios individuales (mail, acuerdos,

contactos, tareas pendientes). Los directorios publicos compartidos conocidos de Exchange están disponibles

en forma de Bulletin Boards. También están disponibles las reglas concernientes a la distribución de mensajes

entrantes así como la generación automática de mensajes de ausencia. Podemos definir un proxy para un usuario

ausente, y con el proxy, además, vendrían los privilegios de acceso durante el período de ausencia. Los acuerdos

para reuniones también están soportados, análogamente que el proceso de Microsoft Exchange, por una lista de

libre-ocupado manipulada en el directorio del servidor Samsung Contact. Se implementó la sincronización de directorios offline a fin de permitir el uso móvil.

Seguridad

El Samsung Contact no ofrece encriptación de mensajes por defecto. Sin embargo, ciertas soluciones ofertadas

por terceras empresas permiten la encriptación S/MIME para Outlook (por ejemplo Entrust). La encriptación de la

conexión entre cliente y servidor (POP3/IMAP) puede lograrse utilizando un stream SSL tunner (stunnel).

La autentificación de usuarios se implementa por medio de la arquitectura PAM. Es usada tanto por los procesos

de servidor para los protocolos UAL/IMAP/POP3 como por la línea de comandos para propósitos administrativos. Además de la autentificación contra el directorio Samsung Contact, también es posible la autentificación contra servicios externos. El presente metodo de entrega incluye módulos PAM para autentificación en cuentas UNIX y servidores SMB (Samba). Samsung Contact permite la definición detallada de los derechos de acceso para los siguientes recursos de servidor en forma de las llamadas Listas de control de acceso (ACLs):

- Bulletin Boards

- Directorios

- Procesos de servicio

- Servidor de impresión

- Scripts del servicio pedido

La cantidad máxima de espacio de memoria que puede utilizar un usuario puede ser limitada por cuotas.

No se necesita ningún software de respaldo adicional para el almacenamiento de mensajes. Se podrá utilizar

cualquier producto disponible para el respectivo sistema operativo del servidor. El diseño del Samsung Contact permite consistentes backups durante la ejecucción de las operaciones. Está disponible una herramienta de línea de comandos para la funcionalidad de backup/restore de un usuario. Esto significa que un sólo usuario puede ser fácilmente trasladado de un nodo de correo a otro. Cualquier ativirus basado en SMTP (MIME-Sweeper, Trendmicro Viruswall) puede utilizarse generalmente. El antivirus AHN (www.ahnlab.com) esta integrado en el servidor. Además de la protección del antivirus, se permite al usuario el establecimiento de filtros de mail personalizados en el producto final. Estos filtros se configuran vía web. La versión se SMTP soporta antispamming de acuerdo con la RFC 2505.

Administración

La administración de un nodo de correo Samsung Contact es posible de dos maneras distintas. Existe, por un lado

un entorno web para la creación de usuarios, listas de distribución y directorios, además, también existen multitud

de programas en línea de comandos para administración. El entorno web está diseñado para uso rutinario. Los programas

de línea de comandos son más apropiados para la automatización de tareas admnistrativas.

La administración del sistema puede ser llevada a cavo por cualquier usuario con privilegios de administrador.

Añadiendo una entrada en el directorio de sistema determinará cuando un usuario está autorizado para actuar

como administrador.

Migración

La migración desde un entorno Exchange o Outlook es posible de varias maneras. Si el número de usuarios no es

demasiado grande (<100), se puede hacer una exportación manual de buzones de correo, acuerdos, contactos y tareas

en un archivo PST local, seguido por la transferencia manual a una estructura de directorios en el servidor destino.

En este caso, los usuarios y los buzones de correo pueden crearse de forma manual.

En entornos con mayor número de usuarios, la migración manual no es razonable desde el punto de vista del coste

y la eficiencia. En este tipo de entornos emplearemos herramientas de migración comerciales. Dependiendo del

fabricante, la importación automática de todos los datos, incluyendo la reconfiguración de los clientes Outlook,

es o no posible. Podremos migrar al servidor destino la siguiente información:

- Usuarios.

- Entradas de calendario.

- Entradas de directorio.

- Listas de distribución pública.

- Jerarquía de directorios, incluyendo todos los componentes (correo, acuerdos, tareas, contactos).

- Bulletin boards.

- Reglas de servidor.

- Listas de control de acceso

Recomendamos que se cuente con un proovedor de servicios externo que tenga la experiencia necesaria para llevar a cabo el proyecto de migración.

Conclusiones

Samsung Contact es un sustituto completo de Microsoft Exchange server, tanto para instalaciones grandes como para las más pequeñas. Todas las funcionalidades de groupware están soportadas. Las aplicaciones basadas en formularios son una excepción, pero un suministrador externo está trabajando en ello.

La tecnología básica ha estado dispnible desde hace más de 15 años. El producto es usado en un elevado número de instalaciones de referencia y la reciente adquisición por parte de Samsung asegura su desarrollo en los años venideros.

3.14.4.6 Sumario

Hay algunas soluciones groupware disponibles en Linux con una funcionalidad similar a la de Microsoft Exchange. Las soluciones generalmente persiguen dos estrategias diferentes. A saber:

- Acceso vía navegadores a los servidores de groupware, procesándose la información dinámicamente en el servidor.

- Acceso al servidor de groupware utilizando software cliente específico

La siguiente tabla (Table 30) ofrece una vista rápida de las funcionalidades más importantes de diferentes soluciones groupware.

Tabla 30: Soluciones groupware altrnativas

TABLA 30

CONTINUACIÓN TABLA 30

Las funcionalidades descritas para las soluciones groupware mencionadas muestran que ya existen productos basados en Linux adecuados. La selección de una solución groupware en particular se basa en los siguientes criterios:

- Uso del cliente de Microsoft Outlook

- Utilización en entornos heterogéneos del lado del cliente, uso simultáneo de clientes basados en Linux y el cliente Outlook.

- Uso de una solución basada en web

- Uso de Outlook

The Kroupware, SuSE OpenExchange y Samsung Contact son los candidatos más adecuados normalmente para continuar utilizando Outlook como cliente. La actual falta de conexión en tiempo real de SuSE OpenExchange con Outlook restrige la funcionalidad de tal forma que para muchos usuarios no será una alternativa interesante hasta que se implemente dicha conexión en tiempo real. Exchange4linux y Samsung Contact presentan hoy por hoy el soporte más amplio de Outlook. La solución The Kroupware mencionada anteriormente puede convertirse en una alternativa interesante en el futuro, especialmente en entornos de sistemas heterogéneos (ver abajo). En vista de la falta de resultados en el entorno productivo, todavía no es posible en este momento hacer afirmaciones concretas sobre la idoneidad de esta solución. Para organizaciones con varios cientos de usuarios, el servidor exchange4linux constituye una plataforma groupware estable que ha demostrado además su validez en el uso práctico. Samsung Contact, que lleva en el mercado mucho tiempo y que ofrece buén soporte para Outlook, es una alternativa prometedora, especialmente para las organizaciones más grandes. Gracias a la escalabilidad del sistema, éste es adecuado incluso en organizaciones con varios miles de personas. La adquisición de HPOpenMail por parte del grupo Samsung ha contestado a la cuestión 74 sobre soporte y la continuidad de su desarrollo.

Entornos de cliente heterogéneos

Organizaciones que utilicen diferentes sistemas operativos en el lado del cliente podrán utilizar Samsung Contact y, en un futuro Kroupware, por ejemplo. Samsung ofrece su propio cliente basado en Java que soporta las funcionalidades groupware deseadas independientemente del sistema operativo. De esta forma, Outlook y/o el cliente Java pueden ser usados en sistemas Windows y sólo el cliente Java en los sistemas Linux. Kroupware implementará en el futuro una solución potencial para entornos híbridos. La posibilidad de utilizar simultaneamente Outlook y el cliente de KDE ofrece a los usuarios las funcionalidades groupware respectivas incluso sin conexión.

Soluciones basadas en web

La soución phpGroupware, sujeta a la GPL, y la comercial OpenExchange ofrecen un gran abanico de funcionalidades a las organizaciones que prefieran una aproximación web. Adicionalmente, OpenExchange permite la conexión al cliente de Outlook, siempre teniendo en cuenta que la conexión en tiempo real no estará disponible.

3.14.5 Continuando la migración

3.14.5.1 Exchange 2000

Nuevas características

El cambio más importante en la arquitectura, conjuntamente al lanzamiento de Exchange 2000 desde Exchange 5.5, es el cambio de Exchange directory service a Windows 2000 active directory (AD). Esto significa que Exchange 2000 ya no incoropora un servicio de directorio propio y consecuentemente requiere de un servicio de directorio como requisito indispensable. Es más, Exchange 2000 no se puede instalar en servidores Windows NT, sólamente en servidores Windows 2000.

La unidad estructural llamada “Site” perteneciente a Exchange 5.5 ha sufrido los siguientes cambios:

- El directorio activo sólo es responsible de de la replicación del directorio; no se deben confundir los sitios introducidos allí con los sitios de Exchange 5.5

- Los servicios de Exchange están estructurados en “grupos administrativos” desde el punto de vista de la administración.

- Es más, los servidores Exchange se dividen en “grupos de enrutado”, los cuales no tienen porque coincidir con los “grupos administrativos” necesariamente,

Debido a que los servidores de Exchange 2000 ya no contienen un servidor de directorio, es necesario uno externo que proporcione información más allá de los límites del dominio, esto es, el Global Catalog (GC). El GC sólo puede hacerse disponible en controladores de dominio de Windows 2000. Contiene información concerniente a todos los objetos de una estructura general de Windows 2000 (forest), de todas formas, respecto a los atributos seleccionados

74 Referirse también al estudio de viabilidad para el Ministerio Federal Alemán del 2001

Descripción técnica de las vías de migración

Los clientes modernos (como Outlook 2000 o 98 SP2) pueden recibir información directamente del GC, mientras que versiones de clientes más antiguas se sirven del servidor Exchange 2000, el cual actúa como proxy y pasa a través de él la petición. En contraste con esto, cada servidor Exchange en Exchange 5.5 incluye un servicio de directorio.

Las listas de distribución en Exchange 5.5 son reemplazadas por grupos con correo electrónico habilitado en el directorio activo. Existen grupos de distribución puros y grupos de seguridad en el DA. Los grupos de seguridad también tienen el correo electrónico habilitado, de forma que se previenen las redundancias. Recuerden que el DA contiene grupos con diferentes áreas de validez (visibilidad): dominios (global y local) y grupos universales (sólo en modo nativo del dominio). Sólo los grupos universales son visibles más allá de las fronteras del dominio.

En Exchange 2000, el borrador ya no es determinado por el modelo de administración del entorno Exchange ya que los servidores pueden ser organizados separadamente en grupos administrativos y grupos de rutado. Sin embargo, esta separación sólo es posible si Exchange 2000 es ejecutado en modo nativo, es decir si no hay o no se usarán servidores 5.5 nunca más.

Exchange 2000 ofrece un modelo de guía para propósitos de administración. Este modelo permite a los administradores cambiar opciones para un grupo de objetos (tal como buzones de usuario, servidores y carpetas públicas) en una sola operación.

El transporte entre servidores Exchange 2000 tiene lugar vía SMTP (Simple Message Transport Protocol). Exchange 5.5 usa RPC. SMTP está ya integrado en Windows 2000, tanto como NNTP.

El conector de grupo de rutado de Exchange 2000 reemplaza la conector de lugar.

Están disponibles los siguientes conectores:

Conector X.400 (ya no está contenido en el MTA de Exchange 2000)

Conector de correo Microsoft

Conector CC:Mail

Conector Lotus Notes

Novell Groupwise

Pueden crearse hasta cuatro grupos de almacenamiento y hasta cuatro bases de datos por cada servidor Exchange 2000. Esto ofrece algunas ventajas, especialmente respecto a la salvaguarda y la recuperación de datos.

Es posible indexar la base de datos de Exchange.

Los grupos de servidores Exchange pueden trabajar ahora en modo “activo-activo".

Outlook Web Access (OWA) soporta ahora WebDAV (Web Distributed Authoring and Versioning), un desarrollo ulterior de HTTP 1.1. Una ventaja respecto a OWA es el hecho de que los servidores Exchange pueden ser configurados como unidad frontal y como unidad de respaldo, por lo que los servidores OWA no tienen que contener datos en si mismos.

Además, la instalación de servicios de:

- chat

- mensajería instantánea

es ahora posible.

La nueva variante de producto “Exchange 2000 Conferencing Server”, permite también audio y videoconferencias.

El entorno de desarrollo de Exchange 2000 queda actualizado por:

- la mejora de los CDOs (Collaboration Data Objects)

- mecanismos ampliados para workflow

- introducción de XML

- integración mejorada del IIS (Internet Information Server) y ASP (Active Server Pages).

Observaciones concernientes a la migración

La migración de Exchange 5.5 a Exchange 2000 es un proceso complejo que requiere intensa preparación, desarrollo conceptual, planificación de migración y pruebas bien diseñadas de acuerdo con el entorno real de producción. Si bien esta guía no puede tratar de forma exhaustiva estas tareas, deben mencionarse, no obstante, algunos de los aspectos importantes de un proyecto de migración.

Antes de nada deben definirse una serie de términos. Una actualización de Exchange 2000 se refiere a la instalación de Exchange 2000 en un servidor de Exchange 5.5. El término actualización del sistema operativo de un servidor, se refiere al la instalación de Windows 2000 en un servidor Windows NT 4.

El hecho de que sólo pueda utilizarse Exchange 2000 si existe un directorio activo Windows 2000, conlleva una serie de condiciones técnicas de frontera, que incluyen:

- La estructura de dominio del directorio activo de Windows 2000 tiene repercusiones más importantes en Exchange 2000 que las que tiene la estructura de dominio de Windows NT sobre Exchange 5.5. El bosque constituye las fronteras de la organización Exchange porque el alcance, a nivel de dominio de información colectiva del Catálogo Global (GC), es única para cada bosque.

- La estructura de OU escogida para los dominios de Windows 2000 no tiene, en principio, repercusiones en la migración a Exchange 2000.

- La introducción de Exchange 2000 requiere una modificación del esquema del directorio activo. Esta modificación se puede llevar a cabo sin la necesidad de instalar Exchange 2000 (palabra clave: forestprep). Además , el dominio al que concierne debe ser preparado (palbra clave: domainprep)

- El modo operativo (nativo vs. modo mixto) de los dominios Windows 2000, influye en la disponibilidad de los grupos universales y, a partir de esta, en la de los distribuidores de correo electrónico.

- La actualización a Exchange 2000 es sólamente posible tras una actualización previa del sistema operativo. No es posible instalar Exchange 2000 sobre Windows NT 4. En contraste, Exchange 5.5 puede correr sobre Windows 2000.

- Una actualización de sistema operativo de un servidor Exchange, requiere un análisis detallado (service packs, etc.), especialmente si existe software adicional de terceras partes instalado (por ej. Software antivirus).

- Antes de llevar a cabo la primera actualización de Exchange 2000, los servidores Exchange tienen que ser miembros de un dominio Windows 2000 y/o un bosque.

- Los usuarios deben logarse en un directorio activo para utilizar Exchange 2000.

La complejidad de la cartera completa de escenarios de migración (modelos de dominios NT puros, varias organizaciones Exchange, Exchange en dominios de recursos, Exchange en controladores de dominio, sedes distribuidas, bosque Windows 2000, etc.) no se contempla dentro del alcance de esta guía. No obstante se deben mencionar algunas herramientas que pueden facilitar la migración y/o coexistencia.

Active Directory Connector (ADC) permite la replicación de una jerarquía de objetos de directorio entre el directorio de un servidor Exchange 5.5 y un directorio activo. ADC, por tanto, juega un papel importante en la migración de Exchange 5.5 a Exchange 2000. Téngase en cuenta que existen dos versiones ADC (una en el CD de Windows 2000 y la otra en el de Exchange 2000). En lo que concierne a la migración a Exchange 2000, la última es la adecuada.

El Site Replication Service (SRS) permite a los servidores Exchange 2000 replicar la configuración Exchange 5.5.

Exchange 2003

Exchange 2003 (nombre código: Titanium) es el sucesor de Exchange y se espera que sea lanzado antes del final de 2003 (N. del T.: a fecha de la traducción esta nueva versión ya es comercial).

El número de nuevas características, comparadas con Exchange 2000, es relativamente pequeño. El principal motivo de la introducción de Exchange 2003 se debe a que los cambios en Windows 2003 en relación a Windows 2000 hacen que no sea posible la instalación de Exchange 2000 sobre plataforma 2003. Esto es, Exchange 2003, sólo puede ser instalado bajo Windows 200375.

La matriz de compatibilidad que se presenta a continuación (Tabla 31) ofrece un mapa de las diferentes combinaciones soportadas de Exchange 5.5, Exchange 2000, Exchange Server 2003 y Windows Server 2003.

Tabla 31: Matriz de compatibilidad - Exchange

La siguiente ilustración (Figura 32) esboza las posibilidades de entornos híbridos.

Figura 32: Entornos híbridos – Exchange

Nuevas características de Exchange 2003 son:

- Outlook Mobile Access (en la actualidad Microsoft Mobile Information Server

2002) estará incluido dentro de Exchange Server 2003. Outlook Mobile Access proporciona, a los usuarios o dispositivos móviles, acceso a su información personal.

- En Exchange Server 2003, el Internet Information Server (IIS version 6 en Windows 2003) permite una nueva forma de comunicación entre Outlook y Exchange, conocida como “RPC por HTTP”. De esta forma, los usuarios de Outlook pueden sincronizar sus datos con un servidor Exchange 2003 a través de una conexión HTTP de forma segura.

- El soporte para clusterización en Windows 2000 Advanced Server, se limita a dos o bien cuatro nodos bajo la versión Windows 2000 Server DataCenter Edition. Windows 2003 y Exchange 2003 permiten la implementación de clusters de hasta ocho nodos con al menos un nodo pasivo si se utiliza Exchange 2003 Server con Windows Server 2003 Enterprise Edition.

- Exchange 2003 utiliza, bajo Windows 2003, el servicio de copia de volumen en sombra y por tanto permite tiempos más cortos de respaldo y recuperación para entornos Exchange.

Office / escritorio

Perspectiva

Con vistas a reemplazar MS Office 97 u Office 2000, parece razonable esperar al lanzamiento de MS Office 2003 (N. Del T.: producto ya comercializado en el momento de la traducción) y experimentar primero con MS Office, cuando además este lanzamiento se ha anunciado para el verano de 2003. Más allá de los aspectos inmediatos de coste, las consideraciones técnicas juegan un papel particularmente importante en lo relativo a los cambios que se han anticipado en los formatos de documento. Microsoft planea establecer XML como el formato principal para los documentos Office de MS Office 2003. En este contexto, no se puede pasar por alto que los actuales problemas de compatibilidad con la solución alternativa de OOS OpenOffice.org, y StarOffice como contraparte comercial, se verán reducidos o incluso eliminados. En caso de resultado positivo en la comprobación de compatibilidad concerniente a intercambio de documentos entre MS Office 2003 y OpenOffice 1.1 o StarOffice 6.1 respectivamente, se tendrían que analizar las acciones y costes resultantes de la importación de documentos Office existentes a MS Office 2003. En un paso más, estas acciones y costes deberían compararse con las acciones y costes, bien conocidas a día de hoy, relativas a la migración a OOo/SO.

Sólo entonces se podrá tomar una decisión a favor de MS Office 2003 o OOo/SO.

La sustitución del escritorio Microsoft vendrá determinada por un lado y en gran medida por la conveniencia de la sustitución de MS Office por OOo/SO y, por otro, por la disponibilidad a largo plazo de otras aplicaciones Windows que sean necesarias y cómo de buenas sean estas

aplicaciones pueden entretanto estar disponibles como programas Windows en el escritorio Linux. Esto debe, sin embargo, ser analizado caso a caso.

Introducción

El escritorio es la interfaz visible para los usuarios, suministrándoles con las herramientas y las aplicaciones que ellos necesitan para su trabajo del día a día. Trabajar con el paquete de Microsoft Office (MS Office) se situa en primer plano de este contexto. De todos modos, varias otras herramientas standard están también disponibles para los usuarios cuyas funcionalidades permanecen disponibles incluso después de la migración. Además, varios programas especializados por añadiduría están mas o menos integrados dentro del escritorio y son amenudo aplicaciones Windows que no pueden ejecutarse directamente desde Linux. La discusión técnica siguiente la hemos dividido en las cinco secciónes de acontinuación:

MS Office: situación inicial.

La migración de reemplazo de MS Office.

Continuando la migración de MS Office.

Las mas nuevas aplicaciones de escritorio.

Aplicaciones Windows bajo Linux.

MS Office: La situación inicial.

MS Office esta disponible en diferentes paquetes y versiones. A diferencia del sistema operativo, uno no tiene que asumir que versión particular de MS Office están usando la mayoria de las organizaciones públicas. Uno puede, de cualquier modo, suponer que las versiones inferiores a MS Office 97 están apenas en uso ya y que Microsoft Office XP no está todavía extensamente usado. La mayoría de las agencías públicas probablemente utilizan Microsoft Office 97 o 2000. Las siguientes discusiones serán en consecuencia basadas en estas dos versiones como fundamento inicial para la migración. La mayor parte de las nuevas características de Microsoft Office XP comparadas con Microsoft Office 2000 tienen que ver con la interfaz de usuario así como el área de trabajo en equipo, con parte de funciones adicionales en el área de trabajo en equipo incluyendo las funcionalidades 'groupware' las cuales están ya cubiertas por otras aplicaciones.

Además, Microsoft se integra en las dos áreas, por ej. Office y Servicios de puntos para compartir (SharePoints), mas marcados que antes*78. Esto, sin embargo, solamente significa cambios menores para el trabajo del día a día. Las nuevas funcionalidades de Office XP serán en consecuencia dirigidas solamente en selectos contextos.

Además de las versiones, los diferentes paquetes de Office juegan un papel importante con un punto de vista para la migración. Estos paquetes generalmente difieren en términos de las aplicaciones las cuales abarcan. Tomamos el paquete Office 2000 Professional como base para la sección

La migración de reemplazo de MS Office

*78 Para detalles acerca de las nuevas características comparadas en versiones inferiores, remitirse a

http://www.microsoft.com/germany/ms/officexp/prof/vergleich.htm

Continuando la migración de MS Office

discutiremos sobre

World

Excel y

PowerPoint

como aplicaciones independientes. Outlook será debatido en el capítulo 3.14 como parte de un groupware y solución de mensajería. Access será analizado y evaluado en conjunto con la migración de bases de datos. Internet Explorer y PhotoEditor serán discutidos en la sección de “Las mas nuevas aplicaciones de escritorio” junto con otras herramientas de escritorio. Los autores también remitirán el proyecto de MS en la misma sección.

Funcionalidades

Una lista de todas las funcionalidades de World, Excel y PowerPoint irían mas lejos del ámbito de esta sección. Alternativamente, los dos siguientes capítulos nos expondrán las mas notables diferencias entre la situación inicial y las posibles alternativas futuras desde un punto de vista para la migración.

Un aspecto para ser considerado primero es el intensivo uso de las organizaciones específicas de solución de software las cuales complementan las funcionalidades de Microsoft Office.

Esto significa de una parte que los entornos de programación disponibles con MS Office son utilizados por la mayoría de organizaciones públicas y otras organizaciones para crear documentos específicos de soluciones de script (macros) de manera que extensamente automatiza trabajo de proceso con MS Office. Esto incluso incluye la implementación de departamentos spanning de trabajo corriente. Por otra parte, las organizaciones públicas también utilizan un gran número de software externo para soluciones que están mas o menos integradas en el Office. Esto es por lo que los entornos de programación de MS Office estarán brevemente referenciados a continuación.

El entorno de programación de MS Office

Los entornos de programación de MS Office están basados en lenguaje de programación BASIC. El dominante Microsoft World corrientemente hace referencia a este lenguaje como Visual Basic. Esta familia de lenguajes habitualmente incluyen diferentes dialectos como los siguientes:

Visual Basic (Visual Studio, Vollversion)

Visual Basic para Aplicaciones (VBA)

Visual Basic Scripting Edición (VBS).

Aunque todos los dialectos tienen el mismo bocavulario basic, ellos difieren en términos de funcionalidad y entornos de ejecución.

El entorno de programación de MS Office incluye visual basic para aplicaciones (VBA). VBA está disponible bajo los términos de licencia Microsoft, así que una tercera parte de fabricantes pueden integrar VBA en sus productos.

En lo que respecta a esta guía, tomaremos como punto de partida la versión Office 97. Las versiones anteriores de Office proporcionaban distintos entornos de programación para los distintos productos (Word Basic, Excel VBA, Access Basic). El Office 97 estableció el VBA versión 5, como el entorno de programación común. La tabla de abajo (Tabla 32) muestra las distintas versiones de VBA frente las distintas versiones del Office.

Tabla 32: Versiones VBA

El VBA, y especialmente las variantes de Visual Basic (Completa y Scripting Edition), se tratarán, en lo sucesivo, fundamentalmente para hacer comparativas.

Conceptos básicos del VBA

El VBA es un lenguaje interpretado que puede ser ejecutado sólo en el interior de aplicaciones Office. El VBA se basa en la tecnología COM (Component Object Model), que es una evolución de la técnología OLE (Object Linking and Embedding, Objetos enlazados e incrustados).

El Office, no sólo es capaz de utilzar objetos COM, sino que él mismo ofrece objetos COM. El Office 97 porporciona más de 550 objetos COM propios, el Office 2000 más de 600. También es posible, por medio del COM, usar funcionalidades externas al Office. El VBA permite el uso de programas externos (como los del sistema operativo) en forma de DLL (Dynamic Link Libraries, Librerías dinámicas)

El gráfico de abajo (Figura 33) muestra las distintas posibilidades que tiene el VBA de usar funcionalidades.

Figura 33: El VBA en la aplicación Office

En el VBA, Cada módulo individual puede clasificarse en los siguientes tipos:

Módulos

Módulos de clases

Formularios

Los módulos contienen código fuente de programas „normales“. Los módulos de clase se usan para crear objetos, así como definir sus métodos y propiedades.

Estos módulos permiten la expansión de las funcionalidades que ya tiene el Ms Office, la automatización de secuencias de llamadas a funciones, así como la implementación de nuevas funcionalidades. Las correcciones, funciones automatizadas, y añadidos son conocidos en conjunto como Macros y Scripting. A fin de integrar estas macros en el MS Office, Los menús, botones y barras de herramientas pueden modificase para facilitar su uso.

Ciertos procedures tienen nombres especiales (tales como AutoOpen, AutoNew) que identifican programas que se ejecutarán automáticamente al abrirse el fichero de Office. Esta caraterística se usa a menudo en plantillas, e implican el riesgo de los llamados „Virus de Macro“.

Los macros y scripting pueden activarse e integrarse de las siguientes maneras:

add-ins

En plantillas

En asistentes

Los add-ins pueden dividirse, según su uso, en los siguientes tipos:

add-ins COM

add-ins propios de la aplicación.

Los add-ins COM se compilan con el Visual Basic (versión completa) y generan DLLs ó EXEs que pueden se ejecutados por otras otras aplicaciones.

Los add-ins propios de la aplicación se generan dentro del entorno de programación del Office, y sólo pueden ser usados dentro del Office. Los add-ins se usan habitualmente cuando es necesario que el código del programa esté disponible permanentemente, de modo que el usuario no necesite abrir plantillas.

La ilustración de abajo (Figura 34) da una visión general de las opciones que tiene el usuario, mediante programación, de expandir el Ms Office.

Figura 34: Opciones de expansión del Office

*Entorno de desarrollo

Con la versión 5 de VBA, un entorno de desarrollo uniforme fué integrado en la aplicación Office. Aunque el llamado IDE (Integrated Development Environment - Entorno Integrado de Desarrollo) se ejecuta en una ventana separada, corre en el mismo area de memoria de la aplicación Office.

Este IDE integra:

- un editor con comprobación de sintaxis y resaltado mediante color

- un explorador de proyectos

- una ventana de propiedades adicionales

- herramientas de depuración

- un navegador de objetos

- compilación condicional

- mecanismos de protección contra el cambio o copia del codigo programado

- e IntelliSense (completado, selección mediante menú, información de sintaxis)

Aparte de este editor, también puede usarse un grabador de macros en la aplicación para generar código simple de programa.

*Control remoto

Dado que el propio Office consiste de un gran número de objetos COM, el control remoto de Office, es decir, automatización COM, es posible.

Podemos usar Windows Scripting Host (WSH) o PerlScript, por ejemplo, para control remoto.

3.15.4 Migración de reemplazo

3.15.4.1 Introducción

Un completo abanico de packetes de software Office o sub-aplicaciones (como el procesador de textos) están disponibles como software libre o propietario para el sistema operativo Linux. Algunos ejemplos de estos paquetes se listan a continuación:

- OpenOffice

- StarOffice

- Koffice

- GnomeOffice

- ThinkFree Office

- y muchos más

Todos los expertos están de acuerdo en que, en el momento actual, sólo el paquete OpenOffice.org (OOo) y el paquete StarOffice (SO) basado en él son alternativas reales a la suite MS Office. Esta guia discutirá por tanto estos dos paquetes únicamente con el detalle en vistas a una migración.

OpenOffice está disponible actualmente en su versión 1.0.3, siendo StarOffice 6.0 su equivalente. Ambas versiones pueden también ser usadas en los sistemas operativos Windows NT, 2000 y XP. OOo/SO tienen las mismas capacidades y formatos de archivo en todos los sistemas operativos soportados y por tanto facilitan una migración "suave" en el aspecto de que únicamente el paquete Office es reemplazado durante el primer paso. Las nuevas versiones 1.1 (OOo) y 6.1 (SO) ya están disponibles como versiones beta, y se espera la versión final en Julio de 2003.

*Diferencias entre OpenOffice y StarOffice

La tecnología básica de las dos suites ofimáticas está desarrollada en base a openoffice.org. En el año 2000, Sun Microsystems migró el código fuente del paquete ofimático StarOffice, entonces en su versión 5.2, al proyecto de código abierto OpenOffice.org. El proyecto OpenOffice.org está sujeto a la doble licencia de la GPL y SISL (GNU Public License o Lesser GNU Public License, repectivamente, y Sun Industries Source Licence). La doble licencia permite los productos comerciales derivados de OpenOffice.org por un lado. Por el otro, garantizan que las especificaciones de la API y los formatos de fichero están ligados a OpenOffice.org y son uniformes entre este y todos sus derivados.

Sun ha desarrollado y/o añadido nuevos componentes para StarOffice y compilado un paquete de producto que incluye unas normas de calidad profesionales, extensa y completa documentación y ofertas de soporte y formación. Algunos de los componentes de Sun son:

- Fuentes TrueType similares a las de Microsoft (ver Figura 35)

- Una función de comprobación de escritura propia y diccionarios de sinónimos, con OpenOffice usando normalmente MySpell (LGPL)

- Plantillas adicionales y una galeria de imágenes

- La base de datos ADABAS

Lo que es más, Sun ofrece parches o service packs para las distintas versiones del producto. Actualmente, un nuevo service pack para Star Office con aspectos de seguridad mejorada, correcciones de fallos o mejoras en los filtros de importación es lanzado cada tres meses. En contraste, OpenOffice.org contiene estos componentes únicamente en su última versión[80].

[80] Para más detalles acerca de las diferencias, por favor, consulte:

http://marketing.openoffice.org/conference/presentationspdf/thu1500/SOvsOOo.pdf

A diferencia de la suite libre OpenOffice.org, la suite StarOffice, está disponible previo pago solamente. Los servicios de soporte se deben pagar en ambas variantes. El soporte de StarOffice viene directamente de la mano de Sun y otros distribuidores, mientras que el soporte para OpenOffice.org sólo está disponible por parte de terceros.

Partes componentes de OOo y SO

OOo y SO, igual que MS Office, consisten de varias sub-aplicaciones. Esto incluye:

Procesamiento de texto (Writer)

Hoja de cálculo (Calc)

Presentación (Impress)

Editor de fórmulas 82(Math)

Dibujo83 (Draw)

Bases de datos84 (Adabas)85.

El siguiente debate se centrará sin embargo, sólo en los tres primeros de estos módulos.

Las tres suites ofimáticas son idénticas en sus funcionalidades más importantes, especialmente aquellas que son utilizadas por la mayoría de los usuarios. La mayoría de los usuarios utilizan el mismo reducido grupo de funciones entre todas las funcionalidades disponibles.

Los siguientes capítulos estarán dirigidos a las diferencias más importantes entre MS

81 Fuente: SunMicrosystem

82 Con Microsoft, las funciones que Math ofrece están integradas por via de un editor específico, que se puede abrir via Insert/Object/New/Microsoft formula editor.

83 Con Microsoft las funciones que Draw ofrece, frecuentemente están integradas via la barra, simbolo “Drawing”.

84 No en OpenOffice.org

85 No directamente comparable a Access en Windows.

p 213Office y OOo/SO en detalle. Esta guía se centra inicialmente en los modulos de procesamiento de textos, hoja de cálculo y creación de presentaciones. El capítulo 3.14 discute un reemplazo posible del módulo de MS Access con otro sistema de base de datos en más detalle. El capítulo 3.15.6 describe módulos adicionales de la suite MS Office y otras aplicaciones del escritorio de MS.

3.15.4.2 Diferencias en los formatos de archivo comparados con MS Office

Cada versión de Microsoft Office utiliza su propio formato binario de archivo para almacenar texto, atributos, gráficos incluidos, meta datos y elementos de diseño tales como datos estructurados OLE.

En contraste con esto, OpenOffice.org y StarOffice 6.0 (OOo/SO) utilizan un formato de archivo basado en XML que almacena los contenidos como texto puro y que por tanto puede ser leido directamente y procesado sin que sea necesario tener Ooo/SO para leer y decodificar. El formato está documentado públicamente y disponible como formato libre como parte del proyecto OpenOffice.org.

El formato de archivo basado en XML de OOo/SO almacena los contenidos y la información de diseño y formato de cada documento como un conjunto separado de subdocumentos XML.

Para permitir el uso amigable para el usuario de los diferentes documentos y corrientes XML – además de las imágenes y datos externos (si los hay) incluidos en formato binario – tales documentos y corrientes XML se almacenan en el conocido formato comprimido ZIP. Sin embargo, los archivos generados por OOo/SO tienen distintas extensiones para las distintas subaplicaciones, igual que MS-Office, en vez de tener la extensión “.zip” (véase la tabla 33)Tabla 33: Extensiones de archivo de las aplicaciones de Office más importantes

Además, OOo/SO incluye adicionalmente las subaplicaciones Draw y Math, que forman parte de las tres aplicaciones principales antes mencionadas de MS Office y que no pueden asignarse directamente a una aplicación específica. Draw se puede utilizar para crear documentos gráficos (sxd/std). Math se utiliza para fórmulas matemáticas (sxm/stm). Pueden enlazarse objetos Draw y Math con otros tipos de documentos OOo/SO desde los que pueden ser editados.

Como los archivos OOo/SO son ZIP, pueden desempaquetarse con cualquier programa de UNZIP.

Figura 36: Contenidos de un archivo OOo/SO como se presentan en un visor de archivos ZIP.

Los gráficos u objetos incluidos, si los hay, se almacenan en los directorios “Pictures” u “Objects” respectivamente. Estos directorios incluyen entonces una referencia (href-link) a los correspondientes archivos subordinados.

Un documento OOo/SO típico, que no contenga objetos ni imágenes incluidos, está constituido por los 5 subdocumentos XML siguientes:

content.xml

Almacena los contenidos principales del documento, incluyendo tablas de texto y elementos gráficos. Si existen imágenes u objetos incluidos, éstos se almacenan entonces en los directorios “Pictures” u “Objects” con una referencia (href-link) que se refiere a los archivos subordinados correspondientes.

styles.xml

Almacena las propiedades y atributos de todos los estilos de carácter, párrafo, página, objeto, y numeración que se utilizan en el documento.meta.xml Almacena información general del documento, incluyendo título, tipo, posición, usuario, última modificación, etcetera. Los contenidos de este archivo se refieren a la información introducida en las propiedades de archivo.

settings.xml Guarda aplicación específica del documento y opciones de vista para el actual documento, además propiedades predefinidas de impresora y opciones de impresión, nivel de zoom y tamaño de la ventana.

manifest.xml Guarda información adicional relativa a los archivos XML, como el tipo MIME y el método de encriptado. Este archivo es como archivos de mapas de bits y archivos de objetos, es también guardado en su propio directorio.

Si el documento también contiene macros, el paquete contiene ademas extensiones XML .

Restricciones relativas a la conversión(importación):

OOo/SO dispone de varios convertidores de formato(filtros) que se habilitan al abrir y editar los documentos de MS Office con OOo/SO y el subsiguiente almacenamiento de cada documento como documento de MS Office. Además, es también posible importar y editar plantillas de documentos de MS . Los archivos pueden ser guardados en el formato MS Office 97/2000/XP o en el formato OOo/SO.

La calidad de conversión es generalmente aceptable a excepción de complicados documentos que contengan macros y formatos de características especiales involucrados. Determinadas características de esquema de MS Office y atributos de formato que OOo/SO no soporte o trate diferente. Esto significa que un documento convertido debe ser manualmente reeditado para que el orden ciertamente se corresponda con el documento original. Una conversión del 100% no debe ser esperada especialmente en el caso de complejas propiedades muy específicas del documento, como índices, campos, esquemas y tablas. Además, diferencias entre el documento original y el convertido pueden ocurrir también despues de la conversión de atributos básicos y instrucciones de formato, como los márgenes de página y los spacios en blanco entre los parrafos.

La tabla de abajo(Tabla 34) muestra las propiedades de MS Office que requieren la reedición manual despues de la conversión automática.

Table 34: Propiedades problematicas de MS Office en la conversión a Ooo/SO

Aplicación	Propiedades
Microsoft Word	Autoformas Marcas de revisión objetos OLE

3.15.4.4 Diferencias funcionales

A un nivel conceptual, no hay diferencias fundamentales entre MS Office y Ooo/SO. Ambos sistemas están basados en una arquitectura de tres capas consistentes en la misma aplicación, las plantillas de documentos y los documentos. La capa más baja es la capa de aplicación que contiene las herramientas y las propiedades para crear documentos y plantillas. La siguiente capa es la capa de plantillas que puede contener un gran número de objetos, macros, instrucciones de formato y configuraciones que simplifican la creación de nuevos documentos. Esto concierne a los documentos que, en la capa superior, pueden contener a su vez más objetos, macros, instrucciones de formato y configuraciones de usuario que complementes la funcionalidad de las plantillas.

La diferencia entre las dos suites ofimáticas radica en las características y funcionalidades que ofrecen y soportan. En muchos casos, estas diferencias son concernientes al diseño seleccionado y a los diferentes modelos de objetos contenidos en las aplicaciones. En la mayor parte de los casos, ambas suites realmente incluyen propiedades equivalentes correspondiendo a características individuales y funcionalidades del otro producto.

La tabla de abajo (Tabla 35) nos da una visión de las plantillas y los tipos de formato disponibles en MS Office y Ooo/SO para las diferentes aplicaciones.

La tabla de abajo (Tabla 36) resume las diferencias en las funciones clave. la “Guia de Migración a StarOffice 6.0” nos da una descripción detallada de mejores funcionalidades y otras diferencias.Criterio importante para la renovación del inventario

Antes de tomar la decisión fundamental en favor o en contra de la migración y analizar la viabilidad del subsecuente detallado planteamiento, debería contestarse a las siguientes preguntas, en el alcance de su inventario:

¿Qué se va a migrar?

¿Es posible la migración?

¿Qué esfuerzos y coste se necesitarán?

Durante la migración se deberían analizar y, de ser necesario, realizar una categorización de los documentos respecto a los siguientes criterios:

Disponibilidad de los documentos
Documentos que necesitan ser procesados o editados con posterioridad. La conversión puede tener lógica en caso de estos documentos
Documentos que, como mucho, sólo serán leídos. Debería considerarse el archivado o la conversión de esos documentos al formato PDF. En caso de migración, ésto reduce considerablemente el esfuerzo requerido.

Complejidad de los documentos
Documentos simples. Estos documentos no contienen macros, gráficos en formatos propietarios (como WordArt), gráficos vectoriales, instrucciones de formato complejas o elementos como notas al pie, tablas o índices. Estos documentos puede ser convertidos fácilmente mediante un proceso por lotes (consulte la sección “Métodos de conversión en el capítulo XXX).
Documentos complejos. Estos documentos contienen macros, componentes compartidos, instrucciones de formato de página y párrafos, gráficos propietarios y de vectores, muchos enlaces y referencias cruzadas, objetos OLE, marcos, cajas de texto, notas al pie, componentes activos, campos de formularios, controles de formularios, formularios o gráficas, por ejemplo, un compendio de diferentes formatos y elementos. Estos documentos requieren, normalmente, planificación adicional y deberían ser evaluados y convertidos de manera individual.

Complejidad de las plantillasComplejidad de las plantillas
Plantillas simples. Consisten en texto genérico y el formato correspondiente que sirven como punto de salida o modelos iniciales para nuevos documentos. Buenos ejemplos son cartas modelo, informes generales o actas. Se pueden aplicar las mismas opciones de conversión que existen para los documentos simples a las plantillas simples.
Plantillas complejas. Contienen campos de formularios y macros que no siempre son fáciles de convertir y que deberán recrearse desde cero con el entorno de desarrollo Ooo/SO y, a veces, incluso requieren de un proceso de reingeniería.

Uso de fuentes de datos externas. Estas fuentes de datos externas suelen necesitar un reenlace, que puede hacerse sin mayores problemas. Fuentes de datos de este tipo suelen ser, por ejemplo, bases de datos y documentos Excel.

Integración de software externo. En estos casos, por una parte, debe evaluarse el alcance del proyecto de migración y el número de aplicaciones involucradas y, por otra parte, comprobar la disponibilidad del código fuente con vistas a la integración en Ooo/SO. Si el software externo está enlazado con MS Office mediante la interfaz de automatización OLE, es posible su enlace con Ooo/SO usando esta interfaz. Las invocaciones a funciones de MS Office deberán convertirse a las correspondientes invocaciones a funciones de Ooo/SO.

Preparando la conversión

Documentos Word

Muchas diferencias en la disposición del documento tras la migración se debe a un formateo incorrecto. Para aumentar la fidelidad de la disposición, deberán tomarse medidas para asegurar que el texto original es o ha sido adecuadamente formateado. Debería aplicarse el siguiente aviso durante el trabajo diario, incluso si la migración no va a realizarse en un plazo breve.

Utilizar plantillas de formato de carácter y párrafo en vez de formatear directamente el texto.

Eliminar los retornos de carro innecesarios entre elementos de las listas para crear el espaciado deseado entre cada uno de ellos. Durante la conversión, estos retornos generan viñetas adicionales vacías de contenido (entradas de lista blancas).

No utilizar múltiples desplazamientos de tabulación para crear columnas de tablas. Definir las separaciones de tabulación de tal forma que sólo una única tabulación separe dos columnas. También puede usarse como alternativa una herramienta de creación de tablas. Si se utilizan múltiples tabulaciones, puede pasar que una tabla parezca “fuera de rango” tras la conversión debido a que las aplicaciones utilizan diferentes distancias de tabulación por defecto.Asegurarse de que el formato de la página del documento es idéntico al tamaño de página de la impresora. Ooo/SO no ajustan el tamaño de página automáticamente, por lo que pueden obtenerse copias impresas incorrectas.

Documentos Excel

Deberían comprobarse las hojas de cálculo grandes y complejas con la vista puesta en las técnicas especiales de formato empleadas y la lógica (fórmulas, añadidos) contenida en ellas para asegurar una conversión correcta. Esto es especialmente importante en el caso de añadidos de terceras partes o del propio Excel.

A continuación se explican brevemente los aspectos involucrados:

Comprobar las fuentes de datos de los gráficos. Excel es, en general, mucho más flexible que Calc a la hora de definir los rangos de datos de los gráficos. Ooo/SO estipula, por ejemplo, que las etiquetas deberán figurar siempre en la primera fila o columna. Si no es así, los gráficos importados suelen carecer de etiquetas.

¿Existe un sistema de protección por palabra clave en los documentos? Calc no puede abrir las hojas Excel protegidas por contraseña. Esto significa que la protección deberá eliminarse antes de la conversión.

Evitar matrices de constantes en las fórmulas. A diferencia de Excel, Calc no soporta matrices de constantes en las fórmulas (como {1,2;3,4}), si no sólo áreas de celdas que especifiquen una matriz (como {A1:B2}).

Evitar el uso de caracteres especiales en los nombres de las hojas de trabajo. Excel soporta más caracteres especiales que Calc en estos nombres.

Evitar hojas de trabajo de más de 32000 líneas de entrada y hojas de cálculo de más de 256 hojas de trabajo, ya que Calc, actualmente, no soporta más entradas de las mencionadas (consultar también 3.15.4.3).

Evitar diferentes modos de visualización para diferentes hojas de trabajo, característica soportada por Excel. Calc sólo permite definir un modo globar de visualización para el documento completo.

Comprobar el tamaño de celda respecto al texto justificado a la derecha. Si la celda es muy pequeña, el texto justificado a la derecha no es extendido a la izquierda más allá de los límites de su celda.

Documentos PowerPoint

Las presentaciones PowerPoint sencillas son aceptadas por Impress correctamente y sin problemas. Las presentaciones con funciones de disposición extendidas y con efectos normalmente conducen a modos de representación diferentes en el documento convertido.

Las medidas listadas a continuación han sido diseñadas para ayudar a preservar el formato original:

Evitar, eliminar o modificar el sombreado de objetos, ya que no está soportado por Impress. Éste no soporta todos los formatos de sombreado de PowerPoint. La ilustración (Figura XX: Objetos sombreados en PowerPoint e Impress) muestra la conversión de sombreados desde PowerPoint a Impress.

Página 223

Evitar, eliminar o modificar los atributos de los objetos.

Mezcla de color basada en tres colores.

Márgenes con dos y tres líneas.

Estas características no están implementadas en Impress. Antes a la conversión, estas características deberían cambiarse a:

Mezcla de color basada en dos colores.

Márgenes con una línea.

Las esquinas redondeadas son automáticamente convertidas a esquinas cuadradas.

Información perdida en las propiedades del documento.

Al contrario que PowerPoint, Impress no almacena la fecha del último acceso. Además, las propiedades del documento PowerPoint no son importadas al documento convertido. Si fueran necesarias, se podrían usar macros para compensar o evitar estas dos deficiencias.

Selección aleatoria con efectos múltiples de transición.

Impress no tiene implementada la selección aleatoria combinada con el uso de efectos múltiples de transición. Es importante que esos efectos de transición sean cambiados a simples efectos antes de la conversión. De lo contrario, estos efectos múltiples se transforman en efectos de líneas verticales durante la conversión.

También indicar que Impress usa distintos nombres para determinados efectos de transición y a veces un comportamiento ligeramente distinto que PowerPoint.

Falta el apoyo de la función "registro de narración".

En contraste a PowerPoint, Impress no tiene implementada la función "registro de narración". Impress crea un archivo de sonido distinto para cada transparencia. Para reutilizar las grabaciones realizadas en PowerPoint, estas deberían ser o bien regrabadas o bien convertidas en un proceso de división .

Página 224

Figure 37: Objetos en la sombra en PowerPoint e Impress .

Proceso de conversión.

Métodos de conversión.

Los documentos de MS Office pueden convertirse a OOo/SO por el software, tanto como una simple conversión o como un proceso de conversión en cola.

Conversión simple.

El documento MS se abre en OOo/SO y almacenado como un documento OOo/SO.

Conversión en cola.

Los archivos del documento son copiadas en un directorio aparte (el cual debería crearse específicamente para este propósito). La función OOo/SO "Archivo / Autopiloto / Document converter" puede ser usada entonces para comenzar el proceso en cola. En primer paso, el formato fuente (MS o OOo/SO) es seleccionada (remitirse a la figura 38). A esto lo sigue la definición de a qué documentos o plantillas van a ser convertidos y en qué directorio fuente pueden estos ser encontrados. Además, todos los documentos MS en el directorio fuente son convertidos y almacenados como documentos OOo/SO en el directorio destino.Como la imagen superior (Figura 39) muestra, El conversor puede discriminar entre documentos y plantillas de documentos. La principal diferencia es que las plantillas de MS Office son archivadas como plantillas Ooo/SO.

El tipo particular de conversor mas favorable en un caso dado depende de la complejidad de los documentos o de las plantillas (acudir al apartado 3.14.4.5)

Además, una situacion donde macros, control OLE/COM, o integración de aplicaciones externas son factores importantes, debe ser examinada con mas detalle. Esto se verá después de nuevo.

Opciones de conversión

Como forma de optimizar conversiones individuales o en bloque, Ooo/SO activa características de compatibilidad en función de las opciones.

Comprobando los documentos convertidos

Después de la conversión, los documentos deben ser comprobados para estar seguros de que las siguientes características se se convirtieron correctamente:

-Tamaño de carácter.

-Margenes

-Tabulaciones

-Sangrados

-Longitud de linea (Caracteres por linea)

-Separación de lineas entre párrafos.

-Tablas

-Cabeceras y pies de pagina

-Listas

-Imágenes

Otras conversiones

Además de las conversiones generales de documentos y plantillas existentes, puede ser necesario importar en el nuevo sistema entradas de autotexto y diccionarios propios de usuario que hayan sido desarrollados durante un periodo de tiempo largo.

La exportación de entradas de autotexto desde plantillas existentes a Ooo/SO puede ser automática

MS Office y Ooo/SO soportan la creación y administración de diccionarios de usuarios. Aunque estos diccionarios tienen extensión ".dic" en ambas aplicaciones, unos no son compatibles con otros. MS Office almacena sus diccionarios como texto plano, mientras que los diccionarios de Ooo/SO se almacenan en un formato propio. Por ahora no existe un método de migración automático.

3.15.4.8 Integración de aplicaciones externas.

En el caso de las aplicaciones externas, su grado de integración en la suite MS Office, juega un importante papel a la hora de la migración a Ooo/So. Muchas aplicaciones especificas y generales que están todavía en uso en las agencias publicas....Descripcion técnica de la migración de rutas
agencias públicas están específicamente diseñadas para el uso en entornos de sistemas dominados por
MS Windows y dependen fuertemente de los módulos propietarios de la API de Windows, como:
MAPI
COM
DDE
...
El grado de integración dentro del entorno de Windows puede variar fuertemente de caso en caso. Una simple y aún poco problemática integración es el uso de la interfaz MAPI para el acceso al cliente de
correo estándar desde una aplicación. Un mayor grado de integración esta obviamente dado si una
aplicación externa permite solo a ciertas aplicaciones MS e/o inclusive si las aplicaciones MS son obligatorias para poder utilizar toda la funcionalidad de una aplicación dada.

Estas diferencias en el grado de integración de aplicaciones externas dentro de Windows y en la suite MS Office requieren un examen cuidadoso como hasta donde es técnicamente factible la migración y que esfuerzos se requieren para ello. Si el código fuente de la aplicación externa está disponible , debe ser examinado por completo para ver si la integración dentro de OOo/SO es posible a través de la interfaz UNO (Universal Network Objects/Objetos de Red Universales) requerida por OOo/SO98.
3.15.4.9 Migración de macros y controles OLE/COM
Las Macros y OLE/COM son métodos utilizados intensivamente para extender las funcionalidades Office y para la automatización de Office bajo Windows (ver capitulo 3.15.3.2). Incluso utiliza la automatización en el progreso de trabajos completos entre departamentos individuales de una misma organización. Como las macros y scriptings en principio están basados en VBA, no pueden ser ejecutados bajo OOo/SO. Por el momento el soporte para la migración automatizada a OOo/SO no se ofrece. Esto significa que las macros existentes y las aplicaciones OLE/COM deben ser migradas manualmente o crearlas de nuevo si van a ser utilizadas más adelante. Dependiendo de la cantidad, el grado de complejidad y la calidad de la documentación, puede significar un esfuerzo de migración substancial y por tanto costos considerables. Por el otro lado, esto posibilita la consolidación de las
macros y las aplicaciones OLE/COM como también la reorientación de la estrategia IT para la automatización de office.

Nota:Para volvernos más independientes de un paquete particular de Oficina en el futuro, los módulos necesarios para los propósitos de automatización deberían ser implementados como componentes Java o C++.

97 Para mas detalles respecto de UNO, por favor lea:
http://udk.openoffice.org/common/man/uno.html
98 La Guía de Migración a StarOffice 6.0, página 73,
explicación de integración dentro de OOo/SO en 5 pasos..

Página 234DESCRIPCIÓN TECNICA DE LAS VIAS DE MIGRACIÓN

Entorno de programación de Ooo/SO

Como MS Office, OOo/SO viene con un API99. La API OOo/SO ha sido diseñado de una manera independiente de un lenguaje de programación o un sistema operativo. En el momento presente OOo/SO puede programarse en lenguajes Java, C++ y StarBasic y bajo Windows por medio de control OLE/COM. Todos los lenguajes de programación usan la misma API, por lo tanto son posibles las mismas tareas. Aún más, tanto Java como C++ permiten el desarrollo de componentes que pueden realizar las más variadas funciones como extensores (plug-ins) en OOo/SO:

Nuevos tipos de mapas

Nuevas funciones de calculo

Ayudantes

Funcionalidad adicional para el usuarios

Actualización de StarBasic

StarBasic es un lenguaje de codigo modular e integrado y sigue los mismos principios que VBA. Ambos lenguajes ofrecen, en muchos aspectos, una estructura y sintaxis muy similar, por lo que programadores expertos en VBA no tendrán dificultades en migrar las macros VBA.

Además de el API, OOo/SO al igual que MS Office ofrece un entorno integrado de desarrollo(IDE) con una interfaz de usuario fuertemente orientada hacia el entornno de desarrollo de MS Office100.

Compatibilidad con MS Office

En los capitulos anteriores hemos visto que no se da un 100% de compatibilidad con MS Office . ¿Como afecta esto con respecto al intercambio de documentos entre usuarios de OOo/SO y usuarios de MS Office? Esta cuestión debe contestarse bajo dos aspectos.

Se debe considerar el proposito de el intercambio de documentos.

También se debe considerar la complejidad de los documentos a intercambiar.

Los documentos son intercambiados con propositos meramente informativos

En este caso la complejidad de los documentos no juega ningún papel. Los documentos a ser intercambiados deberían ser convertidos a un formato PDF. Para todos los usuarios hay copias gratuitas del Lector de PDF y se pueden descargar de Internet sin costo. Ya hace tiempo que el formato PDF ha sido recomendado a las Agencias Federales para el intercambio de documentos.

99 Para información relevante en este contexto, por favor dirijase a http://api.openoffice.org/ (documentación en línea). En la siguiente URL se puede encontrar la especificación de la interfaz http://udk.openoffice.org/ .

100 Para más detalles respecto al uso de los entornos de desarrollo y programación dirijase, por favor, a las páginas 79-90 de “Star Office 6.0 Guia de migración”.DESCRIPCIÓN TECNICA DE LAS VIAS DE MIGRACIÓN

Los documentos son intercambiados con el proposito de un procesamiento en común

Tal y como se ha mostrado en las explicaciones anteriores, la complejidad de los documentos juega un papel muy importante en este caso.

Los documentos simples se pueden procesar conjuntamente sin mayores problemas.

Las funciones de edición son interoperables en OOo/SO y MS Office.

Sin embargo, en el caso de documentos complejos a procesar conjuntamente, son inevitables restricciones importantes.

En lo que respecta a la funcionalidad de proceso de textos y hojas de calculo, el proceso conjunto sólo se puede recomendar a nivel de contenidos. Las responsibilidades del formato se deben asignar muy claramente a una parte, y el formateo no debe tener lugar hasta que el contenido ha sido completado. Ambas partes deben estar de acuerdo con respecto a el procedimiento.

En cuanto a lo que concierne a los documentos de hojas de calculo, los diagramas no se pueden generar hasta que los contenidos de datos han sido completados, esto es así debido a las diferencias entre los motores de generación de diagramas. Si los diagramas van a ser generados utilizando Calc, las restricciones (ver más arríba) en la creación de etiquetas deben ser tomadas en consideración.

El proceso conjunto de tablas Pivot no es posible debido a que no estan soportadas por Calc.

No es recomendable el proceso conjunto de presentaciones complejas.

Para el caso de proceso conjunto o edición de documentos bajo OOo/SO y MS Office, se deben observar las siguientes reglas:

Ponerse de acuerdo en un formato de documento.Si la elección es entre OOo y SO, el uso de los formatos de MS Office es obligatorio, ya que MS Office no incluye filtros OOo/SO. Si existe un formato que ambas versiones puedan manejar – tal como RTF – debe ser usado.

Evitar la así llamada conversion “de vuelta”.

Formatear solo en la última fase ya que la correlación entre OOo/SO y MS Office no funciona una-a-una.

No formatear documentos en formato mezclado, ya que:

van a ser utilizados por muchos y

que puedan incluir funciones automaticas.

Convertir los documentos finales a un formato PDF.

Continuando la migración

Respecto a la continuación, la migración de Office 97 a Office XP (2002) es el principal punto de interes ya que los cambios que son relevantes para un estudio de la migración tienen lugar entre estas dos versiones. En el caso de cambio de Office 2000 a Office XP, los cambios a considerar son mucho menos importantes o ya fueron implementados y serán considerados en conjunto con la migración de Office 97 a Office XP.DESCRIPCIÓN TECNICA DE LAS VIAS DE MIGRACIÓN

Versiones de MS Office más antiguas que Office 97 no serán tomadas en consideración en esta guia.

Microsoft también usa principalmente Office 97 como la referncia basica en sus documentos que tratan sobre la migración a Office XP101 y en sus descripciones de las diferencias comparadas con versiones anteriores102.

Más aún, también debe darse una revisión superfical de las nuevas características que resulten de un cambio a Office 2003.

Office 97 a Office XP

Conversión de documentos existentes

En gran medida los formatos de los documentos se dejaron sin cambiar. Estos pueden simplemente ser abiertos por las aplicaciones Office XP respectivas. Sin embargo, no se dispone de una experiencia contrastada para confirmar que realmente esto funciona para todos los formatos, modelos, macros y codigo. Existe evidencia de que los documentos y los modelos de que no pudieron convertirse, en algunos casos, sin dificultad,

Tal y como con OOo/SO, Office XP también permite la conversión en lote por medio de un “Ayudante de Conversión en Lote”. Microsoft también ofrece un “Paquete de conversión de Office” además del filtro103 estandar de conversión.

Compatibilidad con versiones anteriores

Los formatos de archivo de Office 97, 2000 y XP son compatibles. Todos los documentos pueden generalmente ser editados y almacenados en cada versión. Sin embargo, puede ocurrir que ciertas funciones nuevas y opciones de formato de Office XP no tengan contrapartida en Office 97. Sin embargo, de acuerdo con el Whitepaper titulado “Microsoft Office XP y Compartición de Archivos en un Entorno de Oficina Heterogeneo”104, estos no se pierden en la edición con Office 97 y pueden ser reutilizados cuando el documento es abierto la proxima vez en Office XP.

Migración de macros, codificación e integración de aplicaciones externas

La principal dificultad cuando se migra a Office XP reside en los cambios dentro del entorno de programación de Office. El cambio en el “Modelo de Objeto” requiere una atención particular en este contexto.

Con el cambio de la version 5 a la versión 6 (Office 2000) de VBA y la versión 6.3 (Office XP), especialmente el cambio en el metodo utilizado para unir objetos es lo que tiene repercusiones en la compatibilidad de versiones anteriores y por lo tanto con la migración. Generalmente uno puede asumir que las aplicaciones de Office (macros, codificación, aplicaciones externas) que fueron desarrolladas en el entorno de programación de Office 97 también pueden ser utilizadas en un entorno de Office XP sin problemás y sin ninguna necesidad de adaptación.

101 Microsoft Office XP Deployment Planning Blueprint, Marzo del 2001 (XPBluePrint), y “Office XP Migration Blueprint”, Jerry Honeycutt, Febrero 2003 (magrionblueprint)

102 “Comparación de versiones de Microsoft Office” (Compare)

103 http://www.microsoft.com/office/ork/xp/appndx/appa09.htm

104 http://www.microsoft.com/office/techinfo/deployment/fileshare.asp

DESCRIPCIÓN TECNICA DE LAS VIAS DE MIGRACIÓN

Sin embargo, y a pesar de la compatibilidad generalmente existente hacia abajo, Microsoft no impide que haya excepciones que requieran un ajuste105.

La situación opuesta es mucho más dificil. Significa que las aplicaciones nuevas que fueron desarrolladas para Office XP dificilmente pueden ser utilizadas sin problemas en un entorno de Office 97. Esto se aplica, principalmente, a las macros y debe ser considerado si no se va a realizar un cambio completo o gradual en una organización que use ambas versiones de Office al mismo tiempo.

En vista de la incertidumbre sobre si el uso continuo de todas las aplicaciones Office se mantendrá seguro, o bién las aplicaciones necesitarán adaptarse, es necesario un cuidadoso almacenamiento de las macros existentes, del codigo y de las aplicaciones externas, tal como en el caso de una migración de reemplazo.

Diferencias en funcionalidades

Respecto a los cambios funcionales, la introducción de las así llamados etiquetaslistas (smarttags)106 y las funcionalidaes extendidas para el proceso conjunto, edición y uso de documentos, permanecen en primer lugar.

Las etiquetaslistas son otro medio de automatización que ofrece a los usuarios un soporte sensible al contexto. Una etiquetalista ejecuta una función en respuesta a una entrada (por ejemplo, una palabra en particular o cierto número). Las etiquetaslistas simples o basadas en COM pueden ser diferenciadas. Las simples107 son administradas en listas XML que se almacenan en un punto central de la red de ordenadores, estando así disponibles para todos los usuarios. Las que se basan en COM108 son usadas como 'añadidos'. Sin embargo, las etiquetaslistas no parecen ofrecer ventajas tan importantes. Por supuesto que las etiquetaslistas adecuadas pueden pueden dar soporte a usuarios inexpertos al darles pistas a la funcionalidad y formateando las ayudas disponibles cuando sea necesario. Sin embargo, también pueden conducir a una total confusión si el usuario inexperto no entiende las funcionalidades ofrecidas. Para evitar esto, será necesario que se necesite aumentar los esfuerzos en entrenamiento además de un cambio.

Considerando el futuro, las etiquetaslistas son otro dispositivo de automatización especifico de aplicaciones y que no corresponden con ninguno de los estandares abiertos y que solo pueden ser utilizados con MS Office. Un uso intensivo de las etiquetaslistas hará que sea requerido un mayor esfuerzo para reemplazar MS Office, o incluso puede impedirlo por razones economicas.

Los así llamados “SharePoint Team Services” (Servicios de Punto Compartido en Equipo) están en el corazón de las funcionalidades extendidas para el proceso conjunto y usan documentos de Office.

105 “Kit de recursos de Microsoft© Office, Articulo Tecnico (whitwpaper), Temas de Migración deMicrosoft Office 97 a Microsoft Office XP” (Xpdelta).

106 Einführung in Smarttags auf den Microsoft Web-Seiten

107 http://www.microsoft.com/germany/ms/officexp/developer/smarttags/einfuehrung.htm

108 http://www.microsoft.com/germany/ms/officexp/developer/smarttags/comsmarttag.htmDESCRIPCIÓN TECNICA DE LAS VIAS DE MIGRACIÓN

Estos no deben ser confundidos por el “SharePoint Portal Server” que se introduce en el capitulo 3.12109. El sitio hhtp://www.microsoft.com/sharepoint/server/evaluation/overview/technologies.asp da un resumén de las mayores diferencias y las interacciones.En principio, los “SharePoint Team Services son la versión ligera del Portal Server y no tienen más que una funcionalidad muy simplificada de administración de contenidos. Hace que estén disponibles conjuntos de documentos de los grupos de trabajo en una plataforma Web, via la intranet o la Internet, a todos los miembros de un grupo de trabajo. Debido a su diseño sencillo, los servicios de SharePoint Team son muy adecuados para pequeñas organizaciones y para grupos de trabajo ad-hoc, incluso trabajando más alla de los limites de la organización usando Internet. Sin embargo, también hay que tomar en consideración los riesgos potenciales de seguridad.

Los autores de esta guia de migración ven aproximaciones muy prometedoras, especialmente en este punto, con respecto a la preparación conjunta y publicación por grupos de trabajo de documentos independientes de formatos propietarios, de una menera sencilla basados en Web y en XML (separación de contenidos y presentación). Especialmente en el caso de cooperación que traspase los limites de las organizaciones, no se puede asumir que todos usan las mismas herramientas. Para mantenerse abierto a cualquier forma de cooperación se deben utilizar estandares generalmente aceptados, tales como XML. Parece que Microsoft también lo ha entendido y en el futuro intensificará el uso de este estandar con el producto Office 2003.

Outlook a Office 2003

Con Office 2003 planificado para ser lanzado antes de finales de verano (Junio de 2003), Microsoft planea enfocar su paquete de Office a incrementar el uso de XML La información actual disponible proviene de informes de uso de la versión beta 2 de MS Office 2003110 y de descipciones tecnicas y articulos publicados por Microsoft111. Casi toda la información se refiere al uso de XML en Word 2003.

Esta información sugiere lo siguiente.

Aunque Microsoft ha orientado su XML hacia el estandar de W3C (World Wide Web Consortion), lo ha modificado para sus propositos.

Esta XML modificado será el formato de archivo estandar en Office 2003. Sin embargo, los formatos anteriores se pueden utilizar en paralelo con éste.

Un esquema separado, XML especifico de Word (Word ML), existe para Word.

Además, los archivos de Word pueden ser almacenados en un formato “puro XML”. En este caso, se informa al usuario de que la información de formato se puede perder.

Si se abren en Word documentos externos XML, se debe suministrar, al mísmo tiempo un archivo de esquema valido.

109 El sitio http://www.microsoft.com/sharepoint/server/evaluation/overview/technologies.asp da un breve resumén de las principales diferencias e interacciones.

110 http://xml.coverpages.org/microsoftXDocs.html

111 Microsoft Office Word 2003 Beta 2 Previes (Parte 1 de 2), Microsoft Office Word 2003 Beta 2 Preview (Parte 2 de 2). Beitrag aus TechNet Datebank y otros.

DESCRIPCIÓN TECNICA DE LAS VIAS DE MIGRACIÓN

Las propias hojas de estilo (archivo XLST) puede ser asignadas a documentos externos.

Sin embargo, durante el almacenamiento en formato XML especifico de Word, solo se genera un archivo que contiene todo.

La situación será similar con Excel 2003.

Office 2003 viene con un comprobador XML que genera mensajes de error si, por ejemplo, la sintaxis utilizada es incorrecta o si un documento no cumple con el archivo de esquema especificado.

Sin embargo, esta información no es base suficiente para poder evaluar la compatibilidad entre “XML estandar” y “XML Microsoft”. En éste contexto, la principal cuestión reside en saber que repercusiones tendrán las extensiones XML implementadas por Microsoft, respecto al intercambio de documentos entre diferentes plataformas, y si Microsoft desvelará sus correcciones.

Aplicaciones adicionales de escritorio

Además de los paquetes de Office vistos anteriormente. Aún hay bastante cantidad de aplicaciones de escritorio que se han hecho vitales para el trabajo diario. En lo que sigue se describirán las aplicaciones alternativas más adecuadas para el escritorio de Linux, incluyendo hechos clave para las aplicaciones más importantes del escritorio de Windows.

MS Project

En el momento actual una solución comparable a Microsoft Project aún no esta disponible bajo Linux. Aúnque algunos proyectos (tales como Mr. Project112 y Gantt Project113) estan trabajando en ello, aún no ofrecen ni una fracción de las funcionalidades que MS Project ofrecce.

Escritorios

La mayor parte de las distribuciones de Linux ofrecen a los usuarios escritorios ya preparados que integran las aplicaciones más importantes, de una forma similar al escritorio de Windows. Los dos representantes más importantes son KDE y GNOME.

Las interfaces graficas de usuario de los escritorios son implementadas por medio del sistema X-Window y sus manejadores de ventanas.

Aclaración: el sistema X-Window y el Manejador de Ventana

El sistema X-Window, también simplemente referido como “X”, es un sistema de ventanas con capacidad de red, que se utiliza especialmente con Linux. X se basa en el principio de cliente-servidor, con el servidor suministrando los recursos de pantalla, teclado y ratón, y el cliente, que es un programa de aplicación, comunicandose con el servidor por medio del protocolo X. El servidor y el cliente pueden estar ejecutandose en maquinas diferentes o en la misma maquina.

112 http://mrproject.codefactory,se/

113 http://ganttproject.sourceforge.net/

114 Para más información, por favor dirijase a http://www.x.org

DESCRIPCIÓN TECNICA DE LAS VIAS DE MIGRACIÓN

Esta es la regla cuando Linux se utiliza en los Pcs. Su capacidad en la red hace que X sea particularmente adecuado para clientes delgados (con pocos recursos).

El aspecto de la interfaz grafica del usuario se determina por el conjunto de herramientas utilizados (tales como Xt, controles Athena, OSF/Motif, Tk, Qt, Gtk+, etc.) y el manejador de ventana respectivo (tal como IceWM) más que el mismo X.

El manejador de ventana es un cliente X responsable de manejar la estructura, tamaño etc. de las ventanas del programa, así como sus “aderezos”, i.e. Las tablas de colores y otras muchas características disponibles. Se dispone de una gran cantidad de manejadores de pantalla para uso en escritorios definidos y diseñados115 por el usuario. Los escritorios descritos a continuación tienen sus propios manejadores de ventana.

KDE

KDE es un entorno de escritorio trasparente y moderno para computadoras con Linux y UNIX. KDE es el acrónimo del proyecto Open Source “K Desktop Environment”. KDE ofrece un aspecto similar a los escritorios de Windows y Mac (ver la figura 40). Sin embargo, este aspecto puede ser modificado en la forma que desee el usuario (vease la figura 41).

Practicamente todo puede ser cambiado en principio. Se pueden escoger temas de color diferentes, conjuntos de iconos y marcos, en parte en función del manejador de ventana subyacente que además puede ser libremente seleccionado.. Todos los manejadores de ventana de X11R6 pueden ser usados. Este diseño flexible y las opciones de estructuración permiten la creación de un escritorio uniforme, adaptado a los requerimientos especificos de una agencia publica o departamento. Al mismo tiempo, se puede dar a los usuarios individuales un alto grado de libertad con respecto a la estructura de sus escritorios personales.

115 http://www.pliq.org/xwinman/intro.html

DESCRIPCIÓN TECNICA DE LAS VIAS DE MIGRACIÓN

Figura 40: escritorio KDE – ejemplo 1116

Figura 41: escritorio KDE – ejemplo 2117

116 Fuente: http://www.kde.org/screeshots/

117 Fuente: http://www.kde.org/screeshots/KDE viene con su propio paquete de oficina "Koffice". Las aplicaciones adicionales de escritorio de KDE son las siguientes:

El gestor de ficheros y navegador "Konqueror" (ver capítulos y )

El cliente de correo "KMail" (ver capítulo )

El software de grupo "Kroupware" desarrollado por la Oficina Federal Alemana para la Seguridad de la Información (BSI) (ver capítulo )

El reproductor de medios "Noatun"

Características adicionales importantes son las variadas herramientas de administración y el entorno de desarrollo integrado. La documentación completa está disponible en http://docs.kde.org/.

Además, todas las "aplicaciones no KDE" pueden ser accesibles vía KDE.

GNOME

GNOME es parte del proyecto de Open Source de GNU . GNOME significa "GNU Network Object Modell Environment" (Entorno de Modelo de Objetos de Red de GNU). En términos de disposición, GNOME es tan flexible como KDE (ver Figura 2 y Figura 3).

GNOME también viene con su propio paquete de oficina y entorno de desarrollo. Algunas de las aplicaciones más familiares son:

Los gestores de ficheros "GNOME Commander" y "Nautilus" (ver capítulo 3.15.6.3)

El cliente de correo "Balsa"

El navegador "galeon" (ver capítulo 3.15.6.4)

El empaquetador "GnomeZip"

Una lista más completa de aplicaciones disponibles puede encontrarse en http://www.gnome.org/softwaremap/.

Figura 2: Escritorio de GNOME – ejemplo 1

Figura 3: Escritorio de GNOME – ejemplo 2

DESCRIPCIÓN TECNICA DE LAS VIAS DE MIGRACIÓN

Manejadores de archivos

Konqueror

Nautilus

GNOME Midnightcommander

Lectores Web

Linux ofrece a los usuarios todo un rango de diferentes lectores que pueden seleccionar como deseen o requieran. Los más importantes son:

Galeon

Galeon122 es un lector Web de GNOME que se basa en “Gecko”, que es la maquina de visualización de Mozilla. Galeon es ligero y con una funcionalidad basica. Sin embargo es rapido y compatible con todos los estandares

Beonex Communicator

Beonex Communicator es un lector Open Source sujeto a la licencia GPL. Este lector esta disponible en todas las distribuciones Linux conocidas y también en otras plataformas. Beonex Communicator esta considerado como uno de los lectores más seguros.

Konqueror

Konqueror123 puede ser utilizado no solamente como un manejador de archivos (ver más arriba), sino que tambien como un lector Web bajo KDE. En una forma similar a el Explorador y el escritorio de Windows, Konqueror esta completamente integrado con el escritorio de KDE. Konqueror también esta sujeto a la licencia GPL.

Mozilla

Mozilla124 es un lector Open Source, su codigo fuente esta disponible bajo cuatro licencias, i.e. MPL (“Mozilla Public License”), NPL (“Netscape Public Licence”), LGPL y GPL e incluso bajo la así llamada “tri-license”, i.e. 125 MPL/LGPL/GPL.

Netscape

Netscape versión 7.x se basa en el lector Mozilla y viene con funciones adicionales.

Opera

Opera126 es un lector muy rapido y esta disponible en muchas plataformas127 Opera es un producto comercial sujeto a pago a menos que el usuario acepte anuncios integrados. En este caso, Opera esta disponible en descarga libre.

122 Fuente: http://galeon.sourceforge.net/

123 Fuente: http://www.konqueror.org/

123 Fuente: http://www.mozilla.org/

123 Fuente: http://www.mozilla.org/MPL/

123 Fuente: http://www.opera.com/

123 Fuente: http://www.opera.com/download/index.dml?custom=yesDESCRIPCIÓN TECNICA DE LAS VIAS DE MIGRACIÓN

Todos los lectores mencionados anteriormente cumplen las especificaciones HTML 4 y tienen ventajas y desventajas especificas, por ejemplo, respecto a el soporte de Java y XML. Como se mencionó anteriormente, Beonex es considerado como uno de los lectores más seguros, mientras que Galeon y Opera son lectores muy rapidos. La tabla de abajo (Tabla 37) resume de nuevo los lectores.

Tabla 37: resumen de lectores Web OSS

Lector	Version128	Cliente de correo POP3/IMAP	Cliente de noticias	Cumple HTML 4
Galeon	1.2.10			x
Beonex	0.8.2	x/x	x	x
Konqueror	3.3.1129			x
Mozilla	1.3	x/x	x	x
Netscape	7.0	x/x	x	x
Opera	7.1	x/x		x

Clientes de Correo

Numerosos clientes de correo (incluyendo los que estan integrados en los lectores) estan disponibles para un escritorio de Linux. A continuación presentamos dos de ellos: K-Mail y Sylpheed.

Kmail (con Ägypten)

Kmail130 es el cliente de correo de KDE, que sin embargo, puede ser utilizado en cualquier otro entorno Linux. Por tanto Kmail también es software libre. Kmail ofrece a las agencias publicas una ventaja significativa en comparación de otros clientes de correo bajo Linux:

Un añadido que cumple con SPHINX esta disponible para la encriptación y firma de correos electronicos con Kmail. Este añadido fue desarrollado por la Oficina Federal Alemana para la Seguridad de la Información (BSI) dentro del proyecto Open Source “Ägypten” y aún esta sujeto a más desarrollo. El cumplimiento con SPHINX asegura, por ejemplo, la interoperabilidad entre diferentes soluciones que cumplan SPHINX basadas en el protocolo “TeleTrust e.V. MailTrusT Version2”. Esto significa que los usuarios de las agencias publicas pueden utilizar “Ägypten” para intercambiar correos S/MIME encriptados y firmados con usuarios de otras organizaciones, no importando si estos usan, por ejemplo, Outlook con al añadido Secude que cumple SPHINX, o bien LotusNotes con el añadido MailProtect.

128 En el momento de escribir esta guia.

129 KDE version.

130 http://kmail.kde.org/

131 Fuente: http://www.gnupg.org/aegypten/

KDE se presenta con su propio paquete de ofimática “Koffice”. Otras aplicaciones de escritorio para KDE son:

El gestor de ficheros y navegador “Konqueror” (ver apartados 3.15.6.3 y 3.15.6.4)

El cliente de correo “Kmail” (ver apartado 3.15.6.5)

El conjunto de programas “Kroupware” desarrollado para la Oficina Federal Alemana para la Seguridad de la Información (BSI) (ver apartado 3.14.4.2)

El reproductor de medios “Noatun”

Otras características adicionales son también algunas herramientas de administración y el entorno de desarrollo integrado. La documentación completa se encuentra en http://docs.kde.org

Así y todo, todas las aplicaciones “no-KDE” pueden ser accesibles vía KDE.

GNOME

GNOME es parte del proyecto de código abierto GNU. GNOME son las siglas de “GNU Network Object Modell Environment” o “Modelo GNU de Objetos de Red”. En términos de presentación, GNOME es tan flexible como KDE (ver figuras 42 y 43). GNOME también incluye su propio paquete ofimático y un entorno de desarrollo. Algunas de sus aplicaciones comunes son:

Los gestores de ficheros y navegadores “GNOME Commander” y Nautilus” (ver apartado 3.15.6.3)

El cliente de correo “Balsa”

El navegador “galeon” (ver apartado 3.15.6.4)

El compresor de archivos “GnomeZip”

Una extensa y completa lista de las aplicaciones GNOME disponibles se encuentra en http://www.gnome.org/softwaremap/

Figura 42. Escritorio GNOME – Ejemplo 1

Figura 43. Escritorio GNOME – Ejemplo 2 Gestores de ficheros

Konqueror

Nautilus

GNOME Midnightcommander

Navegadores Web

Linux ofrece a los usuarios un abanico de diferentes navegadores que pueden seleccionarse según se desee o se requiera. Los navegadores web más importantes son:

Galeon

Galeon es un navegador web de GNOME basado en el motor de presentación “Gecko” de Mozilla. Galeon es muy sencillo y presenta una funcionalidad limitada. Aún así es rápido y compatible con todos los estándars.

Beonex Communicator

Beonex Communicator es un navegador de código abierto sujeto a la licencia GPL. Está disponible para todas las distribuciones linux y también para otras plataformas. Beonex Communicator es considerado como uno de los navegadores más seguros.

Konqueror

Konqueror puede ser utilizado no sólo como gestor de archivos (ver más arriba), sino también como un navegador web con KDE. De modo similar a como ocurre con el Explorador de Windows y el escritorio de Windows, Konqueror está totalmente integrado con el escritorio KDE. Konqueror también está sujeto a la licencia GPL.

Mozilla

Mozilla es un navegador de código abierto; su código fuente está disponible bajo cuatro licencias, i.e. MPL (“Mozilla Public License”), NPL (“Netscape Public License”), LPGL y GPL y bajo la denominada “tri-licencia”, i.e. MPL, LGPL, GPL.

Netscape

Netscape versión 7.x se basa en el navegador Mozilla e incluye algunas funciones adicionales.

Opera

Opera es un navegador muy rápido y está disponible para un gran número de plataformas . Opera es un producto comercial, sujeto al pago de una licencia, salvo que

_______________________________________________________

DESCRIPCIÓN TECNICA DE LOS CAMINOS DE MIGRACIÓN

La estación de trabajo WMware es, por tanto, perfectamente apropiada para la utilización de aplicaciones específicas, así como de Office y aplicaciones de Internet. Sin embargo el principal campo de aplicación es hoy el desarrollo de software porque los desarrolladores pueden probar el desarrollo de aplicaciones multi-plataforma en la misma máquina en paralelo con distintos sistemas operativos.

Restricción

La emulación completa de un ordenador todavía necesita elevados requerimientos de hardware de la máquina utilizada para esta emulación. Muchos programas son, por consiguiente, sensiblemente más lentos bajo VMware que en comparación con un ordenador real.

Profundidad de la Integración

VMware representa el escritorio Windows en una ventana separada en el ordenador con Linux utilizado para la emulación. Las aplicaciones relevantes de Windows se pueden activar por tanto desde dentro de esta ventana. El intercambio de datos entre Linux y Windows tiene lugar por medio de una red emulada. Esto requiere tener instalado Samba durante la instalación de Vmware con el fin de posibilitar el acceso al directorio personal (home) del ordenador con Linux.

CUADRO:

Figura 44: Escritorio Windows bajo Linux utilizando VMware133

_____________________________

133Fuente: VMware http://www.vmware.com/products/desdtop/ws_screens.html

___________________________________________________________________________________

Versión: 29.08.2003	Página 243______________________________________________________

DESCRIPCIÓN TECNICA DE LOS CAMINOS DE MIGRACIÓN

En suma, sin embargo, la integración en la estación de trabajo Linux es tan solo rudimentaria. Además, la presentación de la aplicación Windows por medio del escitorio Windows se debe clasificar como no muy ergonómica.

Costes

Vmware es un producto comercial sujeto a un precio134. Además, los precios por las licencias de Windows se pagan como una condición previa al uso de las aplicaciones Windows. Los requerimientos adicionales de Vmware también significan un incremento en los costes en hardware.

Hacer disponibles a las aplicaciones Windows con Vmware para Linux es, por lo tanto, un ejercicio relativamente costoso.

Evaluación

La fuerza real de Vmware es probablemente, y como ya se ha mencionado, en que constituye una buena plataforma de desarrollo para aplicaciones multi-plataforma, mucho más que en hacer disponibles aplicaciones Windows para Linux. Por estas razones, Vmware se debe de utilizar solamente en casos excepcionales.

Servidor GSX 2.5

El servidor Vmware GSX está basado en la misma tecnología que la estación de trabajo Vmware. El servidor GSX habilita que se puedan ejecutar máquinas virtuales como procesos background, siendo controlados remotamente por ordenadores Windows o Linux, y administrados remotamente por medio de un interfaz web y un API especial basado en “scripts”. Esto hace posible también la ejecución simultánea de múltiples sistemas operativos servidores en hardware Intel y la consolidación de esta forma de las arquitecturas de servidor.

Lo dicho en combinación con la variante de la estación de trabajo, también hay que aplicarlo respecto a los “sistemas operativos soportados”, “programas ejecutables”, “restricciones”, “profundidad de integración”, “costes” y “evaluación”135.

Win4Lin

Win4Lin 4.0 – Edición de estación de trabajo

Win4Lin136 posibilita la ejecución en Linux de las versiones Windows basadas en DOS, como son las versiones 95, 98 y Me. En este caso, Win4Lin, al igual que Vmware, no emula un PC sino que proporciona los servicios de sistema necesarios para Windows por medio de un numero de módulos del kernel. Durante la instalación, los archivos del sistema operativo Windows son modificados de tal forma que el sistema operativo Windows se abastece de los correspondientes servicios de los módulos del kernel en vez de ejecutar estos servicios por si mismo. Esto significa que las aplicaciones con Win4Lin van normalmente mucho más rápidas que con Vmware.

Win4Lin , al igual que Vmware, representa el escritorio Windows en una ventana aparte. Una vez se da comienzo al programa, este abre entonces una ventana en la que se inicia Windows.

____________________________

134Para más detalles, ver http://www.vmware.com/vmwarestore/pricing.html

135Los precios para la licencia de servidor se pueden encontar en

http://www.vmware.com/vmwarestore/pricing.html

136Fabricante: Netraverse http://www.trelos.com/

___________________________________________________________________________________

Página 244	Versión: 29.08.2003

DESCRIPCION TECNICA DE LAS RUTAS DE MIGRACION

iniciado. El usuario puede ahora iniciar y usar las aplicaciones Windows (consultar la Figura 45).

Win4Lin no impone ningún requerimiento de harware especial. El software corre en cualquier PC normal 137.

Sistemas operativos soportados

Win4Lin puede correr en cualquier las distribuciones comunes de Linux que utilicen un núcleo de la familia de versiones 2.4.x.

Como ya fue mencionado, Win4Lin posibilita el uso de las siguientes versiones de Windows en Linux 138:

95

98

ME

Programas ejecutables

Win4Lin 4.0 típicamente posibilita el uso de aplicaciones de Ofimática, Internet y orientadas a base de datos en una estación de trabajo Linux.

Restricciones

Existen restricciones relativas a los siguientes aspectos:

Versiones de Windows soportadas

Uno debe esperar que pronto ésa ejecución de muchas aplicaciones nuevas no será más posible.

Parcheo de módulos Windows

La carga de parches Windows de Microsoft debe ser manejada con cuidado ya que no puede ser determinado que archivos modificados por Win4Lin son intercambiados, así que el sistema entra en un estado inconsistente.

Memoria disponible

Desde la versión 4.0, una capacidad máxima de 128MB de RAM puede ponerse a disposición de las aplicaciones Windows corriendo bajo Win4Lin. La memoria virtual sólo es limitada por la capacidad de memoria disponible

en la partición de disco que contiene el directorio “$HOME/win” del usuario.

Soporte de interfaz

Las interfaces DirectX y USB no son soportadas.

Alcance de la integración

137 Requerimientos de hardware según el fabricante:

http://www.netraverse.com/products/win4lin40/requirements.php

138 Por detalles, por favor consulte

http://www.netraverse.com/support/docs/400_relnotes.html#install_winver

Versión: 29.08.2003 Página 245

DESCRIPCION TECNICA DE LAS RUTAS DE MIGRACION

Win4Lin presenta, de la misma forma que VMware, el escritorio Windows en una ventana separada en la cual las aplicaciones Windows pueden ser ejecutadas.

Figura 45: Escritorio Windows en Linux usando Win4Lin 139

Sin embargo, el intercambio de datos entre aplicaciones Linux y Windows es más simple que en el caso de Vmware. Win4Lin posibilita que los directorios Linux sean presentados simplemente como unidades bajo Windows.

Sin embargo, las aplicaciones individuales no están realmente integradas en éste caso. Después que el programa inició, abre una ventana en la cual el usuario puede observar a Windows iniciando antes de que el usuario pueda entonces comenzar y usar aplicaciones en ésa ventana.

Costos

Win4Lin también es un producto sujeto a un pago. Sin embargo, los pagos por licencias 140 son substancialmente menores que por Vmware. Sin embargo, de la misma forma que en el caso de Vmware, las licencias Microsoft deben ser además adquiridas, sin embargo, a un costo razonable por los sistemas operativos involucrados. Esto significa que las aplicaciones Windows bajo Linux pueden correr bajo Win4Lin con un costo significativamente más bajo que con Vmware.

139 Fuente: Netraverse http://www.netraverse.com/products/win4lin40/fullsizescreen shot.jpg

140 Pagos de Licencia para Win4Lin 4.0 Workstation Edition;

http://www.digitalriver.com/dr/v2/ec_Main.Entry?SP=10007&SID=40113&CID=0&CUR=8 40&DS P=0&PGRP=0&CACHE_ID=0

Página 246 Versión: 28.09.2003

DESCRIPCION TECNICA DE LAS RUTAS DE MIGRACION

Evaluación

A pesar de cierta restricciones técnicas, Win4Lin es hoy a menudo una forma posible de usar aplicaciones Windows individuales y simples bajo Linux. Esto es en particular el caso si tal aplicación es requerida sólo en unas pocas estaciones de trabajo. Si tal aplicación es requerida en un número más grande de estaciones de trabajo, la utilización del Servidor de Terminales Win4Lin -el cual es descripto brevemente abajo- puede ser un enfoque posible.

Servidor de Terminales Win4Lin 2.0

Con el Servidor de Terminales Win4Lin, Netraverse utiliza la capacidad de red del protocolo X para utilizar Win4Lin desde dentro de otro sistema. Esto es posible porque ése protocolo posibilita que la ventana Win4Lin sea mostrada en el escritorio Linux.

Con el Servidor de Terminales Win4Lin, una sesión de programa separada es ejecutada luego en un servidor Linux por cada usuario de Win4Lin. Esas sesiones son entonces transferidas usando el protocolo X a los clientes.

La principal ventaja de ésto es que posibilita la instalación y administración centralizada tanto de Win4Lin y el sistema operativo Windows como así también de las aplicaciones requeridas.

WINE

WINE es un proyecto de software libre 141 el cual ha estado persistentemente

buscando y mejorando la integración Windows/Linux a nivel de aplicación. WINE utiliza un principio fundamentalmente diferente de las otras soluciones descriptas hasta ahora para hacer que las aplicaciones Windows estén disponibles bajo Linux.

WINE pone a disposición una implementación libre del API de Windows para su uso bajo Linux y X-Windows. Cuando una aplicación Windows es iniciada, WINE, de la misma forma que el mismo Windows, carga ésa aplicación en la RAM de la computadora, la enlaza a las bibliotecas que WINE pone a disposición, y es de ése modo capaz de hacer que las aplicaciones funcionen bajo Linux. Esto significa que, estrictamente hablando, WINE no es un emulador de Windows.

El mayor desafío involucra ahora hacer que estén disponibles las bibliotecas Windows existentes como implementaciones libres con el mayor alcance posible, de forma que tantas aplicaciones Windows como sea posible puedan correr bajo Linux. WINE implementa ya las bibliotecas Windows con las funciones más importantes, así que no surgen problemas cuando una aplicación Windows sólo accede a la funcionalidad estándar (del sistema operativo Windows) y ya incluye todas las demás funciones en si misma. La situación es más difícil si una aplicación Windows accede a principalmente funciones nuevas de bibliotecas Windows, las cuales no han sido implementadas aún, o a bibliotecas de otras aplicaciones. Debería también mencionarse en éste contexto que los creadores de aplicaciones usualmente intentan soportar incluso versiones antiguas de windows. Con el fin de

141 Página web del proyecto WINE: http://www.winehq.com/

Versión: 29.08.2003 Página 247

DESCRIPCION TECNICA DE LAS RUTAS DE MIGRACION

lograr ésto, ellos utilizan funcionalidades nuevas con muy poca frecuencia y sólo en forma opcional, así que ésto no necesariamente conduce a problemas prácticos.

WINE ya soporta una gran cantidad de aplicaciones (consulte la siguiente sección sobre “Sistemas operativos soportados”) y funcionalidades 142

Sistemas operativos soportados

WINE está disponible en prácticamente todo sistema Linux, y forma parte de la mayoría de las distribuciones.

Programas ejecutables

WINE posibilita la ejecución de prácticament todas las aplicaciones Windows con la condición de que las bibliotecas requeridas estén disponibles.

Programas para los cuales ésto es cierto incluyen, por ejemplo, WinWord, Excel y Powerpoint de los paquetes Office 97 y 2000 así como el Internet Explorer. En casos individuales, la aplicabilidad práctica debe ser verificada por adelantado. Para éste propósito, la base de datos de aplicaciones WINE(http://appdb.winehq.com/ ) debería ser examinada primero.

Restricciones

Un problema con WINE es la todavía muy compleja configuración del programa que requiere mucha experiencia.

Alcance de la integración

WINE permite una integración óptima de aplicaciones Windows en el escritorio Linux. Los programas son iniciados directamente por el manejador de ventanas del escritorio Linux en una ventana X separada en lugar de ser iniciada desde un escritorio aparte.

142 Una lista está disponible en http://www.winehq.com/?page=wine_features;winehq=d35c3404fe39283bf96bb1dd54b14c8d.

Página 248 Versión: 29.08.2003

DESCRIPCION TECNICA DE LAS RUTAS DE MIGRACION

Figura 46: Aplicaciones Windows en el escritorio Linux usando WINE 143

Costos

No se incurre en otros costos que no sean pagos de licencias para las respectivas aplicaciones Windows. Sin embargo, el esfuerzo de administración excede el necesario para otras soluciones.

Evaluación

Este enfoque ofrece dos ventajas importantes:

No existen costos por licencias del sistema operativo Windows.

No es necesario un sistema operativo adicional el cual aumentaria la carga de trabajo de los recursos disponibles. Las aplicaciones Windows pueden teóricamente ser ejecutadas con la misma velocidad que bajo Windows y requieren los mismo recursos de memoria.

Si las bibliotecas requeridas están disponibles para una aplicación en WINE, el uso de WINE debería ser claramente preferido.

WINE podría ser una forma de posibilitar la ejecución de MS Project en los escritorios Linux porque una aplicación Linux alternativa no está disponible actualmente. Sin embargo, ninguna entrada positiva puede encontrarse hasta ahora en la base de datos de aplicaciones.

143 Fuente: http://www.winehq.com/?ss=1

Versión: 29.08.2003 Página 249

DESCRIPCION TECNICA DE LAS RUTAS DE MIGRACION

Crossover 0ffice

Crossover Office (CO) es un producto de Code Weavers144. CO está basado en WINE y compensa la desventaja de la compleja configuración de WINE en que CO acompaña a WINE con un programa de instalación amigable con el usuario así como con scripts para crear usuarios e instalar aplicaciones Windows.

Programas ejecutables

Crossover Office actualmente soporta Microsoft Word, Excel y PowerPoint (de Office 97 y 2000). Otras aplicaciones, como Outlook 2000, IE 5.5 y Notes R5, son ejecutadas en forma relativamente estable.

Costos

Además de los pagos de licencias de MS Office, también hay que pagar licencias para Crossover Office145.

Evaluación

Lo que fue dicho sobre WINE aplica aquí también. Los usuarios que buscan un procedimiento de instalación y configuración amigable con el usuario deberían elegir CO WINE.

Crossover Office Server Edition

El Crossover Office Server Edition posibilita la instalación centralizada de aplicaciones Windows en un servidor de aplicaciones basado en Linux desde donde ellas son puesta a disposición de sistemas clientes a través del protocolo X. Esto ofrece la ventaja de que es posible la provisión y administración centralizada de las aplicaciones Windows.

WineX

WineX es otra variante de WINE en la cual la compañía Transgaming146 se ha concentrado en mejorar el soporte de DirectX. WineX posibilita que algunos sofisticados juegos para Windows sean jugados bajo Linux. Esta es también la razón por la cual WineX no es discutido con más detalle. Es mencionado sólo por completitud. WineX no es software libre.

3.15.7.3 Citrix Metaframe

Las funcionalidades son descriptas en el capitulo 3.16.5

Sistemas Operativos soportados (Consulte el capítulo 3.16.5)

Programas ejecutables

Cualquier aplicación Windows que pueda ser ejecutada en Windows NT o Windows 2000 puede ser ejecutada.

144 Página web de Code Weavers http://www.codeweavers.com/home/

145 Información de precios de Crossover Office http://secure.codeweavers.com/store/

146 Página web de Transgaming http://www.transgaming.com/

Página 250 Versión: 29.08.2003

DESCRIPCION TECNICA DE LAS RUTAS DE MIGRACION

Restricciones

La única restricción concerniente a la ejecución de aplicaciones Windows es que las aplicaciones con un componente gráfico substancial (ver arriba) no deberían ser ejecutadas con Citrix Metaframe.

Alcance de integración

Así como Vmware y Win4Lin, el escritorio Windows puede ser abierto en una ventana separada en el escritorio Linux, siendo las aplicaciones Windows ejecutadas en ésa ventana. Los datos puede ser intercambiados sólo a través de la red. El alcance de integración es por lo tanto muy limitado en éste caso.

Costos

Los costos dependen de la funcionalidad específica del metaframe deseado y deben ser analizados caso a caso. En general, sin embargo, deben pagarse licencias completas Microsoft además de las licencias Citrix.

Evaluación

Citrix Metaframe no puede ser recomendado como una solución temporal para la ejecución de aplicaciones Windows en un escritorio hasta que tales aplicaciones estén disponibles bajo Linux porque Citrix Metaframe es, lo que es más importante, demasiado caro y demasiado complejo.

Citrix Metaframe debería, sin embargo, ser considerado si es previsible que ciertas aplicaciones Windows deban permanecer en uso por tiempo futuro prolongado.

La mayor ventaja de Citrix Metaframe es la instalación y administración centralizada de aplicaciones así como el almacenamiento centralizado de datos. Citrix Metaframe es también un sistema adecuado en un ambiente con clientes thin o clientes sin disco.

3.15.7.4 Windows Terminal Server

Las funcionalidades son descriptas en el capítulo 3.16.5.

Sistemas operativos soportados

(Consulte el capítulo 3.16.5)

Programas ejecutables

Todas las aplicaciones Widows que corren bajo Windows 2000 pueden ser ejecutadas.

Restricciones

(Consulte el capítulo 3.16.5)

Alcance de la integración

Consulte los comentarios sobre Citrix Metaframe.

Costos

Comparado on Citrix, no se incurren en otros costos que no sean pagos a Microsoft.

Evaluación

Versión: 29.08.2003 Página 251Esta opción se puede evaluar como bastante similar a la solución de Citrix Metaframe, aunque ésta es ligeramente más favorable. Pero, en comparación con Citrix Metaframe, presenta la desventaja de que la experiencia acumulada con Windows Terminal Server es todavía limitada, especialmente en entornos más complejos y con mayor número de equipos. Este es un problema de menor importancia en la búsqueda de una solución para el problema que estamos tratando.

Resumen

Las soluciones VMWare, Win4Lin, WINE y Crossover Office se deberían considerar únicamente como soluciones temporales, o como soluciones para pequeñas aplicaciones individuales en estaciones de trabajo. A medio plazo, se necesitaría una aplicación equivalente e independiente de plataforma que se pudiese ejecutar en Linux.

Por otra parte, se podría valorar si la solución Citrix Metaframe podría ser viable económicamente, aunque esto sería más bien una solución estratégica.

De acuerdo con estas condiciones, se podrían extraer las siguientes conclusiones:

Para un número limitado de aplicaciones de Windows, merece la pena usar WINE (si fuese necesario, con un esfuerzo añadido de desarrollo).

Si hay muchas aplicaciones Windows implicadas, es poco probable que se puedan ejecutar utilizando WINE. Se debería valorar la posibilidad de usar Win4Lxn (ejecutable bajo Windows 95, 98 o ME).

Si el número de aplicaciones Windows es muy grande, habría que preguntarse si la migración tiene sentido (siendo necesario comprobar caso por caso, dónde está el límite para decidir si es necesario realizar esta migración).

Un requisito básico para el futuro sería que las aplicaciones fuesen independientes de la plataforma.

Evaluación

A partir de los datos expuestos anteriormente, evaluaremos a continuación la opción de reemplazar o sustituir Office 97 y/o Office 2000 por Office XP u Office 2003 o por OOo/SO. Los resultados de esta evaluación serán la base para la evaluación de la posibilidad de reemplazar el “escritorio” basado en productos Microsoft por un “escritorio” basado en Linux.

Reemplazar Office 97/2000.

Migración a Office XP

En estos momentos se debería reconsiderar la migración de Office 97 y/o Office 2000 a Office XP por la siguiente razón:

Toda migración supone siempre un coste de tiempo y de dinero, de modo que la migración debería dirigirse hacia las tecnologías punteras y más avanzadas, en lugar de hacia tecnologías más antiguas que todavía están vigentes. Es previsible que Office XP sea sustituido a finales del 2003 por Office 2003, basado en una tecnología más avanzada e innovadora. Si, como se ha dicho, se lanzase una primera versión completa de Office 2003 en

el verano de 2003, es previsible que a principios de 2004 exista una versión estable y libre de errores.

Migración a Office 2003

El único argumento técnico contra la migración a Office 2003 es que en estos momentos no existen experiencias disponibles sobre su uso.

Teniendo en cuenta la fuerte orientación de Office 2003 hacia XML y los datos de uso basados en la utilización de la versión beta 2, se puede esperar que Office 2003 facilite el intercambio de documentos entre distintas plataformas. Solamente esta razón sería suficiente para posponer la migración del paquete Office hasta que exista una versión estable y sin errores de Office 2003 y se tengan más datos de su uso diario y del intercambio de documentos entre diferentes plataformas.

Migración a OOo/SO

Desde el punto de vista actual, la migración a OOo/SO sólo podría recomendarse si una organización u organismo público:

nunca o rara vez comparte documentos con otros organismos públicos o con otras organizaciones que usan MS Office (hasta XP) o

comparte solamente documentos simples, por ejemplo documentos sin macros y sin formatos especiales con otros organismos públicos u organizaciones que usan MS Office (hasta XP).

Si se tienen que crear documentos complejos junto con otros organismos públicos y organizaciones que usen Office 97, 2000 o XP, se podría esperar que esta cooperación fuera demasiado compleja y difícil.

Es más, la migración a OOo/SO no se recomienda desde un punto de vista técnico si las aplicaciones externas que están fuertemente integradas con MS Office y son realmente imprescindibles no se pueden integrar con OOo/SO.

En este momento no se puede afirmar nada acerca de este tema debido a que no hay suficiente experiencia en el intercambio de documentos entre MS Office 2003 y OOo/SO, puesto que todavía no están disponibles sus versiones 1.1 y 6.1.

Terminal Servers y clientes ligeros.

Aspectos Generales.

La decisión a favor del uso de terminal servers y clientes ligeros también se puede tomar dentro de proyectos de migración y por lo tanto éste también es uno de los temas tratados en esta guía de migración. Sin embargo, este no es un tema típico de migración, puesto que el entorno de los terminal servers normalmente no se migra. El uso de los sistemas discutidos a continuación en principio tiene que ver con una decisión estratégica general tomada dentro de los departamentos de IT de las organizaciones públicas. Sin embargo, las soluciones presentadas tienen el propósito de ofrecer una idea general y de mostrar el potencial tecnológico.

Las tecnologías discutidas se pueden usar en diferentes áreas:

Servidores basados en Linux y sistemas clientes con el “Linux Terminal Server Proyect”.

NX Terminalservices con sistemas basados en Linux y sistemas cliente para Windows y Linux.

Windows Terminal Server con sistemas clientes principalmente basados en Windows.

Soluciones Citrix Metaframe con diversos sistemas cliente (DOS, Windows, Unix, Linux, etc.).

Los sistemas analizados cubren un amplio rango de diferentes soluciones técnicas (sistemas clientes y servidores) y se deben analizar con mayor detalle en cada caso. Además de las diferencias técnicas y de las opciones, los sistemas también pueden variar mucho con respecto a los modelos de licencias y costes.

Introducción.

La administración y el soporte a estaciones de trabajo es un trabajo muy costoso, sobre todo cuando los ordenadores tienen instalado diferente hardware y software. Más aún, la creciente complejidad en el hardware y el software utilizados puede aumentar la vulnerabilidad de las estaciones de trabajo frente a los fallos, incrementando las tareas necesarias para su administración. La siguiente lista muestra una visión general de las tareas relacionadas con la administración del sistema.

Instalación, incluida la configuración del sistema si fuese necesario.

Adaptación a los requisitos de los usuarios.

Administración de actualizaciones de software, preparación y actualización de los paquetes de instalación y distribución necesarios.

Diagnóstico de fallos, resolución de problemas y soporte.

Gestión de componentes de repuesto.

Generalmente, estas tareas se pueden automatizar mediante el apoyo de herramientas administrativas y aplicaciones de administración del sistema. Aunque la automatización permite reducir la cantidad de trabajo necesario, sin embargo el esfuerzo necesario sigue siendo bastante elevado. Más aún, no todas las organizaciones poseen el presupuesto necesario para adquirir este software de gestión de sistemas, bastante caro en algunas ocasiones. Esto es especialmente cierto en el caso de organizaciones pequeñas.

La utilización de terminal servers puede reducir estos problemas de forma significativa. Incluso con vistas a futuros proyectos de migración, merece la pena pensar acerca del uso futuro de terminal servers y de los clientes ligeros. En un entorno IT convencional distribuido, normalmente los programas se instalan y ejecutan en estaciones de trabajo personales. Los principales propósitos de una estructura basada en servidor son la gestión central de datos, la copia de seguridad de los datos, así como el control de los permisos de acceso. En el caso de una solución basada en terminal servers, existirán uno o más ordenadores centrales con mayor capacidad de proceso. Estos servidores aseguran el acceso independiente de ubicación a los datos y a las aplicaciones que se necesiten. Los terminal servers ofrecen a los usuarios acceso directo al interfaz gráfico de usuario del sistema operativo a través de la red. En el terminal server, cada usuario validado tiene su propia sesión y acceso a todos los recursos disponibles del sistema operativo.

En el servidor de terminales, cada usuario conectado tiene su sesión propia y acceso a todos los recursos disponibles del sistema operativo. A diferencia de las arquitecturas convencionales de trabajo distribuido, no sólo los datos, sino también las aplicaciones, está disponibles en servidores centrales. El acceso a las aplicaciones y los datos de los servidores de terminales debe realizarse usando programas de terminal especiales y los llamados clientes ligeros.

La tabla de debajo (tabla 38) da una pequeña visión de las ventajas del uso de servidores de terminales y clientes ligeros.

Tabla 38: ventajas de servidores de terminales y clientes ligeros.

Además de estas ventajas, también existen ciertas desventajas que deben ser consideradas a la hora de decidir si usar servidores de terminales o no.

Tabla 39: algunas desventajas de los servidores de terminales y clientes ligeros.

CONTINUACIÓN TABLA 69

Se pueden utilizar diferentes tipos de clientes para comunicarse con servidores de terminal.

Clientes pesados

Un cliente pesado es un ordenador tipo estación de trabajo completo. Se utiliza un software especial cliente/servidor de terminal para acceder al servidor de terminal.

Figura 47

Figura 47: Ejecución de aplicaciones X en un cliente pesado.(página 257)

Pequeños clientes

Los pequeños clientes son sistemas con mínimos recursos de hardware. Los clientes o bien acceden a su sistema operativo desde un flash EPROM o bien son arrancados vía la (pxe, tftp, nfs) (remitirse a la Imagen 49).

Imagen 48: Ejecutando X y aplicaciones Windows en un pequeño cliente.

Imagen 49: Arrancando un sistema Linux desde la red.

Algunos acercamientos escogidos para la implementación de entornos de terminal serán brevemente presentados a continuación.(página 258)

Proyecto de Servidor de Terminal Linux

El Proyecto de Servidor de Terminal Linux (LTSP) usa las excelentes opciones que ofrecen Linux y X-Window, con el objeto de tener sistemas clientes arrancados desde sistemas servidores. Las aplicaciones requeridas son por lo tanto ejecutadas en el sistema servidor. La salida gráfica de las aplicaciones que se ejecutan en el servidor es enviada a los terminales a través del protocolo X. La configuración de los sistemas cliente se implementa a través de simples archivos de texto y activa diversas opciones, desde el uso de impresoras locales mediante la ejecución lo cal de programas. El proyecto LTS permite a ordenadores baratos actuar como terminales usando un servidor Linux u otro servidor UNIX, mientras que los clientes pueden trabajar tanto en modo texto o con un interfaz gráfico.

Los sistemas clientes son arrancados desde el servidor a través de la red. A ello se adaptan con ROMs especiales de arranque, que pueden ser instaladas en la mayoría de los adaptadores modernos. Los datos de usuario y/o cuenta son administrados usando las funciones normales incluídas en GNU/Linux.

A continuación son descritas dos ejemplos basados en el acercamiento LTSP.

El concepto GOto

El concepto GOto fue usado desde el entorno de trabajo del proyecto de migración en el Instituto de Ciencias y Zoocultivos de Mariensee. La empresa GONICUS ha desarrollado el concepto GOto y puesto sus partes integrantes a disposición del público en forma de software libre.

La mayor diferencia, comparado con el acercamiento LTSP, es la gestión simplificada de una base LDAP. Todas las configuraciones y perfiles de usuario son almacenados de forma central en los servidores usando LDAP (Lightweight Directory Access Protocol). Esto asegura que todo usuario en el lugar de trabajo tiene acceso tanto a su perfil específico, como a sus aplicaciones y datos partidulares. La administración puede abstraerse usando el interfaz de web Gosa, que proporciona acceso a las estructuras LDAP exigidas y a su control. Ambas soluciones están distribuidas bajo GPL.

El concepto GOto también permite el arranque total en pequeños sistemas clientes con los servidores respectivos a través de la red. El proceso de arranque se extendió para el protocolo estándar PXE porque las opciones de arranque relacionadas, hoy forman parte de la funcionalidad estándar de muchas tarjetas de red, de modo que en muchos casos ni siqueiera se requiere una ROM de arranque. Son soportados tanto clientes pequeños como grandes. La gestión de los grandes clientes puede abstraerse a un proceso equivalente al que se usa para pequeños clientes. Una vez que son instalados los grandes clientes, pueden ser automáticamente almacenados en el último nivel.Servidor Desktop

El desktop server univention_ es una solución comercial, integrada y escalable de servidor basado en Linux con un módulo para la implementación de clientes ligeros y una versión extendida del servicio de directorio OpenLDAP como backend para la administración de usuarios y la configuración.

Al igual que el conceptop GOto, se diferencia de LTSP en que el soporte para arranque del sistema no es sólo mediante BOOTP, sino también mediante PXE. Es más, hay herramientas disponibles para monitorizar las sesiones de usuario y poder evitar el “process corpses” cuando los clientes son apagados. Adicionalmente, el acceso a dispositivos locales – como CDROM, disquetera, tarjeta de sonido o impresora – que están conectados al cliente ligero, está habilitado (aún cuando este acceso puede ser restringido por los administradores). Todo el sistema de usuarios y configuración está contenido en un directorio LDAP. Adicionalmente, la administración puede adaptarse a la administración de clientes pesados basados en Windows o Linux.

La función de reparto de carga integrada asegura una buena escalabilidad de modo que es posible integrar nuevos servidores de aplicaciones o de arranque en el sistema, cuando sea necesario.

Servicios de terminal NX

El producto NX de la compañía italiana Nomachine representa una tecnología de servidor de temrinales basada en Linux relativamente nueva. NX es un producto comercial. Tras muchos años de desarrollo, los programadores implementaron con éxito un compresor muy eficiente para el protocolo X-windows. Recuérdese que el sistema X-window implementa un diseño independiente de la red. Esto significa que la salida de cualquier aplicación puede ser vista en una pantalla remota. A pesar de ello, el protocolo no está muy optimizado desde el punto de vista del uso del ancho de banda disponible. Esta es la razón por la que el uso del protocolo X-windows sólo tenía sentido en entornos de Red de Área Local. A pesar de los intentos de guardar en caché los eventos y mapas de bits y/o comprimir el protocolo (X banda estrecha), los resultados todavía eran suficientes.

El NX ha alcanzado, mientras tanto, un nivel de compresión que se corresponde aproximadamente con el de Citrix. El servidor NX se ejecuta sobre uno o más servidores Linux y, además del protocolo X, es capaz de transmitir eficientemente los protocolos RDP de Microsoft y “buffer de trama” de los visualizadores VNC al cliente NX. El cliente NX se ejecuta bajo Linux, Windows y también en PDAs del tipo iPAC y Zaurus.

Además de una transmisión eficiente de los contenidos de la pantalla, el sistema NX permite el acceso al sistema de ficheros local y la transmisión de datos de sonido. La redirección del puerto serie todavía no es posible. En términos tecnológicos, el sistema está basado principalmente en componentes de código abierto. Todos los componentes de compresión han sido liberados bajo la GPL. La comunicación es encriptada totalmente mediante un túnel ssh. De modo parecido a Citrix Metaframe, es posible publicar el contenido de ventanas de una aplicación Esto permite una integración muy flexible entre los entornos de aplicaciones de Windows y Linux. Es posible presentar aplicaciones Windows en el escritorio Linux o aplicaciones Linux en el escritorio Windows. La separación entre servidor de aplicaciones y nodos de compresión permite un elevado grado de escalabilidad. El servidor de aplicaciones no se ve sobrecargado por la tarea de compresión de datos. No pueden darse conflictos de versión entre servidores de aplicación y de compresión.

El modelo de licencias es interesante, porque depende del número de servidores de aplicaciones y no del número de clientes. Esto hace a este producto significativamente más barato que a otros productos del mercado.

Servicios de terminal de Windows y Citrix

Toda la lógica de aplicación es suministrada centralmente por los servidores, de manera que se requiere un ancho de banda de entre 10 y 20 kbps entre cliente y servidor. La separación de la lógica de aplicación de la interfaz de usuario en los servidores de terminales implica una carga de trabajo adicional en la espina dorsal comparada con entornos convencionales de tipo cliente/servidor, durante el acceso a servidores de ficheros, impresión, base de datos, etc.

Los servidores en que se intalan las aplicaciones son una pieza clave de esta tecnología de servidores de temrinal. El servidor de terminales permite acceso en paralelo de clientes para muchas sesiones de usuario, durante las cuales los usuarios pueden ejecutar las aplicaciones en un área protegida de memoria. Dado que, en estado “no configurado”, todos los usuarios tienen todos los privilegios, el sistema debe protegerse contra acciones de usuarios no deseadas o no autorizadas. Para este fin, los ya conocidos instrumentos de administración NT – como perfiles, políticas y configuraciones basados en el servidor – pueden asegurar la seguridad requerida para ficheros y directorios.

Adicionalmente, las pruebas de aplicación son particularmente importantes en un entorno de servidor de terminales, para asegurar un dimensionado óptimo del servidor. Por tanto, es esencial conocer

Las prestaciones reueridas del procesador y

la capacidad de memoria requerida por una aplicación.

Cuántos usuarios acceden simultáneamente al programa,

si el programa es una aplicación de 16 bits o DOS

si la aplicación es o no multiusuario.

Los Servidios de Terminal Windows se ofrecen en una variante separada de producto (Terminal Server Edition, TSE). Con Windows 2000 este servicio se incluye en todas las variantes de producto.

A menos que se utilice Metaframe de la marca Citrix, la comunicación entre el servidor de terminal y el cliente de terminal está basada en el protocolo RDP (Remote Desktop Procedure), basado en el protocolo IP. Windows NT 4 TSE soporta la versión 4 de RDP, Windows 2000 soporta la versión extendida RDP 5.

Microsoft ofrece clientes para servidor de terminales (clientes RDP) para todos los sistemas operativos Windows (incluyendo sistemas de 16 bits). Otros suministradores ofrecen clientes RDP adicionales para otros entornos de ejecución (como Java).Una desventaja de las soluciones de servidor de termina basadas únicamente en Microsoft, es que los clientes deben conectarse a un determinado servidor. Esto acarrea problemas si

el servidor no está disponible

el servidor está sobrecargado

El producto Metaframe de Citrix ofrece una solución para esto. Metaframe permite a varios servidores de terminales combinarse de modo lógico para formar una “granja de servidores”. Al usuario (cliente) se le presentan entonces las denominadas “aplicaciones publicadas”, en lugar de un único servidor con el que conectarse. Un mecanismo interno de la granja de servidores determina el servidor en el que se ejecutarán las aplicaciones del usuario.

Llegados a este punto, debe tenerse en cuenta que esta explicación sólo enmarca los principios tecnológicos subyacentes, sin tan sólo arañar la superficie de la complejidad de los conceptos y opciones de Citrix. En cualquier caso, este enmarcado es suficiente en este punto, para ilustrar de manera general la opción de utilizar Citrix Metaframe a la hora de ejecutar aplicaciones Windows en el escritorio Linux.

Para garantizar esta funcionalidad, Metaframe incluye el denominado protocolo ICA (Independent Computer Architecture). Existen clientes ICA para

todos los sistemas operativos Windows

DOS

Java

un gran número de variantes de Unix (incluido Linux)

y sistemas portátiles

En el lado del servidor, principalmente son soportados los anteriormente mencionados sistemas operativos de Microsoft (Windows NT4 STE y Windows 2000). Aún así, también hay variantes de Unix disponibles (como Metaframe para Solaris)

Citrix ofrece actualmente dos variantes de Metaframe, i.e:

Metaframe 1.8

Metaframe XP

La versión XP debe considerarse como variante estratégica, porque la versión 1.8 será descontinuada en un futuro próximo..

Metaframe puede encontrarse en entornos grandes con un elevado número de servidores, porque estos entornos requieren una gestión inteligente de la carga de trabajo (reparto de carga). Si varios servidores de terminales se combinan formando una granja de servidores, puede implementarse una función de reparto de carga para los servidores.

La siguiente ilustración (figura 50) enmarca los principios para una granja de servidores bajo Metaframe XP.Descripción técnica de los pasos de la migración

Figura 50: Granja de servidores con Metaframe XP

El balanceo de carga soporta la disponibilidad de la ejecución y la aplicación en todo el sistema porque ningun usuario está asignado a un servidor no disposible. Una vez que el programa de carga de evaluación es asignado a los servidores, la carga del servidor es devuelto bajo Metraframe XP al Data Collector y guardado alli con el proposito de proporcionar peticiones de conexión. Cuando una aplicación publicada es requerida por un cliente ICA, el Data Collector lo identifica y selecciona el servidor que ofrece el mayor rendimiento a tiempo y se lo notifica al cliente. Entonces, el cliente se conecta con este servidor.

En el caso de que la granja de servidores consista , por ejemplo, en ordenadores de 1 o 2 procesadores, se pueden establecer diferentes reglas de funcionamiento para los diferentes servidores. La carga de aplicación de un usuario estandar para los ordenadores de dos procesadores alcanza, por ejemplo, el 100 % de la carga cuando 50 usuarios estan conectados, mientras que los ordenadores de un procesador alcanza este nivel de carga completa cuando 25 usuarios estan conectados. La funcionalidad de este 'ajuste' hace posible que las diferencias de hardware esten niveladas.

Los siguientes aspectos tecnicos deben ser considerados con respecto a la tecnologia del terminal server.

Las granjas de servidores necesitan un dominio de Windows (logon)

Las granjas de servidores usan ficheros basados en servidor para soportar usuarios invitados ( servicios de ficheros estables).

Windows Terminal Server imprime vía RPC en el servidor de impresión de Windows para reducir la carga del Terminal Server.

Las cuentas de usuario en un dominio de Windows son suplementadas por parametros adicionales de Terminal Sever.

No todas las aplicaciones de Windows pueden ejecutarse sobre Terminal Server (estudio de viabilidad, esfuerzos de integracion, costes).

Alta Disponibilidad

El campo de la aplicación debe de ser caracterizado como una primera condición para determinar si los requisitos de alta disponibilidad pueden ser satisfechos usando software de código abierto.

Pretensiones

Las instalaciones de alta disponibilidad proporcionan servicios de tal manera que su mínima capacidad, su salida de datos, sus tiempos de respuesta y otros parámetros no caigan por debajo de ciertos niveles. Estos requisitos se pueden deber a varias razones

Los servicios se necesitan urgentemente para propósitos internos. Son por ejemplo la base de muchas actividades de muchos usuarios y el daño económico de un fallo sería desastroso.

Los servicios son críticos en seguridad. Un fallo puede afectar a intereses nacionales.

Los servicios deben estar disponibles para los ciudadanos o las compañías sin fallo o con un funcionamiento básico.

Con la iniciativa egobierno el gobierno de la república federal alemana ha abrodado los desafíos para un país moderno y eficiente. Esto supone, por una parte, que los sistemas de backend, como las bases de datos, pueden ser accesibles permanentemente o que nuevas aplicaciones pueden ser recibidas en un funcionamiento básico y cualquier pérdida debe ser prevenida. Sin embargo, por otra parte, los mencionados largos tiempos de servicio también significan nuevos requerimientos para los sistemas frontales. Los cortes deben estar acotados y el tiempo de proceso reducido y la imagen de la administración pública puede ser mejorada de manera significativa mediante iniciativas de este tipo. Servicios de no disponibilidad podrían sin embargo no cubrir estas expectativas.

Los cinco nuevos y la realidad.

Los sistmas de alta disponibilidad (AD) son categorizados mediante otros parámetros, como por ejemplo, el porcentaje del tiempo durante el cual proporcionan servicios. La tabla inferior (tabla 40) ilustra que significa esto para un sistema AD que debe estar disponible durante un tiempo determinado.

Sim embargo estas figuras no son realistas. La mayor parte de grados de satisfacción de servicio (GSS) especifican tiempos de espera definidos durante los cuales el servicio no está disponible.Mientras que este tiempo no es contado hacia atrás. Esto significa que la alta disponibilidad es categorizada como tiempo no planificado.

La especificación para una base de datos SAP por ejemplo, puede estipular que la base de datos esta disponible durante el 99.99% del tiempo durante las horas de oficina desde las 7am hasta las 7pm. Si es posible trabajar fuera de estos tiempos, entonces éstos requisitos pueden ser satisfechos mucho mas fácilmente y a un coste menor que en el caso de una especificación no realista de un máximo tiempo de 5 minutos por año en una operaction 24x365.

La aproximación

La alta disponibilidad es conseguida con recursos redundantes y la monitorización de su funcionalidad. Cuando un componente falla, otro componente que estaba en espera entra automáticamente en funcionamiento. Desde este momento sin embargo, la redundancia se ve afectada o incluso deja de existir, de modo que se debe reparar de inmediato. Los sistemas de AD requieren un gran esfuerzo administrativo y no funcionan solos. El tiempo medio de reparación MTTR más que el triempo medio entre fallos MTBF es una importante medida de calidad para estos casos.

La redundancia se puede conseguir en todos los niveles

Hoy en día la redundancia en discos duros son ya un estandar (el espejo RAID1, el uso de RAID5 ya no es tan justificable hoy en día) y están disponibles para todas las plataformas. La situación es, sin embargo, más difícil en el caso de otros componentes hardware. Las tarjetas de red con configuraciones redundantes no están muy bien soportadas. El soporte de la redundandcia hardware por los sistemas operativos está en el ojo del huracan de estas discusiones. En este campo, los sistemas UNIX propietarios y por supuesto, los superordenadores, ofrecen ventajas significativas que en opinión de los autores es poco probable que se consigan por los sistemas de software abierto en un futuro cercano.

La redundancia al nivel de sistema operativo se consigue monitorizando los recursos y su traslado a otra computadora en caso de fallo (failover)

Ciertos componentes middleware, como las bases de datos y los monitores de transacciones, también permiten tratar a un número elevado de sistemas como si fuera uno solo. Algunas aplicaciones no requieren esta característica, porque son distribuidas sobre múltiples computadores en cualquier caso, de modo que un fallo en una computadora no causa problemas.

Si la alta disponibilidad puede ser proporcionanda en un nivel de abstracción, esto es teóricamente suficiente para todos los niveles de abstracción situados bajo este nivel. En la práctica, la robustez y por tanto la fiabilidad de un sistema de AD son mejorados implementado medidas de redundacia en el mayor número de niveles posibles. -recordad que incluso.un subsistema de AD podría fallar en un momento dado y entonces sería compensado por otro componente redundante.

Y finalmente, la causa de errores más importante no debería ser subestimada: el hombre, en su papel de administrador o programador. Errores de administración o programación son llevados a cabo habitualmente por el propio sistema, consecuentemente los servicios y componentes redundantes son inútiles. Si, por ejemplo, un administrador borra varios GB por error, ningún sistema de mirroring o servicio de redundancia puede ayudar -los datos han sido eliminados de todos los componentes. Este es el motivo por el que unas buenas políticas de copia de seguridad y restauración, incluso de recuperación frente a un desastre total, son elementos esenciales en una solución de AD.

Categorías de sistemas de AD.

El principio subyacente en la alta disponibilidad es siempre la redundancia, pero esta redundancia se puede conseguir de diferentes maneras:

Relevo (Failover):

Esta es la arquitectura “clásica” en un sistema de AD, generalmente de dos a tres máquinas que intentan reiniciar un servicio que ha fallado. Si este intento fracasa, el servicio es transferido a otra máquina y arrancado en ella.

Clustering de aplicaciones (Application clustering):

Unas cuantas aplicaciones ya están preparadas para trabajar en cluster y, en consecuencia, son capaces de trabajar en múltiples máquinas que se presentan como una sola al mundo exterior y pueden afrontar fallos de máquinas individuales de manera transparente. El ejemplo más conocido de esta arquitectura es el de Oracle 9/ con la opción Real Application Cluster (RAC).

Granjas de servidores:

Esta aproximación se ha hecho popular especialmente para servidores web. Un “balance de carga” distribuye las peticiones entrantes entre un conjunto de máquinas. Este método es particularmente apropiado para servicios que no tienen estado. Es normalmente utilizado para implementaciones de interficie mientras la parte en segundo plano funciona con un sistema de relevo.

Otro mecanismo usado frecuentemente para bases de datos es el de mantener unos registros para poder rehacer operaciones (redo logs) en caso de recuperación de un desastre. Con este método, se generan redo logs para todas las transacciones y se envían a la computadora de reserva donde son procesados consiguiendo el mismo estado de la base de datos en dicha máquina.

Esta caracterización ayuda a identificar las soluciones de alta disponibilidad ya existentes y a determinar donde tiene sentido el uso de productos Open Source

Figure 51: Soluciones de AD

La insuficiente implementación de los clusters que trabajan con pocas máquinas de forma completamente redundante, se debe principalmente al hardware especial utilizado, para el cual el sistema operativo ofrece soporte frecuentemente insuficiente.

El software de código abierto puede ser utilizado perfectamente en granjas de servidores, idealmente en conjunción junto a sistemas sin estados de sesión. Las aplicaciones más usuales son servidores web, pasarelas para correo-e y servidores de impresión o de ficheros.

Sólo hay unas pocas aplicaciones de código abierto que puedan funcionar como servidor de aplicaciones. En esos casos pueden ser utilizados si los requerimientos de SLA no son muy altos (como es el caso en el 99,9% del horario de oficina,etc.). Aunque en ese caso se suele utilizar una arquitectura de Relevo para alcanzar la alta disponibilidad. También existen soluciones para cluster a nivel de middleware (mediante Jboss, por ejemplo)

No existe bases de datos de alta disponibilidad de código abierto. Es posible de todas formas planear el uso de software propietario (como Oracle RAC) en este apartado bajo Linux, haciendo posible un ahorro sustancial en hardware en ciertos casos.

Software de alta disponibilidad propietario

El software de alta disponibilidad es un dominio propio del mundo de los mainframes UNIX. Windows DataCenter no es considerado suficiente para aplicaciones críticas.

A nivel de sistema operativo, cada uno de los grandes fabricantes de UNIX ofrece una solución de alta disponibilidad basada en la tecnología de relevo. Después de la fusión de Compaq, HP ofrece hasta dos soluciones; sólo la superviviente será discutida aquí.Tabla 42: Repaso

	IBM	HP	Sun
Operating system / HA package	AIX HACMP	HP-UX MC/Serviceguard	Solaris Sun Cluster
File system	JFS2	HFS	UFS with Sun VM
Cluster-wide file system	Yes	No	Yes
Maximum number of machines	32	16	8
Support of multiple application instances	Yes	Yes	Yes
Partitioning	Yes	Yes	Yes
Failover of existing TCP connections	No	Yes	Yes
Storage technology	Ultra3 SCSI Fiberchannel	Ultra3 SCSI Fiberchannel	Ultra3 SCSI Fiberchannel
Disaster recovery options	HAGEO GeoRM	CampusCluster Metrocluster Continental cluster Continuous Access XP	Storage Data Network replicator
Management	GUI integrated in SMIT	Separate GUI	GUI integrated in SUNMC

Como ya se ha mencionado antes, Oracle RAC es una opción importante en el área de bases de datos cuando el objetivo es alcanzar una alta disponibilidad incluso a nivel de middleware. Esta solución se encuentra disponible para los sistemas UNIX propietarios, Linux y Windows Server.

Software de AD de código abierto

El mundo de las herramientas de código abierto experimenta un desarrollo extraordinariamente rápido. La siguiente sección proporciona un repaso del software de AD que ya se está usando ampliamente y se ha probado y comprobado con muchas aplicaciones existentes. En relación con un proyecto de AD en concreto este resumen sólo puede ofrecer un indicador de uso potencial. La arquitectura específica de cada proyecto en particular debe ser estudiada y la idoneidad de las herramientas debe ser determinada caso por caso. Los autores de este estudio recomiendan efusivamente que se incorporen expertos con experiencia en los proyectos respectivos.

Muchas de las herramientas que se mencionarán a continuación son, por supuesto, también ofrecidas por compañías. En Alemania, casi todas las herramientas están disponibles a través de SuSE. El soporte y la asistencia técnica durante el proyecto son ofrecidos por muchas compañías, incluyendo EDS, por ejemplo.

Subsistemas de disco.

Desde la versión del Kernel Linux 2.4, la cual se usa en la mayoría de distribuciones, Linux ha soportado mirroring de discos usando el módulo del kernel Multi-Disk (md).Este subsistema también soporta acceso multi-path, esto es, la conexión simultanea de subsistemas de disco a diferentes computadoras. Esta característica es requerida para discos de datos o aplicaciones en una arquitectura de relevo. Los sistemas de disco deben estar conectados exactamente a una computadora.

LVM es un gestor de volumenes factible. ext3 se está convirtirndo en el estándar en cuanto a sistemas de fichero con journaling (ver también capítulo 3.2.3).

Relevo vía heartbeat

Una arquitectura de releco utilizando heartbeat puede ser implementada para sistemas Linux. heartbeat soporta la definición de grupos de recursos (servicios, sistemas de ficheros y direcciones IP) los cuales pueden ser iniciados en otro servidor después de un fallo. El estado de las aplicaciones en sesiones que estaban abiertas no se recupera en este caso.

Aunque Linux no soporta la configuración multi-path de tarjetas de red, la disponibilidad del servicio puede ser consultada a través de diferentes canales de comunicación (serie o red).

El arranque completamente automático del dispositivo es normalmente requerido en caso de fallo. La solución “watchdog” (perro guardián, N.T.) es la más ampliamente documentada, tiene tendencia a los errores y es la que lleva a un mayor número de reinicios innecesarios. Un nuevo módulo llamado “hangcheck-timer” parece ser superior en muchas situaciones. La elección del módulo en concreto debería dejarse en manos de los consultores que estén llevando a cabo la planificación de la arquitectura de AD para la aplicación dada.

Cada proyecto de AD debería ser consciente de las restricciones de la solución de código abierto para el relevo: No hay un sistema de ficheros a nivel de cluster; el máximo número de máquinas en un cluster con relevo no debería exceder de tres; el particionamiento lógico de las máquinas ya existentes (asignación de recursos hardware como la CPU y el espacio de disco a los grupos de recursos) no está soportado, y tampoco existen opciones de recuperación cuando hay un desastre.

Heartbeat es un módulo ampliamente utilizado; de acuerdo con el proyecto Linux HA, varios miles de instalaciones lo utilizan productivamente en el mundo. Se trata del elemento clave de las soluciones de AD ofrecidas por los proveedores de Linux líderes (SuSE, Conectiva, Mandrake). Un usuario muy conocido en Alemania es Bayerischer Rundfunk los cuales usaron heartbeat para implementar el sitio web de los 2002 Juegos olímpicos para la German Association of TV and Radio Stations (ARD), todo ello bajo Linux.

Dentro del alcance de un proyecto de migración basado en heartbeat 151, una solución de alta disponibilidad fiable fue implementada con éxito para la oficina de la Federal Data protection Commissioner. La ilustración siguiente (Figura 52) ofrece un resumen de dicha arquitectura.

151 http://linux-ha.org/heartbeat/

Figura 52: Solución con heartbeat y DRDB

La combinación de programas usada, consistente en hearbeat y DRBD 152 (Distributed Replicated Block Device), implementa una solución de alta disponibilidad para los servicios de fichero, correo-e e impresión, para el servidor web, los servicios de dominio (DNS, DHCP) y el servicio de directorio. Los nodos del servidor son monitorizados por heartbeat. Con este propósito las máquinas son conectadas usando un cable ethernet cruzado y un cable serie null módem. Si el servidor activo ya no pudiese ser alcanzado por ninguna de las dos vías de comunicación, el servidor de relevo arrebata la dirección IP virtual automáticamente y se hace con el control de los correspondientes servicios. Además de la alta disponibilidad, el programa de DRBD implementa el mirroring de particiones y volúmenes lógicos mediante Raid-1. Esto significa que cualquier dato que hubiese sido escrito está disponible para el segundo sistema en el mismo instante en el que el servidor activo falla. DRBD puede constituir una alternativa más económica frente a sistemas de SAN externas en ciertas situaciones.

Granjas de servidores

El Linux Virtual Server (LVS) proporciona la infraestructura para una granja de servidores. Un equilibrador de carga bajo Linux distribuye las peticiones entrantes entre el conjunto de sistemas reales. Estos sistemas reales están escondidos a ojos del usuario final quien tiene la sensación de estar en un único y gran servidor. Las aplicaciones típicas incluyen, por ejemplo, web, correo-e o servidores de medios.

El servidor virtual Linux (LVS) se combina a menudo con una arquitectura de relevo para el equilibrador de carga. El proyecto UltraMonkey o el proyecto de código abierto Piranha de Red Hat se encargan de combinar esas dos tecnologías.

LVS se utiliza productivamente en muchas compañías. Sitios web muy grandes como linux.com y sourceforge.net, usan LVS para asegurar la alta disponibilidad de sus sitios web. Real Networks utiliza LVS para un cluster de servidores de medios.

Clustering de aplicaciones

Los servidores de aplicaciones líderes en el software de código abierto ofrecen clustering de aplicaciones.

Tomcat es el servidor de aplicaciones de bajo nivel usado para implementar servlets de Java y Java server pages (JSP). Su balance de carga soporta clustering. Tomcat está tan extendido como Apache.

152 http://www.complang.tuwien.ac.at/reisner/drbd/

Descripción técnica de las vías de migración

JBoss es una de las estrellas del mundo del Código Abierto, un servidor de aplicaciones a gran escala que implementa los estándares J2EE. Sólo en el 2002, se registraron mas de 2 millones de descargas desde el sitio de referencia, con abundantes implementaciones en producción. Dentro de su funcionalidad se incluye la ejecución de aplicaciones en clusters.

Las bases de datos de Código Abierto no proporcionan ninguna solución de alta disponibilidad. Uno de los mayores problemas en la mayoría de casos es la no disponibilidad de funciones de salvaguarda en vivo. Sin embargo, Oracle ofrece su opción RAC para sistemas Linux, lo cual permite ahorros sustanciales en las áreas de servicio y de maquinaria.

3.17.6.5 Clusters de computación

Por completitud, las soluciones de AD en computación de alto rendimiento deben ser también mencionadas aquí incluso si esta aplicación es ciertamente de interés limitado para las administraciones públicas. Beowulf fue la primera implementación de un cluster bajo Linux y es todavía la solución de uso más frecuente. La planificación de tareas en un cluster se garantiza por el sistema portátil de proceso por lotes o por el planificador MAUI.EVALUACIÓN DE LA EFICACIA ECONÓMICA

4 Evaluación de la eficacia económica

4.1 Introducción

Tal y como se muestra en la discusión sobre estudios disponibles hoy en día sobre el tema del COP153 junto con el uso de PCA y productos PLC154, la evaluación de la eficiencia económica de los proyectos de SI es, en general, una difícil tarea la cual es casi imposible de resolver a la luz de los habitualmente modelos multidimensionales de eficiencia económica.

Un análisis de amplio espectro y sobre múltiples facetas – el cual es el caso a la hora de comparar los costes de Microsoft y las plataformas PCA/PLC – debe asegurar la comparabilidad entre los asuntos analizados y la extensión apropiada del análisis como requerimientos primordiales. Una discusión demasiado estrecha de aspectos aislados puede conllevar que el resultado no sea aplicable a la escena global. Esto, por ejemplo, se hace aparente en el estudio de IDC "Windows 2000 vs. Linux für Unternehmensanwendungen" [Windows 2000 vs. Linux para Aplicaciones Empresariales] el cual fue encargado por Microsoft. Como el estudio de restringe a si mismo al coste de los servidores para funciones de infraestructura donde la relación entre los costes de las licencias y el coste total difiere del de las aplicaciones cliente, por ejemplo, no es posible derivar afirmaciones análogas respecto a la eficiencia económica en las áreas de las aplicaciones o del escritorio.

Otro aspecto a considerar en el estudio son las estructuras de usuario. El tamaño de las organizaciones y los distintos escenarios de partida para un determinado entorno de SI son aspectos particularmente relevantes al considerar la eficiencia económica de un proyecto de migración. Una observación común es que las agencias públicas pequeñas (por ejemplo, en el sector comunal) usan infraestructuras de SI que pueden ser puestas en marcha y utilizarse con medios simples y sin un entrenamiento intensivo de los usuarios. Como contraste a esto, la utilización fiable de infraestructuras o centros de computación para agencias públicas grandes o especializadas y centros de datos con contratos de nivel de servicio requieren altos niveles de entrenamiento de los usuarios, reglas organizativas para caídas de servicio y emergencias, así como máquinas distintas en algunos casos.

Tomando este marco de referencia en consideración, se requiere un enfoque multi-dimensional para poder analizar la eficiencia económica de los sistemas de información y comunicación. Incluso antes de analizar los costes de los SI, se puede obtener un incremento sustancial de eficiencia económica en la administración pública a través de medidas adecuadas relativas al personal, organizativas y de modernización. Adicionalmente, una estrategia sobre los SI adecuadamente diseñada puede también proporcionar una importante contribución a la hora de incrementar la eficiencia económica.

La eficiencia económica global de los SI está influenciada significativamente por los siguientes parámetros.

153

CTP = Coste Total de la Propiedad

154 PCA = Programas de Código Abierto, PLC = Programas Linux Comerciales Evaluación de la eficacia económica

El grado en que los productos estándar de bajo coste cubren la funcionalidad requerida.

La calidad, flexibilidad de modificación y capacidad de desarrollo de los estándares, tecnologías y productos usados

Introducción efectiva y gestión del sistema

La integración consistente y suave de los componentes y sistemas en una cadena de valor orientada a proceso

Una buena (interna o externa) organización de servicios así como habilidades de alta calidad

Ciclos de vida económica de los productos

Costes y eficacia del proceso de aprovisionamiento

Competencia en el sector de los productos y servicios

La interacción óptima de todos estos factores sobre un periodo extendido de observación es un prerrequisito para establecer y controlas la eficacia económica. Esto significa que un análisis simplificado de los costes individuales falla normalmente a la hora de reflejar el escenario total.

Mas allá de la identificación y la comparación de los costes, la evaluación de los posibles valores de utilidad es otro aspecto importante de la evaluación de la eficacia económica. Especialmente en este área, las consideraciones estratégicas y la previsión de beneficios juegan un papel importante a la hora de permitir una evaluación integral de las situaciones de partida y en perspectiva. Ejemplo: en un contexto estratégico, costes más altos en un componente individual pueden todavía llevar a un resultado total mejor gracias a la independencia entre fabricantes y por tanto de una mejor posición a la hora de negociar el coste de las licencias.

Tanto el método como el resultado pueden servir meramente como una ayuda para determinar la eficacia económica propia de una organización y de aquí obtener el desarrollo de su propia estrategia en SI.

Principios metodológicos

Aunque, generalmente, es posible comparar elementos que difieren en funcionalidad o en términos cualitativos, esto requiere un análisis coste respecto a beneficio el cual confronta también el anticipado incremento en productividad con los costes adicionales anticipados.

Sin embargo, un análisis de productividad en la cadena de valor de los SI no es posible dentro del marco de esta guía de migración ya que no hay disponibles estudios imparciales a largo plazo, especialmente en las administraciones públicas. Sobre la base de la experiencia del día a día y especialmente teniendo en cuenta que ambas plataformas Linux/UNIX y Microsoft son productos maduros con una larga historia de desarrollo, tal análisis podría llevar muy probablemente a un resultado equilibrado. Esta es la razón por la que la evaluación de la eficacia económica en esta guía de migración se centrará en un análisis directo y simplificado monetario y en análisis de beneficios. Evaluación de la eficacia económica

4.2.1	Análisis económico

El método del valor presente neto es usado para determinar los efectos monetarios de los proyectos. Como método dinámico que es, evalúa proyectos de inversión sobre la base de su valor presente neto, por ejemplo, describiendo de forma realista los flujos de dinero (ventas y gastos, en presupuesto y fuera de él) centrándose en una referencia de tiempo común. Las ventas y los gastos que puedan ser relacionados con el proyecto pueden ser planificados con un adelanto de cinco años. El valor actual de mercado de valores futuros se determina por descuento, usando el tipo de interés oficial determinado por el Ministerio de Hacienda.

4.2.2	Análisis de las ventajas

El análisis de las ventajas se aplica si se decide considerar adicionalmente otros efectos que no puedan ser medidos en términos monetarios. El análisis de las ventajas evalúa de forma individual e independiente criterios objetivo ponderados que son subsecuentemente incluidos en la evaluación final. Se usan escalas de evaluación con el fin de cuantificar los llamados errores “blandos”.

Recomendamos evaluar los resultados en dos pasos según lo siguiente.

Debe darse prioridad a los resultados de la evaluación monetaria de la eficacia económica. Los costes y el ahorro resultantes del proyecto se expresan como una relación de retorno de la inversión (ROI) que se ven reflejados como un valor presente neto positivo.

Los resultados del análisis de ventajas se dirigen a las relaciones de urgencia y estrategia. Dentro del marco de los proyectos de migración, deben ser tratados con una prioridad inferior. Este segundo paso esta diseñado principalmente para gestionar casos en los que la evaluación de la eficacia económica según aspectos monetarios es o bien generalmente insuficiente o bien no permite asegurar una clara rentabilidad. Los criterios de urgencia y/o estrategia pueden requerir siempre una alta prioridad de implementación en un proyecto con independencia de los criterios monetarios.

4.2.3	IT-WiBe 21 (recomendaciones sobre eficacia económica en los sistemas TI)

Las evaluaciones de eficacia económica en la administración federal están sujetos a la sección 7 del Código Presupuestario Federal (§ 7 BHO) y de las regulaciones administrativas que emanan de él, el cual, desde 1995, han considerado principalmente métodos económicos. Con el fin de adaptar esas regulaciones a los requerimientos específicos sobre tecnologías de la información, La Agencia Asesora y de Coordinación sobre Tecnologías de la Información del Gobierno Federal (KBSt) ya emitió una directiva administrativa en 1992 titulada "Empfehlung zur Durchführung von Wirtschaftlichkeitsbetrachtungen beim Einsatz der IT in der Bundesverwaltung (IT-WiBe) (recomendaciones sobre eficacia económica para sistemas de TI)“. Una versión completamente revisada se emitió en 1997. La IT-WiBe incluye tres pasos principales como sigue.

Evaluación de la eficacia económica

Identificación de las variables de influencia (criterio de selección)

recogida / evaluación de los datos

Determinación de relaciones

IT-WiBe es un método que, a diferencia del CTP, considera también los posibles ahorros más allá de los aspectos de coste.

4.2.4 Matriz del coste de migración

Como que el método IT-WiBe es generalmente adecuado para evaluar la eficacia económica de un proyecto dado, pero es frecuentemente demasiado complejo y (debido a la falta de las cifras de presupuesto requeridas) no viable, se adopta un método simplificado – la matriz del coste de migración – a efectos de analizar la dimensión monetaria.

Esta aproximación no requiere que los costes y el ahorro se determinen según el método de selección escogido sino que en su lugar los resume en tres categorías, por ejemplo maquinaria, programas y mano de obra. La adquisición155 y los costes de seguimiento así como otros posibles ahorros se registran en un periodo de cinco años para cada una de las categorías. Una vista completa proporciona una visión de conjunto para todos los años y categorías. Además, un análisis del ROI proporciona, de forma similar al método WiBe21, un valor actual neto descontado a la referencia temporal.

Los sectores de "adquisición" y "costes de seguimiento" así como la categoría del ahorro incluyen los siguientes sub-sectores: infraestructura de servidor, aplicaciones de bases de datos, mensajería / trabajo en grupo, aplicaciones web, Ofimática / escritorio y miscelánea. Esto da un instrumento para una rápida valoración de los volúmenes de costes del proyecto, incluyendo la investigación de costes y ahorros, así como para valoración ROI (Recuperación de la inversión) .

4.2.5 Costes totales de la propiedad (TCO)

El principio fundamental del análisis TCO es dividir los costes de un sistema TI en dos grandes grupos, p. ej. Costes directos e indirectos. Los costes directos son todos aquellos costes que pueden ser presupuestados. Una característica común a todos los costes directos es que se pueden medir en unidades monetarias. El segundo gran grupo incluye los costes indirectos que no pueden ser presupuestados. Este grupo incluye los tiempos durante los cuales los sistemas en revisión no están disponibles para usar por razones planificadas o no. Estos tiempos se pueden medir, pero no en unidades monetarias. Esto requiere a veces una conversión controvertida vía salarios pagados “en vano” o perdidas de ganancias. Los costes indirectos también incluyen cualquier actividad de usuario “no productiva”, como el auto aprendizaje, asistencia mutua, aprendizaje formal e informal, administración y copias de seguridad de datos, juegos, surfear, etc.

Este método puede, en principio, ser válido para determinar los costes de migración de los proyectos. Dado que se consideran los aspectos de costes y debido a que un análisis ROI también tendría carencias, y además todos aspectos de costes mencionados antes pueden ser direccionados con el método WiBE 21 y la matriz de costes de migración, la aproximación TCO no se utiliza para evaluar la eficacia económica de la migración de proyectos.

4.2.6 Comparabilidad

La evaluación de la eficacia económica se realiza para dos escenarios de modo que se asegure la comparabilidad de las distintas evaluaciones.

Migración de uno o varios objetos de migración (migración parcial) en el caso de productos o grupos de productos claramente definibles .

Migración completa, p. ej. migración de un entorno completo de TI – Servidores, clientes, infraestructura, aplicaciones especiales.

La migración es generalmente posible de dos modos:

Migración de reemplazado – p. ej. la migración a un entorno completamente nuevo basado en software de Código Abierto, utilizando software de código abierto (OSS) y/o software Linux comercial (COLS) ó

Migración de continuidad – p. ej. la migración de el marco de productos todavía en uso a versiones más nuevas.

Un reducido catálogo de criterios, el cuál está especialmente adaptado para los casos de migraciones parciales, se utiliza para migración de objetos de la migración. Este catálogo incluye los criterios para la introducción y operación .

El criterio general de evaluación del método IT-WiBe, debe ser adoptado en casos de migración completa. Debido a que a veces implica la migración de aplicaciones especiales, también será necesario un trabajo de desarrollo para estas aplicaciones específicas, además de las actividades de migración para los productos estándar.

Estas reglas se aplican generalmente a casos de migración “interna” también. Si se migran productos individuales o grupos de productos (como MS Office), nos referiremos otra vez a objetos de migración y aplicaremos el catálogo de criterios. En contraste a esto, el catálogo de criterios completo de WiBe sólo se aplica en el caso de escenarios más complejos (como productos MS de comunicación y oficina, aplicaciones especiales, etc.).

Otro aspecto a tener en cuenta es que un análisis comparativo de eficiencia económica sólo tiene sentido si las diferentes alternativas se pueden comparar en términos de tecnología y funcionalidad. Las siguientes aplicaciones de Sistema Operativo y tecnología Microsoft pueden considerarse a ser comparadas para los propósitos de esta guía de migración:

Servicios de infraestructura:

Servidor de ficheros.

Servidor de impresión.

Servidor de autenticación.

Redes.

Mensajería y sistemas de trabajo en grupo.

Paquetes y entornos de ofimática.

Servidores de aplicaciones web y bases de datos.

La seguridad IT es un aspecto que hoy en día no se considera comparable a la vista de la alta exposición de los sistemas Windows. Incluso incrementando el esfuerzo y el coste, no es posible asegurar niveles de seguridad de los sistemas comparables, por lo tanto no se hace una comparación de eficiencia económica para el área de seguridad.

4.2.7 Nueva introducción vs. migración de sistemas.

Una análisis de costes con vistas a introducir nuevas tecnologías debe, generalmente, diferenciar entre la nueva introducción y la migración de procesos y sistemas. Como norma general, se puede decir que una nueva introducción es normalmente más simple y barata que la migración donde diferentes, y a veces, arquitecturas históricamente en crecimiento, deben ser reemplazadas y los datos migrados sin interrumpir las operaciones durante mucho tiempo y sin perdida de datos de la aplicación anterior.Como cualquier método de migración depende siempre de su situación de partida, raramente es posible dar un dictamen válido en general para todos los casos de su coste. Aunque la migración es posible en algunos casos sin ningún problema y casi sin coste adicional, la existencia de aplicaciones a migrar desarrolladas por los usuarios, la transferencia de los datos heredados, de estructuras especiales de usuarios y de privilegios de acceso u otras características especiales pueden generar costes de proyecto sustanciales que deben evaluarse caso a caso, también teniendo en consideración aspectos críticos de la agencia pública implicada.

4.2.8 Aproximación de costes totales

Por estas razones, la evaluación de la eficiencia económica se centra en la determinación y análisis de los costes totales de las alternativas generales que se contemplan en esta guía de migración, esto es,

Software de código abierto (SCA).

Software Linux Comercial (SLC).

Software de Microsoft (SM).

Los resultados del análisis dan una proyección fundamental a largo plazo del desarrollo de costes con las distintas alternativas desde la perspectiva actual. Por lo tanto, los costes de la migración deben determinarse de modo que se complete la base para una decisión en favor o en contra de un potencial cambio o migración. Gracias a que un gran número de compañias ofrecen sus servicios en este sector, tal estimación se puede obtener directamente en la forma de una oferta de migración por parte de provedores de servicios tanto internos como externos, y puede compararse con las potenciales posibilidades identificadas.

El método empleado a tal efecto considera la estructura no homogénea y los distintos tamaños de las agencias públicas mediante un análisis de los datos diferenciado. Los costes totales de las alternativas individuales se determinan en varios pasos como sigue:

Definición de las aplicaciones a estudiar.

Determinación de factores de coste en las aplicaciones estudiadas.

Determinación de los valores de los factores de coste para:

agencias públicas pequeñas

agencias públicas medias

agencias públicas grandes

Determinación de los costes de las herramientas de racionalización (herramientas de administración del sistema).

Determinación de la estructura de costes de las alternativas estudiadas.

Determinación de la comparabilidad cualitativa y técnica.

Análisis de escenarios en caso de un cambio a:Software de código abierto (SCA).

Software Linux comercial (SLC).

El potencial inmediato de la opción SCA/SLC en la dimensión puramente monetaria resulta primariamente de los ahorros en costes de licencias (potenciales adicionales resultan de la evaluación estratégica). El resultado de la evaluación de la eficiencia económica es por tanto el análisis de los potenciales a largo plazo mediante la determinación de los costes en licencias de software comparados con los costes totales de las infraestructuras estudiadas.

4.3 La dimensión monetaria (operativa).

4.3.1 Aplicaciones

Para obtener un resultado sensato, el análisis se lleva a cabo dentro de un contexto general que abarca varias aplicaciones. La evaluación general de los costes que se estudian incluye los siguientes campos:

Infraestructura de servidores

Servicios de archivos

Servicios de impresión

Servicios de acceso

Servicios de red

Infraestructura de puestos de trabajo

Ofimática

Web

Mensajería / Trabajo en grupo

Bases de datos y aplicaciones web

La lista con seguridad no es exhaustiva, pero constituye un denominador común para las áreas de infraestructura de costes de las agencias públicas.

4.3.2 Categorías de costes

Asegurar la comparabilidad y estandarizar los resultados de los análisis de costes requiere un modelo de costes uniforme y al mismo tiempo inambiguo para todas las aplicaciones. La metodología adoptada en esta guía de migración se basa en el concepto de que no se lleva a cabo ninguna evaluación de productividad (referirse también al capítulo 4.2), lo cual significa que tampoco se lleva a cabo un análisis por separado de las influencias sobre la productividad relacionadas con los tiempos de parada o con los cálculos de externalización.

Por estas razones, se han definido tres categorías principales de costes para el modelo común de costes como sigue:

Hardware

Comparación de requisitos de hardware

Software

Costes de las licencias de software.

Costes del mantenimiento de software.

Costes adicionales para los sistemas de directorio.

Costes adicionales par los sistemas de gestión y seguridad.

Recursos humanos.

Administración.

Soporte.

Mantenimiento de software.

Formación.

Figura 54: Matriz de costes de migración con categorías de costes y aplicaciones.

Lo siguiente puede ser anotado respecto al tiempo muerto: La experiencia ampliamente disponible, especialmente de centros de cálculo, sugiere la mayor disponibilidad de los sistemas Linux comparado a los sistemas MS Windows y por lo tanto, una mayor productividad bajo Linux .

4.3.3 Características de las categoría aplicadas de las agencias públicas.

Las siguientes secciones describen brevemente las características de los diferentes tipos de agencias públicas. Considerando las, a veces, grandes diferencias en los términos de equipamiento TIy organización de las diferentes agencias públicas, estas solo pueden servir como lineas generales de orientación respetando los criterios de estudio relevantes.

4.3.3.1 Pequeña agencia pública

Usuarios: hasta 250

Hardware: típicamente, pequeña y barata plataforma Intel.

Copias de respaldo y recuperación: mecanismos de copia de respaldo de bajo costo, uso de unidades de cinta o sistemas RAID

Personal: usalmente un administrador con un perfil universal, un delegado

Organización de TI: individuos, algunas veces grupos, bajo grado de especialización

Seguridad y disponibilidad: usualmente de requerimientos bajos a medios

Administración del sistema: herramientas individuales (MS) o scripts (Linux)

4.3.3.2 Agencia pública tramaño medio

Usuarios: entre 250 y 1000

Hardware: pequeños y grandes sistemas de servidores, plataformas Intel y RISC, ambas con posibilidad de arquitecturas distribuidas y centralizadas.

Copias de respaldo y recuperación: disponibles servidores dedicados a copias de seguridad y archivo, el uso de tecnología RAID suele ser la norma.

Personal: varios administradores trabajando 8 horas al dia, especializados, tareas de guardia

Organización de TI: departamento TI

Seguridad y disponibilidad: usualmente de requerimientos medios a altos

Administración del sistema: herramientas de distribución del software, clientes ligeros, monitorización y supervisión de la red y del sistema

4.3.3.3 Agencia pública tamaño grande / centro de operación de computadoras

Usuarios: más de 1.000 (hasta 100.000)

Hardware: clusters Intel de bajo costo, soluciones de grandes servidores, arquitecturas distribuidas, sistemas centrales mainframe

Copias de respaldo y recuperación: servidores de backup centrales o de recuperación de desastres con hardware Robot o Jukebox

Personal: varios administradores trabajando 8 horas al dia, especializados, y con tareas de guardia y respuesta a emergencias

Organización de TI: centro de computadoras, grupos de administración locales, si fuese necesario

Seguridad y disponibilidad: requerimientos altos a muy altos, uso de soluciones SAN extensas

Administración del sistema: herramientas de distribución del software, clientes ligeros, monitorización y supervisión de la red y del sistema

4.4 Dimensión estratégica

Además del análisis directo monetario de los costes totales de las diferentes alternativas, debe incluirse un anális estratégico (o dimensión en terminología WiBe).

La necesidad de un análisis estratégico se origina en las repercusiones monetarias de la “dependencia de un proveedor” como factor estratégico. Esto es relevante desde un punto de vista macroeconómico y microeconómico.

4.4.1 Debate macroeconómico

Aspectos relativos a la competitividad son la clave en esta discusión. Las principales ventajas en competitividad funcional son las siguientes:

Mejor calidad del producto

Menores precios del producto

Mayor ratio de innovación

Aunque todos los fabricantes de software presumen de asegurar la mayor calidad del producto e innovación tecnológica, esta declaración de validez general puede raras veces ser hecha en la realidad. En especial, el desarrollo del World Wide Web nos muestra que Microsoft, por ejemplo, “se durmió” durante largo tiempo ante la más importante innovación de las décadas recientes.

A pesar de la naturaleza fundamental del debate macroeconómico, los lectores de esta guía de migración no pueden influir directamente en el aspecto macroeconómico que se dejará de discutir a partir de aquí con más detalle en este documento. La Comisión Europea está actualmente debatiendo la publicación de la posición monopolística de Microsoft en el campo de los sistemas operativos. Los resultados y conclusiones, en todo caso, están por ser comunicados.

4.4.2. Debate microeconómico

Un análisis sobre la dependencia de una agencia de probeedores de productos y servicios es el punto importante en este contexto. Aunque esta dependencia está sustancialmente alimentada y fundamentada sobre la existencia de monopolios o cuasimonopolios, la dependencia excesiva de proveedores puede ocurrir y causar desventajas económicas incluso en un entorno de competititividad funcional. Estas desventajas pueden tomar la forma de mayores precios del producto, al igual que ciclos de vida más cortos del producto y costes adicionales de introducción en el caso de migración continuada.

Bajo condiciones extremas, esta dependencia puede dar lugar a una situación donde dejen de existir precios razonables y alternativas aceptables para la actuación. En contraste a esto, una situación basada en el equilibrio estratégico da lugar a una mejor posición negociadora con acceso a alternativas ante la aparición de problemas.

4.5 Conjunto de resultados de la evaluación de la eficiencia económica

La mayor parte de los estudios relativos a este tópico usan el acercamiento al coste total en su análisis y aceptan que una parte sustancial del coste es debida a costes de personal junto con la introducción y operación más que a los costes de las licencias. Debido a diferentes suposiciones – casi todas concernientes a las capacidades de administración de sistemas – los estudios llegan a conclusiones contradictorias en lo que respecta a los beneficios económicos de las diferentes alternativas.

Los estudios favorables a Microsoft se basan en el bajo costo de personal debido a un inferior estandar de aprendizaje y por tanto a inferiores salarios básicos del personal administrativo siendo esta la más importante (aunque no única) razón para su bajo TCO calculado para plataformas Microsoft . Otra ventaja – aunque también basada en suposiciones muy cuestionables – es la vista desde el campo de la seguridad en TI que se dice es generalmente más fácil de implementar en platafomas basadas en Microsoft.

Estudios escépticos de Microsoft llegan generalmente a un resultado diferente. Aunque estos estudios también encuentran una direrencia en los salarios base, esta está más que compensada por las mejores capacidades de administración, especialmente en operaciones de centros de computadoras.

Los estudios realizados en el ámbito de esta guía de migración se referirán a tres factores importantes del análisis del TCO que son necesario considerar para la introducción de Linux/OSS:

Porcentaje del costo de licencias software dentro del coste total

Grado de especialización de sistemas de TI e infraestructuras candidatas

Grado de automatización de sistemas de TI e infraestructuras candidatas

El coste de las licencias software dentro del coste total de sistemas y procesos de TI varía del 20% al 50%. Esto es por tanto también el rango de las potenciales alternativas directas o indirectas de OSS y COLS en términos puramente monetarios ateniéndonos a la condición de que los resultados de trabajo que puedan ser realizados sean comparables.

Además de lo concerniente a la porción del coste de licencias dentro de los costes totales de TI, otros dos factores deberían ser considerados para apreciar los verdaderos grados de libertad para los que toman decisiones sobre TI. Estos son, por un lado, el índice de costes que pueden ser directamente influenciados, y por otro lado, el análisis del presupuesto de costes relevantes.

Los tipos de coste que pueden ser directamente influenciados incluyen los siguientes:

Costes de adquisición de software:

Menores precios de compra gracias mayormente a un cambio a productos de menos costo o gracias a la negociaciónCostes de mantenimiento del software:
Principalmente por la consolidación de productos software (reducción de la variedad de productos) o por la omisión de los ciclos de actualización.

Costes de adquisición del hardware:
Gracias al cambio a plataformas hardware de menor coste.

Costes de mantenimiento del hardware:
Por la consolidación del hardware (reduciendo la variedad de productos) o por la extensión de los ciclos de vida.

A diferencia de los costes hardware o software, los costes de personal, como los gastos de TI más complejos, son, normalmente, costes que no pueden ser directamente influenciados. Esto se debe al hecho de que la introducción y operación de infraestructuras y sistemas TI está principalmente relacionados con una base que está menos determinada por los modelos de licencia individual y más por los requisitos relativos a la intensidad del servicio, la disponibilidad y la seguridad de las plataformas utilizadas. La reducción del número de personal existente o la subcontratación y consolidación no suelen ser alternativas que puedan implementarse a corto plazo.

El análisis de los costes en TI que pueden estar directamente influenciados, muestran que los costes en licencias (adquisición de software, mantenimiento, actualizaciones) conforman la mayor parte y, por ello, ofrecen mayor libertad de acción.

Recomendaciones de migración basándose en la evaluación de la eficiencia económica

Las recomendaciones de migración están relacionadas con los siguientes escenarios:

Migración completa (para agencias públicas grandes, medianas y pequeñas)

Migración continua (para agencias públicas grandes, medianas y pequeñas)

Migración parcial (migración selectiva y migración parcial de la parte servidora)

Los ejemplos mostrados no tienen en cuenta el aspecto hardware. Las migración de hardware moderno (no más de 2 ó 3 años) es posible sin modificar el hardware. En el caso de hardware antiguo, el reemplazo o la inversión suplementaria puede ser necesaria independientemente de la dirección de la migración (Fuente Abierta o Microsoft).

El análisis monetario está basado en una media de uso de los bienes de cinco años, típico de las agencias públicas. Sólo se espera reinversión tras este plazo. Esto es igual para la migración hacia Linux como la migración interna de Microsoft (continuidad). No se asumen los costes de mantenimiento durante los cuatro años tras la adquisición.Los cálculos se basan en supuestos precios típicos para las agencias públicas. Los cálculos incluyen, principalmente, precios de compra. También se calculan las variantes de alquiler para los productos Windows y Office.

Una comparativa relativa a los costes de migración relacionados con los usuarios para migraciones completas o continuas muestra claras ventajas en caso de migración hacia el entorno de fuente abierta.

Tabla 43: Comparativa de costes de migración relacionados con los usuarios para migraciones completas / continuas.

Los costes para migración continua son casi dos veces mayores a los costes de migración completa.

Las ventajas en coste de la migración completa se deben, principalmente, a los ahorros en software (alrededor del 92% al 95% para las agencias públicas, desde grandes a pequeñas). La comparativa de los costes de personal, en cambio, muestra diferencias a favor de la migración continua. En las agencias públicas de tipo pequeño / mediano / grande, los costes de personal para esta variante de migración oscilan a favor un 14.0% / 6.5% / 2.2%.

Una máxima es casi idéntica para ambas variantes de migración: ¡el coste se incrementa según desciende el tamaño de la organización!Figura 55: desarrollo de los costes de migración.

Migración completa

Los ejemplos calculados indican el dominio de los costes de personal, del orden del 90% (entre el 87% y el 93%). Los costes de migración oscilan entre los umbrales de porcentaje indicados en la tabla para los distintos tipos de agencias públicas.

Tabla 44: distribución de los costes en caso de una migración completa en las agencias públicas.

Los ahorros calculados en este modelo representan el desembolso necesario para la migración desde el entorno Windows 2000.

Tabla 45: costes totales de migración por usuario en caso de migración completa.La migración completa significa un efecto de ahorro superproporcional en agencias públicas grandes. Los ahorros en conjunto con la migración desde Windows NT a Linux, comparado con la migración a Windows 2000, alcanzan un orden de magnitud que excede tres veces el desembolso.

Los costes de personal en conjunto con el cambio son de un tamaño comparable, por lo que el ahorro en los costes de licencias es la mayor parte del ahorro.

Los ahorros mostrados sugieren la migración al entorno de Fuente Abierta.

El escenario para medianas y pequeñas agencias públicas es, en general, comparable a las agencias públicas grandes. La migración a Fuente Abierta está encarecidamente recomendada también para estos tipos de agencias públicas.

Migración continua

En el caso de este tipo de migración, no se pueden identificar ahorros y, por eso, no pueden ponerse aparte. Este es el por qué de que sólo se muestren los volúmenes de costo relacionados con el escenario.

Tabla 46: costos de migración total por usuario en caso de migración continua.

La eficiencia económica de la migración aumenta según aumenta el número de usuarios. En el modelo aquí usado, no está justificado el cambio de la adquisición al alquiler.

Migración parcial

Migración selectiva

Esta forma de migración implica el reemplazo permanente de un componente del sistema con una estructura TI completa. Este caso se ilustrará con el reemplazo del Exchange 5.5 por el Samsung Contact. Bajo la condición de que en este caso se mantiene toda la funcionalidad, esta forma de migración puede serEvaluación de la eficiencia económica

recomendados para todos los tipos de empresas públicas porque efrece un ventaja en coste comparada a una migración interna de Microsoft.

Los rangos de costes prorporcionados por Samsung encabezan las bandas de coste en migración por usuario, mostradas en la tabla superior.

La distribución entre el software y el coste de personal oscila alrededor del 50%. Este reparto puede variar, dependiendo de la intensidad de la la labor de los procesos de cambio. Los costes aquí tomados, se asumen iguales a aquellos para una migración a Exchange 2000. De cualquier modo, la experiencia sugiere que este reparto de costes es más bajo, de modo que el coste real de personal es menos del 50%

Migración parcial en el lado del servidor

Esta migración parcial corresponde a aquella parte de una migración completa en el lado del servidor. Como una alternativa a una migración completa, esta forma de cambio asegura una relativa alta eficiencia con vistas a la urgencia y criterios de calidad/estrategia poque la parte relevante del proyecto de migración tienen lugar en el area der servidor con vistas a estos aspectos.

Los costes son alrededor de 120€ por usuario menos que para una migración completa. (observese la tabla inferior)

Esta migración alternativa es recomendable no solo por razones d ecoste, sino también porque permite una transición suave al mundo del OSS con mínimas repercusiones para los usuarios.

Aunque en este caso los costes de migración conciernen únicamente a la plataforma del servidor, relaciona no obstante, el número de usuarios en el tipo de empresa púbica concerniente al propósito de la comparación con los costes de las otras.

(página 289)

La evolución del coste en el caso de una amplia migración confirma la tendencia de disminuir los costes con un incremento del tamaño de la organización anteriormente identificada.

Comparado a una migración completa, el reparto de costes de cambio en el cliente final es relativamente constante.

Conclusiones

Una comparación de aspectos económicos de los distintos tipos de migración indica claras ventajas de una migración parcial en el servidor final. Si una agencia pública decide migrar de forma general sus sistemas a Código Abierto, este acercamiento es recomendable desde una perspectiva comercial. Una migración amplia en el servidor final (como variante y/o estado precursor de una migración completa) brinda un especial tributo a los intereses de una agencia pública en el cliente final y por ello conduce hacia una implementación de la nueva plataforma IT más eficiente y sostenible.

Si una agencia pública decide conservar sus sistemas orientados a Microsoft, una migración continua es el procedimiento adecuado.

Las técnicas de migración completa y selectiva son acercamientos menos que óptimos desde una perspectiva económica. En el caso de requerimientos específicos y/o decisiones en una agencia pública, esos métodos pueden, sin embarbo, convertirse en el mejor acercamiento .

Gastos con diferentes escenarios de migración

Asunciones generales acerca de los gastos de migración

Los gastos totales de los escenarios de migración estudiados están aquí compuestos de los siguientes componentes:

Costes de hardware.

Costes de software.

Costes de personal.

Este capítulo estudia anchos de banda para gasto en personal. El aspecto de hardware será desatendido , con los costes de software siendo incluidos en los ejemplos respectivos .

En esta guía de migración, cualquier estimación de gasto es inevitablemente sólo una tosca estimación, porque ni la situación inicial ni el escenario objetivo deseado son (o pueden ser) conocidos exactamente. Por ello es por lo que nos servirán como ejemplos tres escenarios de migración diferentes. Los tres escenarios están categorizados de acuerdo a ejemplos

(página 290)

de agencias públicas ya descritos aquí. Esos tres escenarios serán vagamente perfilados a continuación.

Las asunciones siguientes son aplicables a todos los escenarios:

El cambio de los servidores es acompañado de un repuesto de hardware (nuevo hardware servidor).

Los ordenadores de trabajo son dispositivos con Windows NT 4 en su totalidad (de modo que no sea necesario asignar guías de grupo para los ordenadores de trabajo).

El entorno heredado es una "buena" condición, y el propósito primario de introducir Windows 2000 no consiste en librarse de cargas históricas. Esto principalmente implica que la así llamada "migración in situ" (actualizar un dominio NT existente) no es rechazada.

Una consistente administración técnica de sistemas es aplicable para productos que sean también adecuados para Windows 2000.

Existe un documentado concepto operativo, el cual puede ser actualizado.

Los entornos son completamente administrados por una organización soberana, la cual principalmente actúa como una organización central.

Las pérdidas por fricción, debidas a inconsistencias internas y políticas, y a fondos limitados, son mínimas.

Además, deben considerarse las siguientes condiciones límite:

En este documento no se estudia un cambio de ordenadores de trabajo a Windows 2000/XP.

Tampoco se estudia un cambio de Servicios Finales de Windows.

Un cambio de aplicaciones de servidor, como MS Exchange, MS SQL, MS SNA Server, MS Proxy o aplicaciones terceros fabricantes o servidores NT clúster (Edición Empresa) con unidades de almacenamiento externas (subsistemas de disco duro o SAN), no es considerada.

El modelo estudiado consiste en seis fases, y puede ser descrito brevemente en palabras clave como a continuación.

Taller de trabajo (empezar, acarreando departamentos de especialistas y las disciplinas informáticas relacionadas, identificando cualquier consecuencia relevante, estableciendo prioridades, identificando necesidades de realizar decisiones, determinando acercamientos y planes de proyecto, estimaciones detalladas de gasto, definiendo subproyectos y creando grupos de trabajo).

Inventario (paisaje de aplicación, líneas de comunicación, infraestructura de red, servicios centrales, procedimientos operativos, requerimientos futuros).EVALUACIÓN DE LA EFICIENCIA ECONÓMICA

Concepto general (preparando especificaciones de rendimiento, refinando el plan de proyecto y definiendo paquetes de trabajo, factibilidad técnica, implementación de la integración y del entorno de prueba, descripción del entorno de producción restante, integración de las aplicaciones, selección de las máquinas y su evaluación)

Concepto detallado (definición detallada del rango de funciones, integración en el entorno TI restante, desarrollo de procedimientos de instalación y distribución de los programas, integración en las operaciones, planificación de despliegue, planificación de piloto, entrenamiento del personal TI)

Piloto (no mas características, suministro de un grupo de usuarios representativo, pruebas de carga, integración del UHD (user help desk), primera prueba de tamaño, realimentación al concepto detallado)

Despliegue (poner los procedimientos de instalación en práctica, duplicación de los sistemas servidores, información y entrenamiento al usuario, soporte por el equipo del proyecto, transición a la operación regular)

Se requiere adicionalmente la gestión del proyecto.

4.8.2 Costes de migración de Windows NT a Windows 2000

La inversión necesaria para la migración de Windows NT 4 a Windows 2000 sobre la base de las siguientes especificaciones se analiza a continuación.

Servicios de inicio de sesión

Servicios de red

Servicios de ficheros

Servicios de impresión

La migración a Windows 2000182 incluyendo el directorio activo puede, al igual que otros proyectos de migración, ser dividido en diferentes fases que contienen diferentes paquetes de trabajo. La tabla inferior (Tabla 51) describe los escenarios considerados en palabras clave.

Tabla 51: Descripción de escenarios para la migración de Windows NT a Windows 2000

Categoría	Número de usuarios	Situación de partida	Escenario objetivo
Pequeño	hasta 250	Un dominio NT con dos DC que proporcionan adicionalmente WINS, DNS y DHCP	Un dominio Windows 2000
		Un lugar	Un lugar
		Dos servidores de fichero y dos servidores de impresión	Dos servidores de fichero y dos servidores de impresión

182 La migración de Windows NT a Windows 2000 se denominará en adelante como "migración continua". EVALUACIÓN DE LA EFICIENCIA ECONÓMICA

Categoría	Número de usuarios	Situación de partida	Escenario objetivo
		Tres dominios NT confiando entre ellos, cada uno con cuentas de usuario y máquina	Un dominio Windows 2000 Tres lugares
Medio	Más de 250 y menos de 1000	Adicionalmente los DC proporcionan WINS, DNS y DHCP Tres lugares de tamaño similar (número de usuarios)	Además, dos servidores de fichero y dos servidores de impresión por cada lugar
		Tres dominios, cada uno con dos servidores de fichero y dos servidores de impresión	
		11 dominios con modelo de maestro único (1 dominio de cuentas y 10 dominios de recursos)	Un dominio Windows 2000 Diez lugares
Grande	Más de 1000	Los DC proporcionan adicionalmente WINS, DNS and DHCP 10 lugares	Además, dos servidores de fichero y dos servidores de impresión por cada lugar
		10 dominios, cada uno con dos servidores de fichero y dos servidores de impresión	

Los escenarios objetivo descritos en los entornos grande y medio incluyen consolidación del número de dominios a uno.

Se asume para los tres entornos que al menos un dominio existente es actualizado (actualización in-situ). Esta asunción puede considerarse un anticipo del concepto de migración y objetivo, pero también implica una simplificación de la vía de migración en el sentido que elimina trabajos adicionales de migración relacionados a cuentas de usuario (palabras clave: clonación, historia SID, asignación de nuevos privilegios (ReACLing)).

Los siguientes requisitos expresados en hombres-día (HD) son estimaciones para los diferentes entornos y fases.

Tabla 52: Hombres-día requeridos en el caso de una migración continua

Requisitos en HD	Entorno	
Fase	Sub-paquete	Pequeño	Medio	Grande	Comentarios
Workshop		5	10	10	Distribución plana
Toma de contacto	Inicio de sesión	2	6	22	2 por dominio
	Red				
	File	1	5	21	1 para el primer dominio
					2 para cada dominio posterior
	Impresión	2	6	20	2 para cada dominio posterior
	Procesos	2	4	12	2 para el primer dominio
					1 para cada dominio posterior
	Requisitos	1	3	10	1 por lugar
Concepto general	Rendimiento	2	4	6	Distribución plana

Una proporción fija adicional del 10% debe ser considerada en concepto de gestión de proyecto.

Las inversiones estimativas que se muestran, deben interpretarse como valores mínimos. Se puede definir una cantidad sustancial de requerimientos de tiempo para cada uno de los subapartados si se analizan y corrigen las especificaciones adecuadamente. Se puede mencionar el ejemplo en este contexto, como es la preparación y/o actualización de un concepto operativo.

Los recursos calculados afectan tanto a entradas internas como externas. En el caso de la migración de Windows descrita aquí, la relación de entradas se encuentra entorno al 20% internas y hacia el 80% externas.

4.8.3 Gasto en migración de Windows NT a Linux

La tabla siguiente describe las situaciones consideradas en las palabras clave183.

Tabla 53: Descripción de la situación apta para migrar de Windows NT a Linux

Las situaciones objetivo de entornos medianos y grandes incluyen la concentración de diversos dominios en uno solo. Se asume en todos los entornos que se sustituirá al menos un dominio antiguo (actualización puntual). Esta suposición puede considerarse un anticipo del concepto y objetivo de la migración, pero también una migración simplificada.

183 De ahora en adelante aludiremos a esta forma de migración como "migración total".Aproximación general (preparación de las especificaciones de prestaciones, refinado del plan del proyecto y definición de los bloques de trabajo, viabilidad técnica, implementación de un entorno de integración y pruebas, descripción del entorno de producción restante, integración de las aplicaciones, selección y evaluación del hardware)

Aproximación detallada (definición detallada del rango de las funciones, integración en el resto de entorno de los SI, desarrollo de procedimientos de instalación y distribución del software, integración en las operaciones, planificación del despliegue, planificación piloto, formación del personal de los SI)

Piloto (acotación de la funcionalidad, proporcionar un grupo de usuarios representativos, pruebas de carga, integración del CAU (Centro de Atención a Usuarios), comprobación preliminar de dimensionado, realimentación a la aproximación detallada

Despliegue (poner en funcionamiento los procedimientos de instalación, duplicación de los servidores, información y formación a los usuarios, proporcionar soporte del equipo del proyecto, transición a funcionamiento normal)

Adicionalmente, también se requiere gestión de proyectos.

Costes de migración de Windows NT a Windows 2000

A continuación se analiza el desembolso necesario para migrar de Windows NT a Windows 2000 sobre la base de las siguientes especificaciones.

Servicios de acceso

Servicios de red

Servcios de ficheros

Servicios de impresión

La migración a Windows 2000 puede, como cualquier otro proyecto de migración, ser dividida en diferentes fases que contienen distintos bloques de trabajo. La tabla siguiente (Tabla 51) contiene los escenarios considerados como claves.

Tabla: 51: Descripción de escenarios de migración de Windows NT a Windows 2000Los escenarios finales descritos para los entornos medianos y grandes, incluyen también la consolidación de todos los dominios a un sólo dominio.

Se ha supuesto, para los tres entornos que, al menos, un dominio antiguo es actualizado (actualización local). Esta suposición puede considerarse como un paso previo de los conceptos de objetivo y migración, pero también significa una simplificación del proceso de migración, puesto que elimina el trabajo adicional de migrar las cuentas de los usuarios (palabras clave: clonar, historia de SID, asignación de nuevos privilegios (ReACLing)).

Se han estimado las siguientes necesidades en días-hombre (DH) para los diferentes supuestos y fases.

Tabla 52: Requerimientos en días-hombre para el escenario de migración de continuidad.

Debe considerarse un reparto equitativo adicional del diez por ciento para gestión de proyectos.

Los desembolsos aquí mostrados, deben ser considerados como límites inferiores. Podrían definirse importantes requerimientos de tiempo para cada uno de los subapartados si las especificaciones requeridas son analizadas y modificadas como corresponda. Un ejemplo a mencionar en este contexto es la preparación y/o actualización del bloque operativo.

EVALUACIÓN DE EFICIENCIA ECONÓMICA

*****CUADRO******* TABLA 55 (Requerimientos de tiempo de trabajo persona/día para la migración desde Exchange 5.5 a Exchange2000

*****FIN DE CUADRO**********

Una superficie adicional de otro diez por ciento debe ser considerado para la dirección del proyecto.

Los tiempos de trabajo hombre/día estimados se refieren a las inversiones tanto internas como externas. En el caso de la migración aquí descrita sobre Exchange, la proporción es del orden de alrededor del 25% de inversión interna y sobre el 75% de inversión externa.

4.8.5 Gasto en migración desde Exchange 5.5 a Samsung contact.

El gasto necesario para la migración desde Microsoft Exchange 5.5 a Samsung Contact se estima a continuación.

Los siguientes supuestos son aplicables a todos los entornos (sobre una base Samsung Contact).

Todos los servidores Samsung Contact están basados en los sistemas operativos Linux o UNIX.

La consolidación de múltiples servidores MS Exchange es posible.

El número de usuarios es únicamente dependiente del funcionamiento de la CPU. No hay restricciones de correo entrada, y el almacenamiento de mensajes puede tener una capacidad de hasta varios terabytes.

No es necesaria la migración a ADS.

El sistema no es crítico en recursos, por lo que el hardware existente puede ser reutilizado después de la migración (Linux).

La migración de los directorios públicos, calendario y contactos es posible.

Tabla 56: Requerimientos tiempo de trabajo hombre/día para la migración desde Exchange 5.5 a Samsung Contact

*****************CUADRO************

___________________________________________________________________________________

Página 298	Versión: 28.09.2003

EVALUACIÓN DE EFICIENCIA ECONÓMICA

*****CUADRO******* TABLA 55 (Requerimientos trabajo hombre/día la migración desde Exchange 5.5 a Samsung Contact

*****FIN DE CUADRO**********

4.8.6 Estimaciones recomendadas en cuanto a productos/grupos de producto

4.8.6.1 Supuestos generales

Únicamente se consideran los indicadores coste/beneficio en los cálculos de los escenarios ejemplo objeto de migración, por ejemplo:

Costes en hardware

Costes en software

Costes de importación de datos (=costes de personal).

En contraste con estos antecedentes, cualquier otro tipo de costes existentes, además de los tipos de coste mencionados arriba, se considera neutrale, por ejemplo.:

Costes de compatibilidad

Costes de formación

_________________________________________________________________________________________________

Versión: 29.08.2003	Página 299Evaluación de la eficiencia económica

Costes de Administración

Los proyectos de migración típicamente ofrecen menores potenciales intrínsecos de ahorro (software) únicamente. La eficiencia económica de un proyecto raramente está basada en este factor. Como los proyectos de migración generalmente se centran en la decisión de migrar entre Microsoft o a una plataforma OSS un análisis cruzado se usuará en los siguientes ejemplos. Para este propósito los costes diferenciales comparables en una migración intre Microsoft que no son necesarias son consideradas como ahorro dentro del ámito de una migración del análisis de la migración a OSS.

Se asume una tasa media de 1000 € diarios para el coste del personal externo.

La información para las autoridades federales superiores, serán usadas aquí como una base para asignar los costes de personal. El coste estimado está basado en un grado salarial IV a (según las agencias federales superiores , 36.98€ por hora, 462 minutos al día)

Los costes de personal de los ejemplo para una grande, mediana y pequeña empresa pública son distribuidos a recursos externos e internos en un 80 a 20.

El tipo de interés especificado por el Ministerio federal de finanzas (BMF) (en la actualidad el 6%) se usa para descontar ahorros futuros.

Las licencias de software para las empresas públicas cuestan alrededor del 50% de los precios de las listas comunes. Estos términos y condiciones son aceptados por los proveediores, casi completamente.

Los ejemplos siguientes son presentados en dos diferentes estructuras para ilustrar las diferentes opciones descritas para una evaluación de la eficiencia económica en las aplicaciones prácticas. Estas dos estructuras son:

Estructura acorde con WiBe21 en base a los criterios definidos.

Estructura de las categorías de costes TI en base a 3 factores de costes mayores, por ejemplo hardware software y mano de obra, acorde con la matriz de costes de migración. 4.8.6.2 Ejemplos acordes con la estructura WiBe21

Ejemplo de migración Infraestructura de servidor, pequeña empresa pública

Tabla 57: Ejemplo de migración Infraestructura de servidor, pequeña empresa pública Tabla 58: Ejemplo WiBe 1, infraestructura de servidor [Windows NT / Linux], agencia pública pequeña

El ejemplo WiBe anterior muestra un valor actual neto positivo a condición de que la ayuda externa del cambio no exceda de 28 jornadas laborales y la ayuda interna necesaria 7 jornadas laborales.

Ejemplo de migración: infraestructura de servidor - agencia pública media

Tabla 59: Ejemplo de migración: infraestructura de servidor - agencia pública media

Tabla 60 – Ejemplo WiBe – Infraestructura de servidor [Windows NT /Linux], agencia pública de tamaño medio.

Infraestructura de Servidor [Windows NT-> Linux] – Agencia pública de tamaño medio

TABLA 60

El ejemplo WiBe anterior muestra un valor presente neto positivo condicionado a que el soporte externo para la migración no exceda los 76 días hombre y el soporte interno necesario los 19 días hombre

Ejemplo de migración: Infraestructura de Servidor – agencia pública de tamaño grande

Tabla 61: Ejemplo de migración: Infraestructura de Servidor – agencia pública de tamaño grande

TABLA 61

CONTINUACIÓN TABLA 61

Tabla 1: ejemplo WiBe – infraestructura del servidor [Windows NT / Linux], agencia pública mediana

El ejemplo WiBe anterior muestra un valor neto presente positivo con la condición de que el apoyo externo no exceda los 76 días y el apoyo interno necesario los 19 días.

Ejemplo de migración: infraestructura de servidor – agencia pública grande

Tabla 2: Ejemplo de migración: infraestructura de servidor – agencia pública grande

Objeto de la migración:	Migración desde Microsoft Windows NT a los entornos OSS en Linux – servidores y clientes
Escenario:	Agencia pública grande, 10,000 users
Factores de éxito:	Costes de software, costes del cambio
Suposiciones:	Los factores coste/beneficio siguen los siguientes tres criterios: Costes de licencia Costes del cambio Costes de formación En este marco, cualquier otro tipo de coste existente además de los mencionados se consideran neutral, es decir, no se ha considerado en el cálculo modelo ningún factor coste/beneficio que no sea los tres antes mencionados. El ejemplo considera la diferencia con los costes de un cambio de MS Windows NT a Linux que no se plantean como ahorros. Esto afecta tanto a las licencias de software como a los costes de cambio. Licencias de software: La licencia de Windows se considera como un ahorro, lo que implica la diferencia con el gratuito sistema Linux. Costes del cambio: La diferencia entre los requisitos de días para la migración interna de Microsoft y la migración a Linux se valora con un precio medio del personal externo de 1.000,00€ y cuenta como un ahorro. Los días ahorrados internamente se valoran utilizando los valores especificados por el Ministerio Federal de Finanzas (BMF). Los costes de formación para usuarios tienen el mismo valor para ambas plataformas (Windows 2000 and Linux), y por eso son negligibles. El coste de formación del administrador está planificado para 2 administradores, cada uno durante 5 días (alrededor de 2.000,00€ con el IVA incluído). La relación entre los gastos externos e internos se valora como un 80% externo y un 20% interno.
Cubrir gastos	El proyecto cubre gastos incluso durante el primer año.

Tabla 3: ejemplo WiBe – infraestructura del servidor [Windows NT / Linux], agencia pública grande

The anterior ejemplo WiBe muestra un valor neto presente positivo a condición de que el apoyo para el cambio externo no exceda los 248 días y el apoyo interno necesario los 62 días. Con 66 días de apoyo externo, se consigue un valor presente neto que no llega a ser relevante para el presupuesto.

Ejemplo de migración: Office / escritorio cliente

Tabla 4: Ejemplos de migración: Office / escritorio cliente

Objeto de la migración:	Migración desde Microsoft Office al entorno OSS en Open Office – servidores y clientes
Escenarios:	Agencia pública pequeña hasta 250 usuarios Agencia pública mediana hasta 1.000 usuarios Agencia pública grande más de 1.000 usuarios
Factores de éxito:	Costes de software, costes de cambio
Suposiciones:	En el momento de la migración a OpenOffice, el sistema operativo Linux está disponible en servidores y clientes. Lo que lleva a los costes/beneficios son los siguientes tres criterios: Costes de licencia Costes de cambio Costes de formación En este marco, cualquier otro tipo de costes existente además de los tres mencionados se considera neutral, es decir, en el cálculo modelo sólo se considera los tres factores antes mencionados. En el ejemplo, la licencia de Microsoft Office, a diferencia de la de Open Office, se considera un ahorro. Los costes de formación de usuarios se supone que son casi idénticos para ambas plataformas (Windows 2000 y Linux), y por lo tanto se suponen negligibles. La formación de administradores está planificada para 2 administradores, cada uno durante 5 días (en total alrededor de 2.000,00€, incluyendo el IVA). Los ejemplos calculados aquí se basan en las sigueintes suposiciones cuantitativas : Número de documentos por usuario 13 Número de macros por usuario 0.07 Tiempo de cambio por documento 0.2 h Tiempo de cambio por macro Agencia pública pequeña 0.91 h Agencia pública mediana 5.54 h Agencia pública grande 6.94 h
Cubrir gastos	El proyecto cubre los gastos durante el primer año para todas las categorías de agencias públicas.

Los siguientes ejemplos se calcularon, entre otras cosas, con la intención de identificar un límite superior para el tiempo necesario para la migración de macros. Los tiempos indicados en las suposiciones representan los respectivos límites superiores. Hasta este valor no se produce, bajo condiciones c.p. un valor neto presente negativo.

Además, este análisis proporciona una visión de los gastos en el caso de una migración interna en Microsoft. Estos gastos se consideran ahorros, y se incluyen en el “valor neto presente, rp” (rp = relevante para el presupuesto).

Los costes de migración a Open Office son totalmente no relevantes para el presupuesto porque esta migración la lleva a cabo el personal propio.

Sin embargo, en cualquier caso, los costes del apoyo externo deben ser añadidos a los gastos considerados aquí. Estos costes de apoyo externo pueden presupuestarse a niveles casi idénticos para ambas formas de migración.

Tabla 5: Ejemplo WiBe – Office / escritorio cliente [MS Office / Open Office], agencia pública pequeña

Tabla 6: Ejemplo WiBe – Office / escritorio cliente [MS Office / Open Office], agencia pública mediana

Tabla 7: WiBe

Este proyecto cubre gastos en tres años. Office y el entorno Windows han migrado a Open Office, incluyendo al entorno Linux. Se han migrado 6.500 documentos.

No se incurre en gastos en el software Open Source. Se ahorran cerca de 160.000 € en los costes de licencias anuales que hay que abonar a Microsoft. Esta cantidad se considera ahorro en las recomendaciones sobre la valoración de la eficiencia económica (WiBe) y es presupuestariamente relevante.

La migración se lleva a cabo mediante personal propio, por lo que los costes de cerca de 148.000 € no son presupuestariamente relevantes.

Se aplica el método del valor presente neto para descontar las cantidades a la fecha actual, por lo que el ahorro ahora supone un total de 142.000 € en los 3 años (licencias de Microsoft que ya no hay que pagar). Paralelamente, el ahorro en costes de migración supone durante una año la cantidad de aproximadamente 139.000 €. El valor presente neto asciende por lo tanto a 3.085 €. Este proyecto, por consiguiente, es económicamente eficiente.

El análisis de riesgos (probabilidad de existencia de ahorro y costes de migración) no se tendrá aquí en cuenta porque el ahorro representa los actuales pagos de licencias que se omitirán en el futuro. Los tiempos requeridos para la migración se estimaron dentro de los rangos más altos más que en los más bajos en este contexto.

La mejor práctica aplicada a las cantidades asumidas aquí es el análisis de Gartner

que fue adaptado para reflejar los intereses de las Administraciones públicas.

Tabla 69: Ejemplo WiBe - Windows/Office a Linux/OpenOffice: Punto de equilibrio después de 5 años

TABLA 69Este proyecto cubre gastos tras 5 años. Se debe observar lo que sigue teniendo en cuenta el ejemplo en el que se alcanza el punto de equilibrio en un periodo de 3 años.

Las únicas diferencias son que el número de documentos que había que migrar se incrementó hasta 12.500 (lo que corresponde a unos 25 documentos por usuario). El periodo monitorizado se incrementó a 5 años.

El método de cálculo permanece sin cambios. Se obtiene un valor presente neto positivo de 1.496 € después de 5 años.

Para el análisis de riesgos y cantidades asumidas, véase arriba.

Tabla 70: Ejemplo de migración: mensajería/software de trabajo en grupo (messaging/groupware) – agencia pública de tamaño pequeño

TABLA 70

Tabla 71: Ejemplo WiBe – mensajería / groupware [Exchange 5.5 a Contact], pequeña empresa.

En el ejemplo anterior, el valor superior para el soporte externo para Contact, ha sido determinado para las pequeñas empresas. Este valor es para los 20 dias hábiles. Esto significa que el valor neto actual (187) es aun positivo y el proyecto es todavia rentable. El valor neto actual es mayor si se necesita menos soporte externo.

El analisis de riesgos ( la probabilidad de aparición de costes de ahorros y migraciones) puede ser indiferente aquí debido a que el ahorro representa los pagos del importe de las licencias , los cuales serán omitidos en el futuro. Además, el tiempo requerido para la migración fue estimado en el mayor en vez del menor grado en este contexto.

.

EVALUACIÓN DE LA EFICIENCIA ECONOMICA

Ejemplo de migración: mensajeria/software de grupo – agencia publica media

Tabla 72: Ejemplo de migración: mensajeria/software de grupo – agencia publica media

Objeto migración:	Migración de Microsoft Exchange 5.5 al entorno OSS bajo Linux en Samsung Contact, servidores y clientes
Escenario:	Agencia publica media, 1.000 usuarios
Factores de éxito:	Costes de software, costes del cambio
Hipótesis:	Refierase a los ejemplos que tratan de una “agencia publica pequeña”. Más aún: Los costos y la extensión del entrenamiento para la administraación no cambian con el número de usuarios – estos parametros se mantienen sin cambio (cerca del 2x2.000.000€ incluyendo el iva).
Amortización	Sobre la base de las hipótesis hechas, este proyecto es altamente rentable. El proyecto ya se amortiza en el primer año. El factor más importante esta en el ahorro del soporte de Microsoft para la migración interna. En base al analisis de los mejores y peores casos dentro del marco de un valor neto positivo, se obtiene un un rango de entre 10 y 35 dias de soporte externo de Samsung para este proyecto.

EVALUACIÓN DE LA EFICIENCIA ECONOMICA

Table 73: Ejemplo WiBe mensajeria/software de grupo [Exchange 5.5 a Contact], agencia publica media

Mensajeria/software de grupo [Exchange 5.5 -> Samsung Contact] - agencia media

En el ejemplo de más arriba, el valor del limite superior de soporte externo para Contact se determinó para agencias publicas medianas. Este valor es del orden de 34 dias-hombre. Esto significa que el valor neto total actual (1.102) es aún positivo y el proyecto es aún rentable.

Asumiendo que el valor del soporte externo para Contact en las agencias publicas medias sea en un orden realista de un maximo de 5 dias, esto significaría un valor neto presente relativamente muy positivo, lo que indica una muy buena rentabilidad del proyecto.

El analisis de riesgos (posibilidad de que se den ahorros y costos de migración) pueden ser aquí descartados ya que el ahorro representa el pago de los costos de las licencias que serán omitidas en el futuro. Más aún, el tiempo requerido para la migración se estimó, en este contexto, más en el rango alto que en el bajo.EVALUACIÓN DE LA EFICIENCIA ECONOMICA

Ejemplo de migración: mensajeria/software de grupo – agencia publica grande

Tabla 72: Ejemplo de migración: mensajeria/software de grupo – agencia publica grande

Objeto migración:	Migración de Microsoft Exchange 5.5 al entorno OSS bajo Linux en Samsung Contact
Escenario:	Agencia publica grande, 10.000 usuarios
Factores de éxito:	Costes de software, costes del cambio
Hipotesis:	Refierase a los ejemplos que tratan de una “agencia publica pequeña y media”.
Amortización despues de 1 año:	Sobre la base de la hipotesis de unos 6200 usuarios, este proyecto se hace rentable. El valor neto actual se hace negativo cuando aumentan la cantidad de usuarios y/o los dias de soporte externo. El ahorro debido a la no utilización de soporte externo para la migración interna de Microsoft es solo efectiva hasta esa cantidad.

Tabla 75: Ejemplo WiBe - mensajería / groupware [Exchange 5.5 a Contact], agencia pública grande

En el ejemplo de cálculo anterior, se asumieron 17 jornadas laborales de ayuda externa para Contact. Esto significa ahorros de alrededor de 111 jornadas laborales para servicios de Microsoft. Se seleccionó un número de 10.000 usuarios. Este entorno de cálculo lleva a un valor actual neto positivo.

4.8.6.4 Ejemplos de migración según categorías de coste IT

Las suposiciones que se hicieron en el capítulo 4.8.6 son aplicables también a este caso.

Los ejemplos calculados se refieren a los productos mostrados en la tabla de abajo.

Figura 57: Migración por tipos y productos

Un análisis comparativo de las alternativas de migración se realiza en este modelo en base al entorno dado. Una plataforma basada en productos Microsoft sirve de escenario de partida. La migración continuada es la única variante que no produce ningún ahorro real que pudiera ser calculado de este modo. Todas las otras variantes llevan a un cambio completo o parcial en plataforma y por tanto incluyen gastos no realizados que se consideran así como ahorros comparados con la migración continuada.

Los precios y condiciones usados en los cálculos del modelo llevan a un sumidero de liquidez durante el primer año del proyecto. Como los cálculos están basados en precios de adquisición, los ahorros también ocurren durante el primer año solamente.

4.8.6.5	Migración completa

La migración completa significa efectos de ahorros superproporcionales para todos los tipos de agencia pública. En contraste con la migración a Windows 2000, la migración de Windows NT a Linux genera ahorros que exceden del gasto en varias veces.EVALUACIÓN DE LA EFICIENCIA ECONOMICA

Instalación grande

El costo de personal, en union con el del cambio , fueron comparativamente similares, por lo tanto el ahorro por el costo de las licencias es el factor más importante en el ahorro.

Figura 58: Ejemplo del calculo de eficiencia economica de la migración de Windows NT a Linux, agencia publica grande, analisis de costos del proyecto.

El analisis del aprovechamiento de esta variante también nos da un valor actual neto positivo y por lo tanto un resultado provechoso del proyecto.

Fifura 59: Ejemplo del calculo de la eficiencia economica de la migración de Windows NT a Linux, agencia publica grande, analisis del valor neto actualEVALUACIÓN DE LA EFICIENCIA ECONOMICA

Intalación media

El escenario para las agencias publicas medias y pequeñas, es generalmente comparable con el de las agencias publicas grandes. Para este tipo de agencias publicas también se recomienda la migración a Open Software.

Figura 60: Ejemplo del calculo de eficiencia economica de la migración de Windows NT a Linux, agencia publica mediana, analisis de los costos del proyecto

El analisis comparativo de las variantes de la migración muestra también un valor neto actual positivo para este tipo de agencia.EVALUACIÓN DE LA EFICIENCIA ECONOMICA

Figura 61: Ejemplo del calculo de la eficiencia economica de la migración de Windows NT a Linux, agencia publica media, analisis del valor neto actual.

Pequeña instalación

Los ejemplos de agencias publicas medianas y pequeñas también son aplicables en este caso.

Figura 62: Ejemplo del calculo de la eficiencia economica de la migración de Windows NT a Linux, agencia publica pequeña, analisis de costes del proyecto.EVALUACIÓN DE LA EFICIENCIA ECONOMICA

Figura 63: Ejemplo del calculo de eficiencia economica de la migración de Windows NT a Linux, agencia publica pequeña, analisis del valor neto actual

Migración continua

En el caso de este tipo de migración, no se detecta ahorro y por tanto no se puede poner en relieve. Este es el porqué solo se muestran los volumenes de costo.

Los precios de adquisición se asumen una única vez. En paralelo con esto, los resultados se muestran bajo la premisa de pagos anuales de alquiler para versiones de actualización de productos de Windows y de Office.

Los calculos son realizados para instalaciones pequeñas, medianas y grandes.

La versión alquilada es la solución significativamente más cara de todas las variantes analizadas (costes adicionales de 250.000€ para pequeños proyectos de migración, cerca de 1m€ para proyectos medios y un tope de cerca de 10m€ para grandes proyectos de migración). El incremento del costo es solamente causado por las licencias de actualización de software.

Todos los costos de personal que se muestran representan los costos externos de personal.

EVALUACIÓN DE LA EFICIENCIA ECONOMICA

Instalaciones grandes

Figura 64: Ejemplo de calculo de costes de un proyecto, migración de Windows NT a Windows 2000, agencia publica grande

Figura 65: Ejemplo de calculo del coste de proyecto, migración de Windows NT a Windows 2000, agencia publica grande, alternativa: alquiler de Windows/Office

EVALUACIÓN DE EFICACIA ECONÓMICA

Instalación mediana

Figura 66: Ejemplo de cálculo del costo del proyecto, migración desde Windows NT a Windows 2000, agencia pública mediana.

Figura 67: Ejemplo de cálculo del costo del proyecto, migración desde Windows NT a Windows 2000, agencia pública mediana, alternativa: alquiler de Windows/Office.

Versión: 29.08.2003 Página 325

EVALUACIÓN DE EFICACIA ECONÓMICA

Instalación pequeña

Figura 68: Ejemplo de cálculo del costo del proyecto, migración desde Windows NT a Windows 2000, agencia pública pequeña.

Figura 69: Ejemplo de cálculo del costo del proyecto, migración desde Windows NT a Windows 2000, agencia pública pequeña, alternativa: alquiler de Windows/Office.

Página 326 Versión: 29.08.2003

EVALUACIÓN DE EFICACIA ECONÓMICA

4.8.6.7 Migración parcial

Migración selectiva

Figura 70: Ejemplo del cálculo del costo del proyecto, migración desde Exchange 5.5 a Samsung Contact, agencia pública grande.

Figura 71: Ejemplo del cálculo del costo del proyecto, migración desde Exchange 5.5 a Samsung Contact, agencia pública mediana.

Versión: 29.08.2003 Página 327

Evaluación de eficacia económica

Figura 72: Ejemplo de cálculo del costo del proyecto, migración desde Exchange 5.5 a Samsung Contact, agencia pública pequeña.

Migración parcial del servidor

Figura 73: Ejemplo de cálculo del coste del proyecto, migración desde Windows NT a Linux del servidor, agencia pública grande.

Página 328 Versión: 29.08.2003

EVALUACIÓN DE EFICACIA ECONÓMICA

Figura 74: Ejemplo del cálculo del coste del proyecto, migración desde Windows NT a Linux del servidor, agencia pública mediana.

Figura 75: Ejemplo de cálculo del coste del proyecto, migración desde Windows NT a Linux del servidor, agencia pública pequeña.

4.9 Ejemplo de evaluación de urgencia y calidad/estrategia

El ejemplo de evaluación incluye el cálculo de urgencia, D, y de los factores calidad/estrategia, Q, de acuerdo al IT-WiBe 21 (recomendaciones sobre tasación de la eficacia económica para sistemas IT). Considera la situación de las agencias públicas

Versión: 29.08.2003 Página 329

Evaluación de eficacia económica

en general y representa una estimación aproximada de la discusión actual concerniente a la evaluación de sistemas heredados. Las ventajas y desventajas que conducen a diferentes clasificaciones son resumidas en términos generales. La descripción está enfocada hacia los grados de consecución de los objetivos de acuerdo al catálogo de criterios.

El ejemplo de evaluación para la urgencia de los proyectos de migración da un valor de > 59 <. Los proyectos son generalmente soportados desde ésta perspectiva.

El ejemplo de evaluación calidad/estrategia de proyectos de migración da un valor de > 66 <. Eso significa que los proyectos tienen sentido bajo esos aspectos también.

Criterios de Urgencia

Estos criterios (grupo 3 del catálogo de criterios) se refieren a la urgencia en reemplazar un sistema existente, por un lado, y al cumplimiento de reglas y leyes administrativas por el otro.

4.9.2 Criterios de calidad/estrategia

El grupo 4 del catálogo de criterios contiene los criterios de calidad y estrategia de los proyectos IT. Estos se refieren a la prioridad de un proyecto IT, a las mejoras de calidad interna dentro de las agencias públicas y a las repercusiones sobre empleados y “clientes” de las administraciones públicas (orientación ciudadana) así como la disponibilidad general en el mercado de software y seguridad IT. La plausibilidad estratégica de un proyecto IT dado es verificada contra los criterios. Eso significa que el sistema heredado desaparece del foco de atención, y que el proyecto IT tiene que ser verificado en base a los factores referidos por los criterios.

4.9.3 Análisis de beneficios

Los criterios para urgencia y calidad/estrategia no pueden ser cuantificados en términos monetarios. En su lugar, forman parte de un análisis de beneficios. Eso requiere una descripción cualitativa de las repercusiones de dichos criterios. Esa descripción, por su parte, debe ser traducida a una puntuación para cada uno de los criterios. Una escala de 0 a 10 está disponible para ése propósito. Los puntos son multiplicados por el factor de ponderación aplicable y sumado para los grupos de criterios individuales.

Un valor mayor que 50 significa que un proyecto IT puede ser clasificado como “recomendado para su implementación” con respecto al área analizada.

Página 330 Versión: 29.08.2003

EVALUACIÓN DE EFICIENCIA ECONÓMICA

Figura 76: Modelo de evaluación para urgencia y calidad en proyectos de migración.

Tabla 76: Ejemplo: análisis de beneficios para factores de de urgencia.

Versión: 29.08.2003 Página 331Evaluación de la eficiencia económica

WiBe Item	Criterio / explicación	Factores de peso /puntos
3	Factores de urgencia	

	...errores del sistema. Soporte de nuevas característiscas, como USB, etc. no se aseguran.	

3.1 3.1.2 3.1.2.1	Urgencia por reemplazar un sistema obsoleto. Estabilidad del sistema obsoleto. Bugs, errores y tiempo de inactividad: La susceptibilidad a errores del sistema obsoleto todavía tiene límites tolerables. La introducción de nuevas herramientas administrativas aumentará la susceptibilidad a errores pues los desarrolladores software utilizan nuevas librerías que para integrarlas en la arquitectura Windows NT tienen problemas.	G 20 P 7

3.1 3.1.2 3.1.2.2	Urgencia por reemplazar un sistema obsoleto. Estabilidad del sistema obsoleto. Problemas de servicio, cuellos de botella en el personal El soporte externo para el soporte del sistema, caerá incluso más en el futuro debido a que el fabricante no asegurará por más tiempo este tipo de soporte y porque el fabricante ya habrá dado el salto a una segunda generación de productos para una nueva plataforma de sistemas operativos.	G 20 P 4

3.1 3.1.3 3.1.3.1	Urgencia por reemplazar un sistema obsoleto. Flexibilidad del sistema obsoleto. Límites de expansión / actualización La implementación de actualizaciones en funcionalidades, como por ejemplo USB, etc. no se asegurará más. Las herramientas que soporten la interoperabilidad con el nuevo sistema no serán ampliadas. Cambiar la arquitectura implica que los problemas de compatibilidad con otros sistemas aumentarán en un futuro próximo.	G 10 P 8

3.1 3.1.3 3.1.3.2	Urgencia por reemplazar un sistema obsoleto. Flexibilidad del sistema obsoleto. Interoperabilidad, problemas presentes y futuros de las interfaces. La adaptación de un sistema obsoleto a las necesidades actuales se convierte en una tarea difícil.	G 10 P 9

3.1 3.1.3 3.1.3.3	Urgencia por reemplazar un sistema obsoleto. Flexibilidad del sistema obsoleto. Enemigos del usuario Afecta poco al presente.	G 10 P 3

Tabla 77: Ejemplo: análisis del beneficio para factores de calidad / estratégicos.

WiBe Item	Criterio / explicación	Factores de peso /puntos
4	Factores de calidad / estratégicos	

4.1 4.1.2	Prioridad del proyecto tecnológico. Integración en el terreno tecnológico de la administración federal en general: Las especificaciones emitidas por la agencia coordinadora y consejera del gobierno general para la información tecnológica en la administración federal (KBSt) con respecto al uso de proyectos de software libre con vistas a la implementación de un entorno real considerando todas las facetas relevantes (administración, conversión de ficheros, etc.) únicamente puede ser implementada condicionalmente utilizando los productos dados y sus dependencias.	G 5 P 5

4.1 4.1.3	Prioridad del proyecto tecnológico. Efecto de seguimiento mediante redes de comunicación En contraposición a la situación actual, se crearía una base ideal de comunicación dentro del marco de orientación hacia el uso de los productos OSS con el fin de simplificar la comunicación entre diferentes agencias públicas.	G 10 P 7

4.1 4.1.5	Prioridad del proyecto tecnológico. Independencia del fabricante Considerando la estructura heterogénea de la que se componen los productos OSS y los productos Microsoft, se espera alcanzar un alto grado de independencia del fabricante utilizando un decidido enfoque hacia el uso de productos OSS.	G 20 P 8

4.4 4.4.1	Efectos relacionados con el personal laboral. Atractivo de las condiciones de trabajo. Tendrán que considerarse dos efectos por separado en este contexto: En el área administrativa, el esfuerzo adicional debido al incremento significante de las actividades demandadas resultantes del uso de productos OSS, claramente extenderá las cualificaciones personales del perfil del trabajador. En el área de los usuarios , se espera que dichas soluciones posibiliten una simplificación de las capacidades de intercomunicación de los procesos, que en la actualidad a veces se encuentra muy limitada por la oferta de productos dentro del campo de la ofimática.	G 5 P 6

WiBe Item	Criterio / explicación	Factores de peso /puntos
4	Factores de calidad / estratégicos	

4.4 4.4.2	Efectos relacionados con el personal de trabajo. Incrementar / expandir sus cualidades. Los efectos que recaen sobre el incremento de cualidades pueden perfectamente esperarse en un futuro. En el área administrativa, estos efectos resultan de una cartera de tareas mucho más interesantes y de entrenar. En el área de los usuarios, estos efectos resultan de un conocimiento adquirido debido al uso de distintos sistemas ofimáticos.	G 2 P 3

4.4 4.4.3	Efectos relacionados con el personal de trabajo. Divulgación / disponibilidad de entrenamiento. No existen problemas desde el punto de vista del entrenamiento y experiencia requeridos para el uso de sistemas que actualmente están implantados. Sin embargo, dado el incremento de demanda de productos OSS, a lo mejor resulta ser un poco más difícil encontrar personal bien calificado. Sin embargo, desde el momento en que se considera que el personal está preparado adecuadamente , este efecto puede ser rechazado a término medio en cuanto a administración se refiere.	G 3 P 2

4.5 4.5.4	Efectos relacionados con orientación ciudadana. Mejora de la imagen Los proyectos de migración también están diseñados para integrar el día a día entre los heterogéneos mundos del servidor y del cliente. La transición gradual a un entorno OSS permite que la migración sea un mecanismo suave y a la vez servirá como demostración de que el proyecto político de introducir OSS puede ser perfectamente implementable. A medio y largo plazo, el sector administrativo y los ciudadanos se beneficiarán del valor añadido que resulta del proyecto de migración.	G 2 P 6

4.6 4.6.1	Divulgación / disponibilidad del software Penetración en el mercado. Los productos que se utilizarán estarán disponibles en el mercado sin problemas.	G 5 P 7

4.6 4.6.2	Divulgación / disponibilidad del software Soporte independiente No solo los fabricantes, sino que numerosas compañías independientes ofrecen soporte para los productos que se utilizarán.	G 5 P 6

WiBe Item	Criterio / explicación	Factores de peso /puntos
4	Factores de calidad / estratégicos	

4.6 4.6.3	Divulgación / disponibilidad del software Disponibilidad de certificación software Existen tanto referencias relevantes como certificados para los productos que se usen.	G 5 P 5

4.6 4.6.4	Divulgación / disponibilidad del software Disponibilidad de herramientas administrativas para el software. Existen una amplia gama de herramientas administrativas.	G 5 P 5

4.7 4.7.1	Seguridad tecnológica Seguridad en comunicaciones La comunicación tanto con vecinos internos como externos se garantiza.	G 6 P 7

4.7 4.7.2	Seguridad tecnológica Aplicación seguro / seguridad Las aplicaciones son muy desarrolladas y estudiadas (maduras).	G 6 P 6

4.7 4.7.3	Seguridad tecnológica Fallo en seguridad Los sistemas que tienden a usarse cada vez son más seguros contra fallos.	G 6 P 7

4.7 4.7.4	Seguridad tecnológica Administración de seguridad Los sistemas que tienden a usarse incluyen mecanismos de seguridad que son documentados y que pueden estar al alcance de todos aquellos que les interese.	G 6 P 7

4.7 4.7.5	Seguridad tecnológica Inversión y planificación en seguridad La inversión que debe hacerse es segura. Los productos permanecerán en el futuro durante un periodo de 5 años para las agencias públicas. Los sistemas que se usen son estables y los procesos basados en dichos sistemas pueden ser planificados con seguridad.	G 6 P 8

5 Recomendaciones para la migración

5.1 Afirmaciones de tipo general

5.1.1 El proceso de toma de decisiones

Los resultados de una evaluación de eficiencia económica con una perspectiva a largo plazo son cruciales para lograr una recomendación favorable a la migración o a su desarrollo. Incluso aunque la migración completa o parcial se puede llevar a cabo sin restricciones desde el punto de vista técnico, las consideraciones económicas podrían sugerir que una migración no tiene mucho sentido dadas las condiciones actuales. A la vista de las diferentes relaciones e interacciones entre componentes independientes y sistemas de cada infraestructura con el mundo de las aplicaciones, una valoración a largo plazo siempre ha de ser parte del proceso de toma de decisiones. En este contexto, el análisis desde el punto de vista de la introducción del software de código abierto no será muy diferente de los análisis de evaluación habituales en el ámbito de las TI, por ejemplo, en cuanto a la concentración (consolidación) de hardware o software. Los siguientes aspectos suelen formar parte de las estrategias tanto de administraciones públicas como de empresas:

Sistemas y plataformas de aplicaciones integradas mediante especificaciones y estándares abiertos, si fuera necesario incluso con la ayuda de productos de integración dedicados.

Sistemas y plataformas de aplicaciones integradas mediante interfaces y especificaciones propietarias de fabricantes (no publicadas o publicadas parcialmente), si fuera necesario incluso con la ayuda de productos de integración específicos de fabricantes.

Uso (histórico) de soluciones independientes para métodos y aplicaciones selectivos especializados.

Dado que el software abierto suele asociarse, por su origen, con el uso de estándares abiertos, constituye otra variante en este campo:

Sistemas y plataforma de aplicaciones integrados en función de especificaciones y estándares abiertos utilizando código abierto (reutilizable).

Si bien una decisión a favor de la introducción selectiva de un producto de código abierto muy utilizado, como el servidor web Apache, suele conseguirse de forma muy pragmática y rápida, la decisión a favor de la introducción generalizada de software de código abierto y la sustitución de islas propietarias requiere un enfoque metódico por su repercusión a largo plazo. Los puntos clave de un enfoque semejante son los siguientes:

Desarrollo de una estrategia global de TI, teniendo en cuenta los objetivos financieros, organizativos, de innovación y personales.

Definición del futuro estratégico de la plataforma de código abierto, teniendo en cuenta los cálculos de la eficiencia económica a largo plazo, sin dejar de lado el uso de

RECOMENDACIONES PARA LA MIGRACIÓN

Versión: 29.08.2003 Página 337

productos estándar tanto gratuitos como comerciales (consulte la sección 5.2.1, modelo de software abierto frente al modelo de software comercial para Linux)

Identificación en el anteproyecto de todos los estándares necesarios para garantizar la posibilidad de reutilización tanto interna como externa, así como la interoperatividad

Selección de los productos que cumplan los requisitos

Definición del proyecto, incluido el cronograma correspondiente, la lista de actuaciones, así como la garatía de respetar el presupuesto

Como se puede apreciar en la siguiente ilustración, los métodos y herramientas utilizadas ya en las administraciones públicas se pueden utilizar para las diferentes fases.

Estrategia Plataforma Estándares Productos Proyectos

Estrategia de TIC

CTP

SAGA

WiBe‘21 Vd

lGuía de migración

Figura 77: Toma de decisiones para la introducción de software abierto

Recomendaciones generales

A la vista de las diferentes situaciones de partida (incluidas las soluciones aisladas), por lo general hacer afirmaciones válidas relativas a las ventajas económicas de las estrategias de plataforma sólo es posible en contadas ocasiones. No obstante, se puede decir en general que la eficiencia económica aumenta en función del grado de integración de los productos de una plataforma. Esto se debe a varias razones:

Mayor productividad en el caso de productos correctamente integrados (sin inconsistencias del sistema)

Mayores posibilidades de reutilización de componentes y soluciones que fueron desarrollados sobre la base de las mismas tecnologías intermedias

Ahorro debido a procesos estandarizados de adquisición y mantenimiento, así como acuerdos de asistencia técnica en caso de ser necesarios.

Además, un mayor nivel de estandarización sobre la base de estándares abiertos también impulsa la eficiencia económica en conjunto. Esto se debe a diversas razones que comentamos a continuación:

Provoca la competencia entre productos y soluciones

Reduce la dependencia de los fabricantes

Generalmente se amplían los mercados de servicios

Recomendaciones para la migración

Página 338 Versión: 28.09.2003

En concreto (si bien no únicamente), la adopción de SAGA (estándares y arquitecturas para aplicaciones de e-gobierno o Standards and Architectures for e-government Applications) y de sistemas de estandarización interna en el seno de las administraciones públicas han aumentado la seguridad en la inversión para proveedores comerciales de software basado en Linux. Esto se refleja en el número creciente de proveedores de componentes básicos y métodos especializados, que han creado una situación en la que ya es posible efectuar una migración completa, algo que hasta hace poco tiempo era difícil.

Partiendo de esta base, se pueden hacer las siguientes recomendaciones generales para el uso de productos de código abierto.

Adoptar la eficiencia económica como objetivo general de toda la estrategia de TI, teniendo en cuenta adecuadamente los factores de innovación y organización

Usar el sistema operativo Linux como base de la plataforma de TI en todos los campos de aplicación siempre que los requisitos para la migración total o parcial se cumplan (consulte las secciones 5.2 y 5.4)

Usar estándares abiertos, que cuentan con el reconocimiento tanto de la industria de las TI como de la comunidad de código abierto, como base para la selección e integración de productos de software mediante los que evitar casos de dependencia excesiva de un fabricante

Implantación de una evaluación de proyectos en función de la eficiencia económica a fin de colaborar en la toma de decisiones en el uso de productos gratuitos y comerciales basados en Linux (consulte el capítulo 4)

La migración a la plataforma de software de código abierto o a software comercial para Linux puede en general resultar lo más razonable desde el punto de vista económico (más provechoso) en comparación con una migración continua a las nuevas versiones de Microsoft.

La omisión o reducción de costes por licencia puede conducir a un ahorro directo (económico), por ejemplo en los siguientes casos:

La migración parcial de servidores, gracias a la abundancia de conocimientos acerca de hardware y software UNIX, más los sistemas UNIX ya es posible

La sustitución selectiva de miembros de la antigua familia de gestión (hoy en día: .NET Enterprise Server), como Exchange o SQL Server, especialmente en casos de numerosos usuarios y, por lo tanto, licencias

La migración parcial de productos de Office de MS en los clientes a menos que el uso de Office como entorno de ejecución de macros o aplicaciones impida la sustitución

En muchas otras situaciones de aplicación, la dimensión estratégica ha de tenerse en cuenta para valorar correctamente el posible ahorro. El capítulo titulado "Evaluación de eficiencia económica" trata esta dimensión estratégica en profundidad.

En cualquiera de los casos ha de tenerse en cuenta el coste de formación como aspecto económico, tanto en la migración de plataformas actuales a Linux como a un nuevo nivel de Microsoft.

RECOMENDACIONES PARA LA MIGRACIÓN

Versión: 29.08.2003 Página 339

Dado que tales costes forman parte de un análisis realista de ambos casos, se puede considerar que este segmento del coste es prácticamente neutral en la comparación de las alternativas. Además, los costes de adaptar aplicaciones especializadas existentes también ha de tenerse en cuenta en ambos casos, esto es: para las dos alternativas191.

Ya que las recomendaciones generales no pueden tratar los requisitos y marcos de referencia de una situación de partida concreta, se optará por hacer más recomendaciones en cuanto a las diferentes situaciones. La sección 5.2 trata el caso de una migración completa, la 5.3 examina la situación en que las diversas plataformas quedan estables, y la sección 5.4 analiza un entorno híbrido (migración parcial).

5.2 Migración de tipo "sustitución total"

La migración completa como se ha definido en esta guía consiste en introducir Linux como sistema operativo en todos los componentes de la infraestructura de TIC. Una sustitución completa de sistemas operativos también suele implicar la sustitución con productos compatibles con

SAGA a nivel de integración y aplicación porque los productos necesarios, en concreto Java, aún no han alcanzado el grado de difusión esperada192.

Dos variantes de software que suelen combinarse suelen estar, por regla general, disponibles para realizar una migración completa:

SCA: software de código abierto (o software libre)193: software de código abierto y gratuito desarrollado por la comunidad de código abierto

SCOL: software comercial para Linux: software comercial, de código abierto o propietario para Linux ofrecido por desarrolladores de software.

Dado que muchas áreas de la administración pública emplean de forma intensiva aplicaciones especializadas basadas en Windows y desarrolladas por las propias administraciones, así como sistemas de aplicaciones basados en ERP, es de suponer que el software de código abierto cumplirá todos los requisitos en el área de infraestructuras únicamente en un futuro próximo. A la vista de la positiva promoción de Linux gracias a la disponibilidad de grandes sistemas de aplicaciones de fabricantes como SAP y Oracle, el uso de software comercial y el creciente número de programas para Linux pueden verse como una evolución positiva para el mayor desarrollo de la plataforma de código abierto, lo que conducirá a un apogeo mayor en el avance de esta plataforma.

191 El análisis de este segmento de coste no consta entre los objetivos de esta guía. Suele requerir análisis muy específicos en los diferentes organismos públicos afectados, una tarea que no puede llevarse a cabo en una guía de migración. Los aspectos correspondientes al marco de una evaluación de eficiencia económica pueden variar en cada caso si los costes de migración determinados para aplicaciones especializadas se incluyen en el análisis.

192 En este caso, las aplicaciones web del modelo (L)AMP, que también se utilizan muy frecuentemente en Windows, no se ven afectadas por la necesidad de una migración.

193 Consulte la definición en el capítulo 2.

Recomendaciones para la migración

Página 340 Versión: 28.09.2003

Las características específicas de las arquitecturas de software y de sistemas posibles y recomendadas pueden variar en función del tamaño, la intensidad de la TIC y el grado de especialización del organismo público. Las posibilidades de ampliación y disponibilidad de los componentes concretos por un lado, y la información necesaria para la introducción por el otro, desempeñan un papel decisivo en este contexto.

Esta es la razón por la que los aspectos concretos se tratan por separado, por ejemplo: para organismos grandes y medianos, además de los especializados y los más pequeños. A modo de introducción, vamos a tratar un modelo general y por tanto genérico para tareas de infraestructuras.

5.2.1 Modelo de arquitectura

Suponiendo un uso consistente de Linux como plataforma para aplicaciones de cliente y servidor, se pueden distinguir dos tipos de arquitecturas para clientes análogas a las habituales de UNIX y Windows: clientes completos y tontos.

Estación de trabajo cliente

Aplicación de oficina

StarOffice

OpenOffice. Org

Máquina virtual Java KDE/GNOME

Aplicaciones Java

Servidor de infraestructuras

Servidor de archivos e impresión

Servido DNS y DHCP

Servidor de directorios

Servidor web Correo y calendarios

Servidor de aplicaciones J2EE

Servidor DBMS

Servidor DBMS

Arquitectura en

l

Linux

Linux Linux

Linux

K - Mail

y Mozilla Conqueror

Servidor de aplicaciones

Componentes aptos para aplicaciones generales

con requisitos específicos

Figura 78: Arquitectura del sistema con un cliente completo basado en Linux

La configuración que aparece en la arquitectura de la Figura 78 con un cliente completo basado en Linux es representativa de estaciones de trabajo con capacidad multifunción en una infraestructura distribuida con equipos personales disponibles comercialmente (cliente completo). La plataforma de servidor se encarga de las funciones de infraestructura habituales, y un servidor de aplicaciones completa el equipamiento para conformar una arquitectura de 3 capas.

RECOMENDACIONES PARA LA MIGRACIÓN

Versión: 29.08.2003 Página 341

Los componentes seleccionados cubren diversas aplicaciones, incluidas por ejemplo las siguientes:

Estaciones de trabajo (personales y de oficina)

Programas de trabajo en grupo (servidor de correo calendarios)

Sistemas de bases de datos (servidor DBMS)

Servidor web

Servidor de archivos

Servidor de impresión

Servicios de autenticación

Servicios de red (entre ellos, pero no únicamente: servidor DNS y DHCP).

Las áreas entramadas de la Figura 78 se pueden utilizar independientemente del tamaño y nivel de especialización del organismo público. El resto de los componentes del sistema serán tratados en las siguientes secciones en el contexto de sus diferentes situaciones de aplicación, a saber:

Organismos públicos grandes y medianos

Organismos públicos especializados con servicios de TIC

Organismos públicos pequeños

Nota: generalmente se han de tener en cuenta ciertas restricciones relacionadas con las situaciones de migración analizados en este documento.

El análisis técnico demuestra que, con algunas excepciones, hay disponibles algunas soluciones alternativas procedentes del ámbito del software de código abierto y/o comercial capaces de sustituir los productos de Microsoft que forman parte de la situación de partida supuesta en este documento (consulte el capítulo 2.2.1). Los puntos clave son:

La compatibilidad entre OpenOffice.org/StarOffice y MS Office no es total. Esto afecta especialmente a los usuarios que habitualmente tienen que crear documentos en colaboración con otros. Cuando se utilizan diferentes variantes de Office, se suelen encontrar problemas de formato.

El motor de gráficas de OpenOffice.org y StarOffice no es tan potente como el de Excel de MS. Esto es especialmente cierto a la hora de crear gráficas Pivot.

Aún no hay disponible una alternativa adecuada a ciertos productos, como Project o Visio de MS.

No obstante, una migración de productos de Microsoft a soluciones de software de código abierto y software comercial para Linux puede evitarse más por razones económicas que funcionales. Esto afecta especialmente a la migración de los sistemas personales.

Office de MS

La funcionalidad y complejidad de las macros, scripts, plantillas y documentos

Recomendaciones para la migración

Página 342 Versión: 28.09.2003

puede suponer que la migración a OpenOffice.org o StarOffice no sea económica.

Office Professional de MS

Existe un problema de versiones análogo en el caso de Access de MS y las aplicaciones relacionadas que se suelen utilizar para procesos sencillos de automatización.

Aplicaciones especializadas

Dependiendo del grado de uso de aplicaciones especializadas nativas de Windows, una migración total puede, en el peor de los casos, evitarse hasta que estén disponibles productos alternativos (consulte el capítulo 5.3). Esto también es aplicable a las aplicaciones creadas sobre la base de Exchange de MS y que lo utilizan como entorno de ejecución.

5.2.1.1 Estaciones de trabajo

El funcionamiento de las estaciones de trabajo se basa en Linux. A día de hoy no es posible recomendar una distribución concreta. La decisión depende de las circunstancias de cada caso y de los requisitos específicos del organismo público en cuestión. Tanto OpenOffice como StarOffice pueden recomendarse en el ámbito de la oficina. La decisión a favor de un producto o el otro depende de los requisitos específicos del organismo público en cuestión. Igual que Office de Microsoft, StarOffice y OpenOffice incluyen las aplicaciones necesarias para el trabajo cotidiano(tratamiento de texto, análisis de hojas de cálculo, presentaciones...) y satisfacen todos los requisitos funcionales. Para la suite StarOffice, disponible como producto comercial, Sun ha desarrollado y/o añadido componentes de ampliación (fuentes truetype, un corrector ortográfico propio, plantillas adicionales, una galería de imágenes y la base de datos ADABAS). OpenOffice.org, por el contrario, es parte de la familia del software de código abierto gratuito y está disponible gratuitamente. Las diferencias funcionales y técnicas entre ambos paquetes de oficina son mínimas.

El sistema de escritorio es otra interfaz de usuario importante. Entre las distribuciones de Linux, suelen implantarse clientes completos para usuarios que, como en el caso de Windows, cubren las aplicaciones más importantes. KDE y GNOME son los dos representantes más importantes del sistema de escritorio. La selección del sistema de escritorio concreto es una cuestión de gustos personales y las preferencias del usuario para ciertas aplicaciones.

5.2.1.2 Servidor web

El servidor web Apache (consulte también el capítulo 3.11.4) se considera en estos momentos la vara de medir servicios de Internet e intranet. Su flexibilidad, gracias a su diseño modular y al gran número de módulos disponibles, ha convertido al servidor web Apache en líder del mercado de servidores web. Las prestaciones de este componente incluyen sus largos años de funcionamiento en grandes entornos de producción, sus completas funciones de seguridad y la posibilidad de elegir entre una amplia oferta de soporte profesional.

RECOMENDACIONES PARA LA MIGRACIÓN

Versión: 29.08.2003 Página 343

5.2.1.3 Sistema de archivos

Para servicios de archivos basados en entornos Linux se recomienda el veterano sistema de archivos en red o Network File System (NFS). NFS se utiliza tradicionalmente como sistema de archivos para trabajo en redes UNIX. NFS es el protocolo estándar cuando diferentes sistemas UNIX han de compartir directorios. Los usuarios pueden acceder a las áreas de directorios que necesiten a través de servidores centrales o distribuidos. Los árboles de directorio exportados se enlazan automáticamente con la estación de trabajo correspondiente.

Los sistemas de archivos XFS y EXT3 se recomiendan para el almacenamiento físico de datos en sistemas de discos de los servidores reales. Ambos sistemas son compatibles con las funciones de registro de archivos, de cuotas y de asignación de permisos de acceso a archivos y directorios.

5.2.1.4 Servicios de impresión

El sistema de impresión de UNIX o "Common UNIX Printing System" (CUPS) es el único sistema recomendado para la puesta en marcha de servicios de impresión. CUPS se ha establecido en prácticamente todos los sistemas UNIX y constituye el estándar de facto de las distribuciones más importantes (SuSE, Debian, RedHat, etc.). El servicio de impresión CUPS ofrece todas las funciones necesarias para proveer de una infraestructura de impresión. Admite un gran número de dispositivos de impresión diferentes y es capaz de poner a disposición de cada usuario sus opciones de impresión específicas. CUPS está basado en el protocolo de impresión de Internet o Internet Printing Protocol, el nuevo estándar definido para imprimir tanto con dispositivos locales como en redes de área local (LAN) y en redes de área amplia (WAN, Internet...).

5.2.1.5 Servicios de red

Por su origen UNIX, los servicios que constituyen la infraestructura de red basada en TCP/IP constituyen, por defecto, una parte integral del software de código abierto. BIND (dominio de nombres de Internet de Berkeley o Berkeley Internet Name Domain) se recomienda como una implantación de referencia para establecer sistemas de nombres de dominio. En cuanto al DHCP, consulte también la implantación de referencia del Internet Software Consortium.

5.2.2 Organismos públicos medianos y grandes

Los organismos públicos medianos y grandes presentan arquitecturas de TIC especiales, y las recomendaciones para la migración de ciertas aplicaciones pueden diferir de las correspondientes a administraciones más pequeñas. Hasta un determinado tamaño, los organismos públicos suelen trabajar tanto en arquitecturas de TIC distribuidas como centralizadas. Las distribuidas se suelen emplear para trabajos centralizados (ERP, análisis de costes y resultados) en administraciones públicas. Los componentes del sistema concretos que conforman la base para la implementación de procesos centralizados han de cumplir requisitos especialmente exigentes, con vistas a la seguridad, el rendimiento y las posibilidades de ampliación de su infraestructura informática. Los estándares de calidad definidos internamente requieren un alto nivel de disponibilidad y exigen servicios de soporte completo tanto para componentes clave como para usuarios. Esto obliga al uso intensivo de plataformas de gestión, especialmente para el control de redes y sistemas. En áreas de organismos públicos, las arquitecturas distribuidas se encuentran fundamentalmente en entornos de comunicación de oficinas, tratamiento de texto y edición, y aplicaciones especiales. Por ejemplo, las bases de datos distribuidas, los sistemas de correo y los de archivos se emplean sobre todo en niveles de departamento.

Recomendaciones para la migración

Página 344 Versión: 28.09.2003

Los sistemas distribuidos requieren mecanismos especiales de réplicas y de administración distribuida de sistemas.

Además de los componentes mencionados en el capítulo 5.2.1, aquellos que están especialmente adaptados a los requisitos concretos de grandes entornos suelen recomendarse en la implantación de requisitos técnicos y arqutectónicos específicos. En cuanto a las recomendaciones de evaluación de eficiencia económica en el caso de migración total en organismos públicos grandes y medianos, consulte los capítulos 4.6.1 y 4.8.6.5.

Cliente Linux

Aplicación de oficina

StarOffice

OpenOffice. org

Máquina virtual Java

KDE/ GNOME

Aplicaciones Java

Servidor Linux

Servidores de archivos e impresión

Servidor DNS y DHCP

OpenLDAP

(SUN ONE)

Apache

Samsung

Contact

Servidor de aplicaciones J2EE

BD SAP

(Oracle / DB2)

Servidor DBMS

Arquitectura en general

Linux

Linux Linux

Linux

K - Mail

Mozilla

Conqueror

Servidor de aplicaciones

Componentes aptos para uso general

Componentes relacionados con requisitos

Figura 79: Arquitectura de TIC recomendada para organismos públicos en caso de "migraciones totales"

5.2.2.1 Sistemas de gestión de bases de datos

Los requisitos concernientes a sistemas de gestión de bases de datos en grandes arquitecturas de TIC centralizadas difieren, en concreto, en que se pretende aumentar la estabilidad, el rendimiento y la seguridad.

De entre los sistemas de bases de datos de código abierto, la base de datos SAP se recomienda de cara a los requisitos de administraciones grandes. La base de datos SAP también puede adquirirse a SAP (consulte también el capítulo 3.13.4) en formato de plataforma certificada para el sistema R/3

y sus sucesores, y se utiliza como tecnología clave en los propios productos de SAP. Las funciones incluyen no sólo el soporte para transacciones, sino que también impulsan y albergan procedimientos.

RECOMENDACIONES PARA LA MIGRACIÓN

Versión: 29.08.2003 Página 345

En caso de que se necesiten funciones más completan y/o adicionales, también se recomienda el uso de productos comerciales estándar para Linux (SCOL).

Los productos estándar para Linux forman parte hoy día de la oferta de numerosos desarrolladores. Un ejemplo serían los productos de IBM (DB2) y Oracle.

5.2.2.2 Programas de trabajo en grupo

Samsung Contact (un producto SCOL) es una solución de trabajo en grupo basada en Linux con buenas posibilidades de ampliación en entornos grandes. Gracias a su arquitectura, que comprende varios componentes independientes, concebida como ampliación horizontal, el sistema también se puede distribuir en varios servidores. Samsung Contact es un producto muy correcto que satisface las necesidades especiales de los entornos grandes. Samsung Contact

no sólo admite su instalación en un único servidor, sino que también se pueden efectuar instalaciones distribuidas en diversas ubicaciones, por lo que ofrece una solución ampliable incluso en locales descentralizados.

5.2.2.3 Servicios de directorio

Por su papel clave a la hora de garantizar la eficiencia de la gestión de sistemas y la seguridad de las TIC, los servicios de directorio desempeñan un papel fundamental en la integración de aplicaciones y sistemas en plataformas.

Con la importancia cada vez mayor que están cobrando los servicios de autenticación en aplicaciones web y por los requisitos cada vez más exigentes en cuanto a transparencia de las operaciones de autenticación, el modelo de directorios (los servicios de directorio) y metadirectorios ya conocido desde hace tiempo se ha visto completado por componentes y desarrollos que nos dirigen hacia un sistema general conocido a menudo como gestor de identidades (consulte también la ilustración siguiente).

Figura 80: Campos de aplicación de servicios de directorio basados en el ejemplo de la plataforma SunOne

Tanto los productos de software de código abierto gratuito como los de software comercial para Linux se pueden utilizar por regla general en la implantación de servicios de directorio.

Como veremos a continuación, en este contexto se pueden dar dos situaciones fundamentales:

1. Implantación de funciones básicas para aplicaciones de autenticación, así como para la gestión profesional basada en el protocolo LDAP.

Recomendaciones para la migración

Página 346 Versión: 28.09.2003

En este caso, la alternativa de software de código abierto OpenLDAP se considera habitualmente suficiente y económica.

2. Implantación de funciones ampliadas para mejorar la eficiencia en la gestión, por ejemplo, sincronizando los datos de autenticación de los usuarios en diversas aplicaciones.

Por lo general se puede asumir en estos casos que el uso de productos comerciales conllevará ventajas en comparación con desarrollos propios para la evaluación de la eficiencia económica

5.2.2.4 Servicios de gestión de sistemas

A la vista de los requisitos cada vez más exigentes en la gestión de sistemas, el uso de los productos de gestión Tivoli u OpenView habría de tenerse en cuenta. Además de las soluciones comerciales mencionadas anteriormente, se pueden emplear otras posibilidades de gestión mediante herramientas del sistema operativo en ciertas tareas (consulte el capítulo 3.6).

5.2.3 Organismos públicos especializados con servicios de TIC

Los organismos públicos que también actúen como proveedores de servicios de TIC especializados en el seno de la administración pública suelen trabajar con arquitecturas de TIC fuertemente centralizadas.

Suelen ofrecer sus servicios como centros de datos y sistemas, y proporcionan servicios de TIC a otras administraciones, por ejemplo como "proveedores de servicios de aplicación" (PSA). Las arquitecturas centralizadas habituales empleadas para la implantación de diferentes procesos especiales (por ejemplo ERP) tienen a menudo requisitos muy exigentes en términos de rendimiento y posibilidades de ampliación de los sistemas. Por esto los sistemas de hardware empleados son de buena calidad y a veces incluso de alto nivel, aptos para el funcionamiento en centros informáticos automatizados, como redes de área de almacenamiento (SAN) en los que se realizan copias de seguridad de los datos y archivos con los mismos. Estos departamentos especializados exigen el máximo a la seguridad, rendimiento y posibilidades de ampliación de sus infraestructuras de TIC.

Los estándares de calidad definidos en estos entornos suelen ser parte del acuerdo firmado entre el organismo y el proveedor, y se estipulan sistemas de alta disponibilidad y soporte completo para los usuarios. En estos casos se utilizan plataformas de gestión de sistemas con un alto grado de automatización, con lo que se garantiza un uso efectivo de la gestión del sistema. Además, los centros informáticos requieren soporte de sistemas de primer y segundo nivel efectivo, incluidas prestaciones de gestión de problemas completas.

RECOMENDACIONES PARA LA MIGRACIÓN

Versión: 29.08.2003 Página 347

Arquitectura en general

Figura 81: Arquitectura de TIC recomendada para organismos públicos especializados en caso de "migración completa"

5.2.3.1 Sistemas de gestión de bases de datos

Las recomendaciones dadas en la sección 5.2.2.1 también son aplicables en este caso a los sistemas de gestión de bases de datos. Los centros informáticos requieren además que los sistemas sean certificados para ciertos aparatos (SAN) y programas como condición para su uso. Muchos sistemas de bases de datos basados en Linux (SAP DB, Oracle,

DB2, etc.) están ya certificados. Por otra parte, los responsables de los centros informáticos pueden utilizar distribuciones de Linux certificadas como sistema operativo base en sus respectivas aplicaciones.

5.2.3.2 Servidor de aplicaciones

Los servidores de aplicaciones suelen utilizarse en casos de aplicaciones complejas. Entre las aplicaciones especiales, estos servidores implementan procesos y reglas de negocios complejos y, al tiempo, acceden a sistemas externos. El servidor de aplicaciones debe ser capaz de garantizar la gestión de sesiones de usuario. Además, debe ofrecer interfaces adecuadas para las aplicaciones externas y debe incluir soluciones de alta disponibilidad (granjas, balanceado de carga, alta disponibilidad). Además de los ya conocidos productos comerciales (SCOL) como Websphere de IBM, Weblogic de BEA, Application Server de Oracle y muchos otros, también se pueden utilizar productos de código abierto. El proyecto "JBoss" ofrece un completo servidor de aplicaciones Java de código abierto. Este servidor de aplicaciones cumple la especificación J2EE y viene de serie con un servidor web, un JSP y un motor de servlets,

Recomendaciones para la migración

Página 348 Versión: 28.09.2003

es compatible con Enterprise Java Beans, y puede configurarse en granjas.

5.2.3.3 Servicios de gestión de sistemas

A la vista de los requisitos en parte comparables, se pueden dar las mismas recomendaciones que para aquellos organismos oficiales especializados de medio y gran tamaño.

5.2.4 Organismos públicos pequeños

Los organismos oficiales pequeños suelen contar con arquitecturas de TIC centralizadas; no obstante, no tienen el carácter de un centro informático por su concentración local. Estos pequeños departamentos no suelen llevar a cabo grandes procesos directamente. Estos servicios suelen externalizarse siguiendo un modelo de leasing y las desarrollan los centros informáticos de la administración. Los estándares de calidad definidos en el seno de la administración pública no preveen ningún requisito especial en términos de disponibilidad ni de soporte al usuario (basta con el horario de trabajo habitual). De uso común es el hardware de copias de seguridad y de archivo. Las plataformas de gestión de sistemas no suelen utilizarse. El enfoque preferido es el uso de herramientas y scripts propios para acometer las tareas del departamento. Las administraciones más pequeñas se caracterizan por sus requisitos bajos o medios en cuanto a seguridad, el rendimiento y las posibilidades de ampliación de la infraestructura de TIC. El soporte de primer y segundo nivel suele combinarse y realizarse sin más ayuda que una herramienta de gestión de problemas.

Los productos de código abierto no tienen necesariamente que adaptarse al tamaño de una administración pública. Los productos ampliables, como Samsung Contact o SunOne Directory

Server, pueden satisfacer cualquier requisito de un departamento pequeño. En cualquier caso, cualquier recomendación debería tener en cuenta el hecho de que las soluciones grandes suelen exigir un mayor despliegue en la instalación, más esfuerzo en la configuración y, en general , un mayor coste.

En cuanto a las recomendaciones para la evaluación de la eficiencia económica en casos de migraciones totales en organismos públicos medianos y grandes, consulte los capítulos 4.6.1 y 4.8.6.5.

RECOMENDACIONES PARA LA MIGRACIÓN

Versión: 29.08.2003 Página 349

Arquitectura en general

Figura 82: Arquitectura de TIC recomendada para organismos públicos pequeños en casos de "migración total"

5.2.4.1 Sistemas de gestión de bases de datos

En el ámbito del software de código abierto se puede encontrar una gran variedad de sistemas de bases de datos alternativos. Todos los sistemas de bases de datos tratados en profundidad en el capítulo 3.13.4 son muy adecuados para su uso en trabajos ya descritos.

No se pueden extraer recomendaciones generalizadas, simples y claras de SAP DB, My SQL o

PostgreSQL de sus propiedades funcionales. La decisión a favor de un sistema de bases de datos u otro ha de examinarse en cada caso, siempre como parte de un desarrollo planificado o de un entorno de ejecución.

No obstante, MySQL constituye una solución óptima, especialmente a la hora de desarrollar bases de datos y aplicaciones web con PHP, gracias a su estrecha integración.

5.2.4.2 Programas de trabajo en grupo

Junto a la solución recomendada para administraciones públicas grandes, el uso de la solución Samsung también tiene sentido en administraciones más pequeñas. Aparte de Samsung Contact, la solución Kroupware (consulte 3.14.4) también puede constituir en el futuro una base adecuada para organizaciones medianas y pequeñas. La ventaja de la solución Kroupware es su estrecha integración con los clientes de programas de trabajo en grupo basados en GNU/Linux, propios del escritorio KDE. Esto significa que en el futuro tendremos a nuestra disposición una solución sujeta a la licencia GPL, una interesante alternativa desde el punto de vista económico. Ha de tenerse en cuenta en este contexto que puede utilizarse el plug-in de código abierto "Ägypten",

Recomendaciones para la migración

Página 350 Versión: 28.09.2003

una herramienta compatible con SPHINX para el cifrado y firmado de correo electrónico.

Aquellos departamentos que no estén intersados en el uso sin conexión de soluciones de trabajo en grupo también pueden utilizar accesos mediante clientes web. phpGroupware también puede ser la solución en este caso.

5.2.4.3 Servicio de directorio

El servicio de directorio de código abierto OpenLDAP se recomienda para la administración de información importante de la red. El servicio puede, por ejemplo, utilizarse para la gestión de usuarios, su autenticación, recursos dedicados al hardware y otros ajustes de la infraestructura (registros DNS, configuraciones DHCP, etc.). OpenLDAP ofrece todas las funciones habituales y necesarias de administración de un directorio completo (consulte el capítulo 3.7.4).

5.2.4.4 Servicios de gestión de sistemas

El uso de la amplia gama de herramientas disponibles de serie bajo Linux se recomienda principal mente para administraciones de menor escala. Estas herramientas (ssh, cron/at, potentes intérpretes de comandos, utilidades y lenguajes de programación) pueden utilizarse para automatizar tareas rutinarias en gran medida. Otras herramientas y productos de administración de sistemas se presentan en el capítulo 3.6.

5.3 "Migración progresiva" completa

Una migración progresiva completa es una transición en la que la gama de productos de Microsoft se sigue utilizando en todas las áreas. Existen dos posibles situaciones de partida que justificarían esta modalidad de migración.

No obstante, las razones técnicas no son parámetros decisivos en ninguna de las situaciones que se describen a continuación. Con sólo algunas excepciones, existen alternativas técnicas que funcionan sobre Linux para todas las necesidades expuestas. En el análisis final, la razón para optar por una "migración progresiva" es económica.

La primera situación de partida tratada aquí ha sido descrita en el capítulo 2 de esta guía como un entorno de sistemas NT 4 con Exchange 5.5, SQL Server 7 de MS, IIS 4 y Office 97 u Office 2000, respectivamente. El entorno ya está caracterizado por una grado de integración muy alto. Entre los parámetros clave para evaluar el nivel de integración se cuentan por ejemplo los siguientes:

Número de aplicaciones especiales disponibles sólo para Windows

Disponibilidad del código fuente de tales aplicaciones especiales

Nivel de integración de las aplicaciones especiales, especialmente en el entorno Office de MS

Alcance del uso de entornos de desarrollo e interfaces de lenguajes de programación específicos de Microsoft

RECOMENDACIONES PARA LA MIGRACIÓN

Versión: 29.08.2003 Página 351

Número de macros y scripts específicos de Office de MS (por ejemplo, implantaciones de flujos de trabajo propios de departamento).

Los costes y el esfuerzo necesarios para efectuar una migración progresiva aumentan cuanto mayor es el grado de integración. Una afirmación final relativa a qué nivel de integración justifica una migración progresiva suele requerir un análisis detallado de los componentes a migrar en cada caso, así como una evaluación de eficiencia económica más detallada.

En la práctica, el desarrollo avanzado de la plataforma .NET originará una situación de partida con un nivel de integración tal, que supondrá un obstáculo considerable para la migración. Una migración parcial en una primera fase puede obstaculizar este desarrollo (consulte el capítulo 5.4).

Figura 83: Situación de partida para una migración progresiva

La segunda situación de partida considerada en el presente documento describe un entorno de TIC en el que ya se han producido una migración total a Windows 2000 y una implantación completa de directorios activos (consulte la figura 83). El cambio fue realizado recientemente, por ejemplo en el año 2002. En cuanto al modelo de arquitectura subyacente a las recomendaciones para la migración (capítulo 5.2.1), las prestaciones máximas del modelo son las siguientes:

Estaciones de trabajo: clientes Windows 2000 con Office 2000

Servidor web: Internet Information Server 5

Servidor de bases de datos: SQL Server 2000 de MS

Recomendaciones para la migración

Página 352 Versión: 28.09.2003

Programas para trabajo en grupo/mensajería: Exchange 2000

Servicio de directorios: servicio de directorio activo

Servicios de infraestructuras:

Windows 2000 Server (Advanced Server)

(sistema de archivos, servicios de impresión y servicios de red)

En el caso de que los elementos individuales de esta arquitectura aún no estén en uso, se pueden proponer soluciones adecuadas en el seno de una migración parcial. Consulte el capítulo 5.4 si desea más información y recomendaciones acerca de este tema. En lo referente a la situación descrita anteriormente, el principio de protección de la inversión implica que no se puede recomendar una migración total (ni siquiera parcial) de componentes ya en uso al menos en los próximos 4 ó 5 años. No obstante, dicha situación de partida no debería considerarse como parte de las recomendaciones de migración por las siguientes razones:

A continuación se describirán formas de minimizar el grado de integración mencionado anteriormente en estas situaciones y, por lo tanto, la dependencia de los organismos públicos de productos de Microsoft .

Además, también se van a hacer algunas recomendaciones relacionadas con los futuros modelos de migración a las administraciones públicas en la medida de lo posible teniendo en cuenta nuestra información actual.

Desde el punto de vista económico a largo plazo, una migración progresiva no es muy recomendable, especialmente si se pretende evitar la dependencia de un solo proveedor. Una migración progresiva puede tener sentido en aquellos casos donde los costes de migración de aplicaciones especiales basadas en la plataforma Microsoft, y que deberían ser reprogramadas para adaptarlas al software libre, serían tan grandes que la migración no sería rentable a largo plazo.

Para conocer las recomendaciones de evaluación de la eficiencia económica, en el caso de migraciones progresivas, consulte los capítulos 4.6.2 y 4.8.6.6.

5.3.1 Minimizar el grado de integración para proteger el grado de libertad

Como ya se ha mencionado, una migración progresiva y el uso de Windows 2000, incluidos los directorios activos, debería paliar la dependencia de los productos de Microsoft, con lo que se podrían utilizar todas las opciones de una migración total incluso en el futuro. Tenga en cuenta las siguientes recomendaciones.

Servicio de directorios:

Cualquier uso de directorios activos debería restringirse a los "directorios activos de funciones reducidas“ (consulte la sección 3.7.5).

El directorio activo no debería utilizarse como fuente LDAP para otras aplicaciones (por ejemplo, aplicaciones web).

RECOMENDACIONES PARA LA MIGRACIÓN

Versión: 29.08.2003 Página 353

Los datos personales del directorio activo han de importarse desde una fuente independiente, como MetaDirectory. Si los conceptos de papeles se planean por adelantado, los programas que exijan directorios activos o disponer de directorios activos como centro principal deben evitarse.

Sistemas personales

El uso de aplicaciones basadas en Access de MS ha de evitarse. El uso de una base de datos central y de aplicaciones programadas, por ejemplo, con PHP deberían recibir trato preferencial.

Las aplicaciones VBA deberían ser descritas, analizadas detalladamente y centralizadas si este procedimiento no se ha seguido ya en el proceso de migración. Los nuevos desarrollos en este área deberían evitarse siempre que sea posible.

Las aplicaciones deberían elegirse y los proyectos de desarrollo iniciarse teniendo siempre en cuenta su compatibilidad con los estándares y arquitecturas para aplicaciones de e-gobierno o SAGA (consulte el capítulo 3.8).

Las aplicaciones de terceros que exijan productos de Office como entorno de ejecución único deberían evitarse siempre que sea posible.

Esto último no es aplicable en el caso de aplicaciones especiales para las que no se preve una alternativa a medio plazo.

Las aplicaciones (especiales) que requieran productos de Office de MS deberían migrarse gradualmente.

Sistema de archivos

Se debe garantizar la posibilidad de reproducción de la estructura de permisos mediante el uso de scripts (por ejemplo, Perl). Si se utiliza una interfaz gráfica de usuario, es obligatoria una documentación detallada y completa de todas las configuraciones. Dado que esto no siempre puede garantizarse a la vista de las conocidas debilidades humanas, el formato script es el mejor acercamiento a este problema.

Los grupos locales no deberían utilizarse a menos que sea absolutamente necesario.

Programas de trabajo en grupo/mensajería

No se deben utilizar servidores Exchange 2000 como distribuidores principales de correo. Para esta finalidad deben emplearse productos de código abierto (como postfix o sendmail), de forma que se garantice la opción de trabajar con varios sistemas de correo en paralelo.

No se deberían utilizar aplicaciones en carpetas públicas de Exchange.

Aplicaciones web

Los productos de Microsoft no deberían utilizarse si quieren respetarse las normas de compatibilidad de SAGA y su gran número de alternativas (consulte el capítulo 3.9).

Se debe evitar la autenticación mediante instancias de autenticación secundarias. Utilizar una segunda contraseña es una práctica aceptable y puede

Recomendaciones para la migración

Página 354 Versión: 28.09.2003

justificarse, en primer lugar y sobre todo, por razones de seguridad. En situaciones excepcionales se pueden utilizar productos de código abierto alternativos.

Gestión de sistemas

El uso de productos de terceros que también sean compatibles con Linux (como Tivoli) debería tener preferencia.

Servicios de red

Las soluciones de código abierto han de tener preferencia en servicios de red DHCP y DNS.

Software de interfaz

A la hora de desarrollar aplicaciones, debería optarse por una estrecha integración con los estándares SAGA para aumentar las posibilidades de reutilización de código.

Deberían utilizarse tecnologías de servicios XML y web para la comunicación y el intercambio de información con sistemas externos (a menos que problemas de seguridad lo impidan; consulte los capítulos 3.10 y 3.9).

5.3.2 Otros modelos de migración

De cara a continuar con la migración, primero es necesario tratar la instalación de Windows XP en estaciones de trabajo. El principio de protección de la inversión ha de aplicarse también en este caso. A la luz de este problema, y en una situación de partida como la descrita anteriormente, la migración de las estaciones de trabajo a Windows XP no puede recomendarse. Si se tienen en cuenta diferentes aspectos de la protección de la inversión, la continuación de la migración podría atrasarse 4 ó 5 años como poco. Esto significa que, suponiendo una migración en 2001, el próximo cambio no tendría lugar antes de 2005. Especialmente aquellos organismos públicos que han adoptado las anteriores recomendaciones, para reducir su dependencia de productos de Microsoft , tendrían que comprobar si, a la luz de las condiciones técnicas y económicas del momento, se debe efectuar una migración completa o progresiva. Lo mismo es aplicable a cualquier otra administración en la misma situación de partida.

5.4 Migración parcial

5.4.1 Migración selectiva

Una migración selectiva consiste en sustituir permanentemente un producto Microsoft seleccionado por una solución de código abierto o de software comercial para Linux, mientras el resto de productos se somete a una migración progresiva. La siguiente sección esbozará casos de migraciones selectivas sensatas y factibles.

La migración selectiva más importante afecta a la sustitución de Exchange 5.5. Una razón para esta sustitución es el hecho de que, según la información de que se dispone actualmente,

RECOMENDACIONES PARA LA MIGRACIÓN

Versión: 29.08.2003 Página 355

Microsoft va a dejar de mantener (al menos en sus versiones generales)194 Exchange 5.5. La alternativa susceptible de migración progresiva ofrecida por Microsoft es Exchange 2000. No obstante, migrar de forma progresiva a Exchange 2000 no es posible para muchos organismos públicos porque esta solución especifica el uso de un directorio activo como componente obligatorio. Con Exchange 2000, Microsoft ha externalizado el anterior servicio de directorios interno de Exchange 5.5 y ha desarrollado el directorio activo en función de este modelo, convirtiéndolo en el centro del cosmos de Windows 2000. Esto significa que Exchange 2000 requiere Windows 2000 Server o uno de sus sucesores.

Muchos organismos públicos están, por todo esto, muy interesados en una solución alternativa adecuada para los programas de trabajo en grupo y mensajería que ofrezca funciones comparables o idénticas, que no requiera directorios activos y que permita seguir utilizando Outlook de MS como cliente.

En este sentido, hay disponibles diferentes soluciones alternativas (consulte también la ilustración que aparece más abajo). En el caso de requisitos de compatibilidad más exigentes, dos soluciones son candidatas especialmente aptas para distintas necesidades, a saber:

Samsung Contact

Exchange4Linux

Gracias a su buena conexión MAPI, ambas soluciones permiten seguir utilizando el cliente Outlook con sus funciones más importantes. Si desea consultar una descripción técnica más detallada y una comparación de prestaciones, consulte el capítulo "Descripciones técnicas". Un cálculo modelo de la eficiencia económica en el caso de migraciones a Samsung Contact está a su disposición en "Evaluación de eficiencia económica" (consulte el capítulo 4).

194 http://support.microsoft.com/default.aspx?scid=fh;en-us;lifesrvr

Recomendaciones para la migración

Página 356 Versión: 28.09.2003Figura 84: Diversas variantse para sustituir Exchange mediante una migración parcial

Samsung Contact, igual que Exchange, no es software libre, se trata de un programa propietario de la categoría de software comercial para Linux. La migración a Samsung Contact ya se ha tratado en el apartado de recomendaciones para una “migración total” completa (consulte el capítulo 3.14.4). Samsung Contact es especialmente apta para organismos públicos grandes y especializados, con requisitos muy específicos en cuanto a posibilidades de ampliación y seguridad contra fallos. También se puede recomendar a administraciones de hasta 500 usuarios una solución de menor precio conocida como Exchange4Linux. Se trata fundamentalmente de una solución de software libre. El componente del servidor es software libre, y sólo el conector MAPI es un producto restrictivo, únicamente disponible previo pago. Si desea conocer todos los detalles, consulte el capítulo 3.14.4. Ambas soluciones requieren disponer de Linux como sistema operativo de servidor. La migración selectiva ofrece toda una serie de ventajas:

El alcance del proyecto de migración está claramente definido y se puede planear bien.

Los ajustes necesarios son limitados, de forma que la planificación y gestión del proyecto tienen muchas ventajas clave.

Los conceptos de funcionamiento y experiencia con una nueva plataforma de sistema operativo se pueden desarrollar paso a paso.

Los administradores involucrados en el proyecto necesitan formación. Así, los administradores recién formados podrán servir de divulgadores en el departamento de TIC.

RECOMENDACIONES PARA LA MIGRACIÓN

Versión: 29.08.2003 Página 357

Otro aspecto que se debe mencionar al hablar de programas de trabajo en grupo y mensajería es que la migración únicamente del correo es significativamente más sencilla en aquellos casos en que las funciones de trabajo en grupo no son necesarias. Esto es, de hecho, una solución probada y, por lo tanto, preferible.

Otra forma de migración selectiva consiste en sustituir Office de MS con OpenOffice.org o StarOffice. En este caso habrán de tenerse en cuenta las restricciones funcionales mencionadas anteriormente, especialmente sus consecuencias económicas. En la evaluación de eficiencia económica de una migración total, capítulo (3.15.4), ya se ha analizado la migración de Office. Para conocer las recomendaciones para la evaluación de eficiencia económica en migraciones selectivas, consulte los capítulos 4.6.3.1 y 4.8.6.7.

5.4.2 Migración parcial de los servidores

El ejemplo de una migración generalizada de servidores se utilizará a continuación para presentar una situación sensata y recomendable a partir de la cual efectuar una migración parcial de servidores. Como situación de partida se asume el entorno Windows NT descrito en el capítulo 2.2.1.

Las recomendaciones ofrecidas para migraciones completas (ver también 5.2) también son, en principio, aplicables a las migraciones generalizadas. Las diferencias residen en el hecho de que los clientes sigan siendo fundamentalmente sistemas basados en Windows.

Las recomendaciones para:

Sistema de bases de datos

Servidores web

Servicios de red

también pueden encontrarse en la sección 5.2.

El requisito fundamental para la migración de servidores es que el funcionamiento e interacción entre servidores basados en Linux y clientes basados en Windows sean impecables tras la migración. El requisito más importante para el proceso de migración probablemente sea la sustitución del sistema de archivos y los servicios de impresión, red y autenticación, incluida la migración de estructuras de archivos y permisos, y la importación de datos de configuración.

La evaluación de eficiencia económica indica que entre un 65% y 80% aproximadamente de los costes del proyecto son compensados por el ahorro producido. Los costes de personal asociados al cambio decantan el balance final, esto es: los costes superan al ahorro. Esto significa que normalmente no existe una ventaja económica directa derivada de este tipo de migración comparada con una migración progresiva. No obstante, los factores “blandos” en cuanto a criterios de urgencia y estrategia serán muy probablemente relevantes en la decisión de un proyecto.

Para conocer detalles en lo relativo a las recomendaciones para la evaluación de eficiencia económica en migraciones amplias, consulte los capítulos 4.6.3.2 y 4.8.6.7.

Recomendaciones para la migración

Página 358 Versión: 28.09.2003

5.4.2.1 Administración y autenticación de usuarios

Un servidor Samba basado en Linux junto a OpenLDAP se recomienda como un buen sustituto del controlador de dominios Windows NT 4.0. Samba es capaz de desempeñar todas las funciones de un controlador de dominio Windows bajo Linux. Especialmente la próxima versión Samba 3.0195 que ya había sido probada con éxito en proyectos de migración de la German Federal Cartel Office, permite establecer conexiones casi sin restricciones con clientes Windows 2000 y Windows XP. Si desea obtener más detalles, consulte las descripciones técnicas del capítulo 3.

5.4.2.2 Servicios de archivos e impresión

Como ya hemos explicado, Samba es el único producto para servicios de archivos que tendremos en cuenta para la integración impecable de clientes Windows. Samba es capaz de desempeñar las funciones más importantes de un servidor de archivos basado en Windows NT bajo Linux. Los usuarios de clientes Windows también pueden obtener su perfil de usuario y scripts de acceso, así como directorios de inicio y directorios de grupo a través de un servidor Samba. Los sistemas de archivos XFS y EXT3 se recomiendan para el almacenamiento físico de datos en los sistemas de disco del servidor. Ambos sistemas de archivos (véase 3.2.3) son compatibles con POSIX-ACL, características de registro (journaling) y cuotas.

Los servicios de impresión han de implantarse mediante CUPS sobre Samba. CUPS se integra perfectamente en entornos Samba.

5.5 Métodos de migración

5.5.1 Migración en un único paso

Esta sección ofrece un esbozo de las razones para efectuar una migración en un único paso y analiza las situaciones de partida en las que se recomienda este tipo de cambio. La migración en un único paso es el contrario de una migración sutil. Ambos métodos de migración tienen como objetivo último una "migración total", es decir, que ambos métodos están encaminados a la implantación de un entorno de sistemas basado por entero en Linux. La migración en un único paso se caracteriza no por su velocidad sino por el hecho de que tiene lugar en un corto y, sobre todo, acotado plazo de tiempo. La migración en un único paso tiene una fecha de inicio definida (fecha de comienzo) y un final determinado (fecha de conclusión). La migración finaliza cuando se inicia el funcionamiento productivo a gran escala de un entorno de TIC basado por entero en Linux. La migración en un único paso es especialmente exigente en términos de:

Organización del proyecto

Organización del organismo público involucrado

Hardware

Recursos económicos

Administradores

195 Aún no publicado ni desarrollado y probado por completo.

RECOMENDACIONES PARA LA MIGRACIÓN

Versión: 29.08.2003 Página 359

Usuarios

Los requisitos de administradores y usuarios, en particular, no deberían subestimarse. Esto tiene mayor relevancia cuanto más limitados sean los conocimientos de administradores y usuarios sobre el nuevo entorno de TIC. La migración en un único paso, no obstante, también tiene la ventaja de que los administradores no tienen que hacerse cargo de dos orientaciones de TIC diferentes durante un largo periodo de tiempo. En un intervalo relativamente corto (proporcional a los requisitos del proyecto en cuestión), podrán centrarse por entero en los nuevos sistemas. Otro requisito importante es disponer de los fondos necesarios en un periodo de tiempo relativamente corto. En el análisis final el alcance y sobre todo la complejidad y diversidad de las aplicaciones, y los sistemas que se desean migrar determinan cuándo se necesitan los fondos y en qué cantidad. Este aspecto es un factor determinante en la viabilidad de la migración en un único paso.

Los exigentes requisitos en la organización de administraciones públicas se centran, por un lado, en la cualificación de la plantilla que deberá continuar haciendo su trabajo cotidiano. Esto significa que deben minimizarse las interferencias en el trabajo del organismo. Por otra parte, las operaciones en TIC han de continuar; un cambio en todo el entorno de servidores supone grandes exigencias para todas las partes implicadas porque la migración de los servicios de servidor puntuales no puede separarse al azar y los administradores han de garantizar un trabajo fluido mientras se forman en la utilización de los nuevos sistemas. Estos requisitos pueden abordarse mediante conceptos adecuados de cambio y sustitución. También se puede configurar un entorno de TIC paralelo, incluso aunque esto implique aumentar las exigencias de hardware y costes.

Estos exigentes requisitos suscitarán inevitablemente la pregunta de si una migración en un único paso tiene sentido y/o para quién, así como a quién recomendársela. Las razones para una migración de este tipo son las siguientes:

La migración es inevitable, por ejemplo porque la asistencia para sistemas antiguos está desfasada.

Los administradores y usuarios han de afrontar un cambio profundo, pero sólo una vez en lugar de todos los años.

Los administradores no han de superar la complejidad de entornos heterogéneos durante periodos de tiempo indeterminados.

¿Bajo qué condiciones y para quién tiene sentido esta migración en un único paso?

Un entorno de sistemas claramente configurado y sin demasiadas interdependencias es una buena condición previa para una migración en un único paso. Esto significa que sólo algunas aplicaciones y servicios se utilizan para satisfacer tareas productivas. Esto no significa necesariamente que las administraciones y organismos en cuestión sean pequeños o tengan estructuras simples. Esto también se aplica, por ejemplo, a administraciones y organismos

Recomendaciones para la migración

Página 360 Versión: 28.09.2003

con funciones de seguridad en las que la mayoría de usuarios dependen de unas pocas aplicaciones especializadas, por lo general ubicadas en un servidor, y que se emplean para hacer la mayoría del trabajo. No obstante, también puede servir este enfoque para organismos pequeños y medianos con algunas aplicaciones especializadas, documentación de oficina estándar y programas de Office con un número pequeño de plantillas y documentos complejos (como la Comisión Antimonopolio). Los organismos públicos donde los administradores ya dispongan de los conocimientos necesarios también ofrecen buenas condiciones para una migración en un único paso. Bien sea porque los administradores emplean sistemas basados en Linux en casa o porque ya utilizan oficialmente aplicaciones y servicios concretos basados en Linux (como servidorse de correo sobre Linux). Si el personal se muestra además abierto a nuevos desarrollos y está interesado en Linux, tenemos otra condición previa ideal para la migración en un paso.

5.5.2 Migración suave

Esta sección trata sobre las razones y formas de hacer una migración suave. Pero, ¿qué significa exactamente migración suave? Se trata de un enfoque en el que el objetivo está claro, pero en el que el tiempo dedicado a lograrlo se define sólo de forma aproximada, efectuando el proceso de migración componente a componente, basándose en el modelo arquitectónico descrito anteriormente.

Las razones para una migración suave se hacen claras al repasar los requisitos y razones para una migración en un único paso.

Los organismos y administraciones públicos con pocos medios pueden distribuir los costes necesarios en función de su situación presupuestaria.

La falta de conocimientos se puede desarrollar gradualmente, de forma que se recortan los costes. Una migración suave permite ir asentando los componentes uno a uno.

Los administradores, una vez formados, pueden actuar como divulgadores, de forma que cuando se migra el siguiente componente ya hay disponible un mayor nivel de conocimientos.

Las barreras y reservas existentes desaparecen gradualmente.

Las estructuras de TIC complejas pueden simplificarse componente por componente.

La siguiente ilustración muestra un posible proceso de migración suave.

RECOMENDACIONES PARA LA MIGRACIÓN

Versión: 29.08.2003 Página 361

Figura 85: Migración suave

Un componente fácil de detectar ha de ser el primer elemento a migrar. En el ejemplo anterior se ha elegido el servidor DBMS. La tarea no consiste en migrar las aplicaciones de la base de datos, sino el establecimiento de un DBMS paralelo. Se supone que se dispone del conocimiento sobre DBMS necesario, ya que durante la primera migración se requerirá al menos un DBMS, por ejemplo cuando el servidor web sea sustituido. Si bien el servidor de directorios es en principio un componente independiente, puede que sea utilizable conjuntamente con el servidor web y crear una situación favorable para la siguiente fase de migración: la del software de trabajo en grupo. La migración de los servicios de archivos, red e impresión será el siguiente paso. Finalmente, se pueden migrar los sistemas personales cuando se hayan ido adaptando en segundo plano todas las aplicaciones especializadas y las de oficina. En el caso de una migración suave, no se pueden intercambiar y sustituir los componentes aleatoriamente en cada paso. Los elementos que funcionan en grupo deberían mudarse de forma conjunta. Otro aspecto importante es no sobrecargar el calendario y fijar fechas realistas. Por otra parte, el tiempo de implantación ha de reflejar la complejidad de la actualización y sustitución de tareas y, por lo tanto, el trabajo del administrador. Dado que los requisitos de administración según los entornos de TIC son mayores que en entornos homogéneos, todo el proceso de cambio debería completarse en 2 o 3 fases, con fechas límite realistas para lograr una migración suave.Figura 86: Fases de cambio con una migración suave

muestra las tres fases de migración. La migración puede entonces llevarse a cabo hasta un punto relativamente avanzado en un entorno heterogéneo, especialmente con la ayuda de Samba, de servicios de terminal y de la posibilidad de seguir utilizando Outlook como cliente para trabajo en grupo y mensajería.

En último término, después de que todas las aplicaciones especializadas y de Office se hayan migrado en paralelo con este proceso, la migración del escritorio – esto es, la migración en el extremo del cliente – a Linux se puede llevar a cabo. A condición de que la migración de las aplicaciones especializadas y de Office lo permitan, incluso se puede considerar la migración de MS Office a OpenOffice.org o StarOffice bajo un cliente Windows en un paso intermedio.

5.5.3 Factores críticos de éxito

Los proyectos de migración son normalmente complejos e involucran muchos aspectos. Esto se aplica tanto a una migración completa (clientes y servidores) como a una parcial (solo servidores) o selectiva. La figura que sigue muestra el proceso de migración multifase con sus varios subaspectos.Figura 87: Modelo de proceso gradual de migración

Para asegurar el éxito de los proyectos de migración tanto en su faceta de proyectos TI en general, como en su faceta de proyectos de innovación en particular, deben identificarse y evaluarse los factores críticos para el éxito con bastante antelación. Un proyecto de migración es primero y ante todo un éxito para todos los implicados si se alcanzan los objetivos y resultados deseados dentro de los límites planeados y acordados de tiempo y presupuesto.

Además, la contribución al éxito de los llamados factores “suaves” no se debe subestimar. Estos factores incluyen, por ejemplo, la satisfacción de la plantilla, la comunicación fluida y por tanto eliminación o reducción de fallos, frustración y trabajo doble, así como la selección conforme a la demanda y, por supuesto, la aceptación del nuevo panorama de IT por sus usuarios.

Con independencia del tamaño de una agencia pública y con independencia de la naturaleza del proyecto de migración – esto es, migración de reemplazo o progresiva – los parámetros que se resumen a continuación contribuyen, en opinión de los autores, al éxito sostenible de un proyecto.

Identificación de objetivos claros para el proyecto de migración

Implicación y posicionamiento de los niveles de gestión y toma de decisiones

Información temprana e implicación de la plantilla y grupos afectados

Creación de un alto grado de aceptación de los usuarios del entorno apuntado

Planificación estructurada de tiempo, proyecto y recursos, incluyendo control del proyecto Medidas organizativas para preparar el proceso de migración y establecer un equipo cualificado de proyecto

Toma de stocks detallada, incluyendo una definición de requisitos funcionales

Selección óptima de proyecto y servicio

Entrenamiento a tiempo y sostenible

Gestión de calidad y documentación

Un vistazo a los factores de éxito sugiere que los proyectos de migración no acaban con la compra e implementación de los componentes requeridos. Dependencias y actividades adicionales deben ser tenidas en cuenta tanto antes como durante y después del proyecto real de migración.

Los proyectos de migración solo se pueden tener como exitosos y económicamente eficientes si, además de minimizar los costes de operación, también mejoran los procedimientos de trabajo mediante un soporte de comunicación e información que sea actual, integrador, y funcionalmente orientado al objetivo, y si conducen a un incremento general de la flexibilidad, la eficacia y la capacidad de respuesta a tareas presentes y futuras. Otros objetivos, como la independencia de fabricantes y/o plataformas, son aspectos centrales que deben satisfacer los parámetros de una evaluación de eficiencia económica.

Las siguientes secciones discutirán los criterios de éxito más importantes identificados para proyectos de migración en más detalle.

5.5.3.1 Identificación de objetivos claros

La identificación de objetivos claros es la base del éxito de cualquier proyecto. Se debe distinguir en este contexto entre objetivos estratégicos de administración (nivel de motivación) y objetivos al nivel de migración de servidores (nivel de implementación). Las razones subyacentes para la migración deben exponerse en un primer paso, seguido por una definición de lo que se espera conseguir con la migración en otro paso.

Antes de comenzar el proyecto, se deben explicar los objetivos del proyecto de migración a los afectados, a la administración de la agencia pública y a los socios implicados. Esta definición de objetivos es la base de toda acción posterior, del diseño del proyecto y de la selección del software apuntado, asi como de la selección de los socios internos y externos que se implicarán. Alcanzar un cierto grado de independencia de fabricantes y/o plataformas es por tanto un objetivo bastante general.

Dependiendo de la agencia concreta afectada, pueden existir por ejemplo los siguientes objetivos detallados al nivel de migración de servidores

Migración de servidores sin adaptación y modificación de clientes (importación completa de datos, perfiles de usuario, estructuras de archivos y directorios, incluyendo privilegios de acceso existentes)

Migración completa de clientes (reemplazo equivalente de aplicaciones y funciones, e integración en la red informática heredada de la agencia pública sin afectar a la red) Migración de datos y estructuras de datos, manteniendo las aplicaciones de bases de datos (con la correspondiente selección de sistemas de bases de datos libres)

Reemplazo de las aplicaciones existentes en estaciones de trabajo por aplicaciones equivalentes (implementación de un sistema de administración central fácil de usar; consideración de los componentes de seguridad de IT según Bund Online 2005, tales como ICP (infraestructura de clave pública), autentificación via certificados y características biométricas)

Creación de un sistema de reemplazo adecuado para la administración y autentificación de usuarios

Conversión transparente al usuario de plantillas de formato

5.5.3.2 Implicación y posicionamiento del nivel de gestión y toma de decisiones

El nivel de gestión y toma de decisiones es el nivel en el que se toman decisiones clave para el proyecto de migración sin estar directa y activamente implicado en el trabajo del proyecto. La administración del proyecto responde ante este nivel. Cómo se define en detalle este nivel depende de la situación particular de la agencia pública y de la prioridad del proyecto dentro de la agencia pública.

El papel del nivel de gestión para el éxito del proyecto a menudo se subestima. Es un hecho empírico que la gente tiende a pensar que los que están en el nivel administrativo “saben poco o nada de las tecnologías de la información y comunicaciones”. Al mismo tiempo, la gente cree también entonces que la gestión de una agencia pública “sólo” tiene como interés primordial tener un “sistema asequible que funcione”. Sin embargo, esta idea es contraproducente. En contraste, el nivel de gestión y toma de decisiones es el responsable de definir los objetivos de la migración específicos para la agencia más que del establecimiento e implementación del proyecto. La gestión de una agencia pública es también responsable normalmente de corregir y revisar los contratos existentes como resultado de tal proyecto.

En primer lugar, el proyecto de migración debe ser lanzado. Para este propósito, los gestores deben definir una misión de proyecto sobre la base de los déficits identificados y/o objetivos de proyecto concretos (por ejemplo, alcanzar la independencia de fabricantes y/o plataformas) o reconocer la necesidad de definir una misión de proyecto sobre la base de peticiones de los empleados subordinados.

Comunicando el proyecto como una decisión de gestión

El nivel de gestión contribuye de forma significativa al éxito del proyecto mostrando con claridad a todos los implicados en el proyecto y a la plantilla en su conjunto que la gestión apoya este proyecto que ella ha iniciado y que la gestión no solo monitoriza todas las fases del proyecto durante toda su duración, sino que también apoya activamente el proyecto.

Información a tiempo y activa para la plantilla

La responsabilidad en la comunicación y motivación de la plantilla es otra tarea central de gestión que comienza y debe llevarse a cabo incluso (antes)Antes de que un proyecto de migración comienze realmente. El liderazgo tiene lugar a través de la comunicación, así que el liderazgo y los estilos de comunicación están inseparablemente conectados, requiriendo particualrmente un alto grado de competencia social. Esto significa que los proyectos planteados deben ser transparentes para todos los miembros del equipo y todos aquellos involucrados. Tanto las areas que van a ser cambiadas y las que no deben ser identificadas. (Por ejemplo, los elementos a cambiar y los que no podrán ser descritos de una forma precisa tomando como base el concepto operativo existente).

Además, diferentes canales de comunicación deben ser usados para diseminar información, como reuniones de información general, hablar con el equipo, talleres o circulares y avisos, también usando la intranet de las agencias públicas (evitar rumores). Las formas para responder a las preguntas y sugerencias, así como las preocupaciones y los miedos del equipo relacionados con el cambio deben ser establecidos en las primeras fases del proyecto. Personal representativo y representantes deben también estar involucrados en la totalidad del proceso y en todos los momentos.

Aprovisionamiento de los fondos requeridos

El nivel de gestión debe asegurarse de que los fondos (no personales y personales) requeridos para los diferentes paquetes de trabajo y para aquellos involucrados esten disponibles al comienzo del proyecto. Esos costes incluyen no solo la inversión inicial y los costes de licencias, sino también los costes de entrenamiento, consultas externas, mantenimiento del proyecto así como los costes del personal interno, por ejemplo. Además, serán necesarios ajustes en los fondos requeridos dependiendo del progreso del proyecto.

Aceptación de resultados intermedios y finales

Una clara y definida división de responsabilidades existe entre el equipo directivo, los jefes de proyecto y el grupo de miembros del proyecto. Los que vayan a tomar las decisiones deben hacer y justificar las decisiones claves al final de las diferentes fases del proyecto en base a la documentación preparada por los miembros del grupo de proyecto. Las condiciones que se cambien pueden requerir modificaciones de los objetivos estratégicos.

Creación de un alto grado de aceptación del entorno final por parte del usuario:

Los proyectos de migración solo pueden tener sentido y ser un éxito a nivel del personal si los beneficios pueden ser claramente identificados y comunicados como algo sensible y necesario. Estos beneficios derivan de la definición de los objetivos.

El equipo involucrado debe de estar convencido de los beneficios del proyecto de migración para apoyar e introducir el proyecto en los departamentos individuales y a traves de la totalidad de la agencia pública. Al mismo tiempo las limitaciones del código de fuente abierto deben ser claramente comunicadas, y las razones para la introdución de código de fuente abierto deberían ser explicadas.

El objetivo es el de asegurar un alto grado de aceptación y por tanto la satisfación y la motivación del equipo. Lo que se debe prevenir es que el personal insatisfecho (gente a la que le falta información, motivación o cualificación debido a la falta de entrenamiento) ponga en peligro la totalidad del éxito del proyecto de migración y comunicar los fallos, si hubiese alguno. A largo plazo

A largo plazo, esto puede afectar a la eficiencia y puesta en práctica de la agencia pública en general. Además del “ejercicio obligatorio” de asegurar la salida de información a lo largo del proyecto, los responsables deben también llevar a cabo el “ejercicio voluntario” de la monitorización de los éxitos que se vayan produciendo en relación a la satisfacción del equipo para ser capaces de tomar las medidas oportunas, cuando fuese necesario.

Aunque el desarrollo de los conceptos y la implantación sostenible de medidas es inicialmente trabajo de la directiva , esto sólo puede ser desarrollado, llevado a cabo y, como no, mejorado de forma dinámica con la ayuda del personal. El apoyo externo, los consejos y los entrenamientos o enseñanzas pueden ser un medio de sensibilidad adicional durnte la fase inicial.

Entrenamiento de usuario y administrador.

En lo que a entrenamiento se refiere, los administradores deben ser integrados en una fase temprana y los futuros usuarios a medida que se acerquen los plazos. Un concepto específico del entrenamiento del grupo debe ser desarrollado considerando tanto las habilidades existentes, experiencia y cualificaciones como el futuro trabajo específico de los componentes. Esto también tiene que ver con el entrenamiento del usario en su lugar de trabajo así como el entrenamiento diario, especialmente para los administradores y el usuario que apoye al equipo en el campo de los entornos de software abierto. Además, las experiencias obtenidas de los proyectos piloto o de otros proyectos de migración deben ser activamente integradas en el entrenamiento para hacer uso de las lecciones aprendidas. Otras medidas concretas incluyen la implementación de entornos de prueba y simulación, los simulacros de emergencia, copias de seguridad y recuperación.

Todo ello es aún más importante si las habilidades y la experiencia son inexistentes o están limitadas y si el soporte contínuo o bajo demanda ya no están disponibles una vez que el proyecto de migración ha finalizado.

Medidas organizativas para preparar el proceso de migración

Establecimiento de un equipo de proyecto

Los típicos proyectos de migración son llevados a cabo por diferentes personas en vez de individualmente. Para que esto se lleve a cabo con éxito, dichos proyectos deben tener un curso definido y unos objetivos concretos. Estas son las características del clásico proyecto de trabajo, siendo recomendable el establecimiento de una organización orientada al proyecto .

En base a esto debe comprobarse si, y en qué grado, la estructura existente de la organización (que típicamente está orientada al proceso) es todavía una forma de organización adecuada y adaptada al proyecto. Si fuese necesario, la estructura de la organización de referencia debe de ser cambiada temporalmente y a los grupos involucrados -aparte de la estrucura de organización de la agencia pública- se les debe dar una nueva estructura organizativa como miembros del proyecto de grupo. Los procesos de trabajo, interfaces, productos y recursos deben ser identificados y definidos con anterioridad con

Los procesos de trabajo, interfaces, productos y recursos han de identificarse y definirse por adelantado con la participación de quienes vayan a estar implicados en el proyecto.

196 Consulte con el Ministerio del Interior alemán o la guía "Handbuch für Organisationsuntersuchungen in der

Bundesverwaltung" Bonn, 5ª edición de 1988, pp. 23 y siguientes

Recomendaciones para la migración

Página 368 Versión: 28.09.2003

Los siguientes principios han de aplicarse a este ejercicio:

La organización del proyecto es más importante que la estructura organizativa de la administración pública

Definición clara de tareas y responsabilidades

Reducción temporal o transferencia de trabajos rutinarios

Definición de las vías de comunicación e informes

Cualquier plan y medida ha de evaluarse pormenorizadamente con vistas a conocer hasta qué punto es compatible con los objetivos del proyecto desde el punto de vista organizativo. En caso de duda, debe darse prioridad a aquellas medidas que ofrezcan un mayor potencial de compatibilidad.

Miembros del grupo de proyecto

El jefe de proyecto y los miembros del grupo son claves en el éxito de un proyecto. Incluso cuando el resto de condiciones sean favorables, un equipo inadecuado puede arrojar resultados insatisfactorios, mientras que un equipo de alto nivel puede lograr resultados aceptables incluso en condiciones adversas. Esto contrasta con la opinión de algunos de que "nadie ha de ser irreemplazable".

Jefe de proyecto: el jefe de proyecto asume la responsabilidad general del proyecto. Coordina, organiza y comunica el trabajo general para garantizar que el proyecto se está desarrollando correctamente, acorde a los plazos y sin superar el presupuesto. El jefe de proyecto es responsable de definir objetivos y metas, y de constatar que se cumplen (incluidos los informes al comité rector, si corresponde). Dependiendo del tamaño del organismo público en cuestión y de la naturaleza de la migración, puede ser recomendable nombrar jefes de subproyecto.

El grupo del proyecto: los miembros del grupo del proyecto desarrollan el contenido e implantan las fases y metas concretas del proceso de migración. En principio se trata de los administradores, así como usuarios concretos y, si fuera necesario, especialistas externos (personas con experiencia y conocimientos prácticos,

consultores).

Incorporación de consultores externos

También los organismos públicos están haciendo uso cada vez más frecuentemente de la ayuda de consultores externos en sus proyectos. Las razones197 de esta tendencia incluyen:

Análisis del problema de forma profesional y sin prejuicios

Gestión de proyecto eficaz y orientada a objetivos claros

197 Ministerio del Interior alemán, "Handbuch für Organisationsuntersuchungen in der Bundesverwaltung", Bonn, 5ª edición de 1988, pp. 37 y siguientes

RECOMENDACIONES PARA LA MIGRACIÓN

Versión: 29.08.2003 Página 369

Comunicación constante en el proyecto, con progreso efectivo y comprobación de resultados

Gestión convincente, reuniones frecuentes, buena presentación y documentación de resultados

Transferencia de conocimientos en cuanto a la preparación e implantación de complejos proyectos de migración y tecnologías de la información. RECOMENDACIONES PARA LA MIGRACIÓN

Comunicación progresiva sobre el proyecto con controles efectivos de avance y resultados.

Administración, presentación (reuniones) y documentación de resultados convincentes y bien preparadas.

Transferencia del conocimiento (know-how) con respecto a la preparación e implementación de proyectos complejos de IT y migraciones.

Definición de la forma específica de organización del proyecto

La forma adecuada de organización para el proyecto de migración debe definirse en función del tamaño tanto del proyecto de migración como de la agencia pública. La organización del proyecto representa en este caso una organización paralela que no interfiere con la estructura de la organización existente y tiene una duración limitada a la duración del proyecto. Se recomienda establecer para la organización una de las tres opciones descriptas a continuación, dependiendo de las tareas y propósitos particulares.

Organzación linear: Los miembros del equipo del proyecto son delegados por la organización existente y forman una unidad organizativa separada dirigida por un adminstrador del proyecto. Esto lleva a una mayor identificación con el proyecto por parte de los miembros del equipo, y una total concentración en el mismo. Sin embargo, esto significa al mismo tiempo que esas personas no están disponibles en sus respectivos departamentos, lo que puede implicar una sobrecarga de trabajo para el resto del personal. La organización linear debería adoptarse en el caso de proyectos grandes y difíciles.

Organización en equipo: El proyecto es dirigido por un coordinador del proyecto que, al pertenecer al personal, no tiene poder formal de decisión y por lo tanto su responabilidad es limitada. Los miembros del equipo del proyecto permanecen en sus respectivos departamentos y solamente se reúnen en las reuniones del proyecto. Esto hace a la organización del equipo del proyecto susceptible de disrupción e ineficiencia.

Las ventajas de esta forma de organización son los limitados requerimientos organizativos (el único nuevo miembro que debe buscarse es el coordinador) y la flexibilidad en la distribución del trabajo (se trabaja en el proyecto y en los respectivos departamentos). Además, se pueden desarrollar varios proyectos al mismo tiempo. Esta forma de organización es apropiada para proyectos pequeños para los cuales los requerimientos organizativos de los otros modos resultan demasiado altos.

Organización matricial: En este caso se introduce una línea de comando horizontal en adición a la estructura jerárquica existente. En lo referente a los contenidos del proyecto, los miembros del equipo informan a un administrador de proyecto, mientras que sus superiores inmediatos continúan siéndolo en lo respectivo a temas personales y disciplinarios. Los proyectos de este tipo son complejos y requieren de

esfuerzos sustanciales para su coordinación.

Las ventajas son que los recursos necesarios se usan únicamente cuando son requeridos. Al contrario de la organización en equipo, el administrador del proyecto tiene poder de decisión y está autorizado a impartir órdenes.

Las desventajas se deben a que los miembros del proyecto ¨sirven a dos señores¨. Pueden surgir conflictos respecto de los recursos o derivados del conflicto de órdenes, especialmente si se llevan a cabo varios proyectos al mismo tiempo.

Resumen y evaluación de la formas de organización de proyectos para procesos de migración

La tabla siguiente puede servir como guía de orientación para la selección de la forma apropiada de organización del proyecto. Sin embargo será necesaria la adaptación a las condiciones particulares de la agencia pública específica a la cual se vaya a aplicar.

Tabla 78: Resumen de las formas de organización del proyecto propuestas.

5.5.3.6 Inclusión de círculos selectos de usuarios

Dentro de los alcances de la preparación del proyecto, y dependiendo de la complejidad del proyecto de migración, deberá decidirse a nivel organizativo cuáles grupos de usuarios estarán activamente involucrados en el proyecto de migración y cuáles serán solamente informados al respecto. Esto significa que los usuarios pueden estar activamente afectados por el proceso de cambio, dependiendo de que se trate de un porceso de migración total, parcial o selectivo. Por ejemplo, si se reemplazan los servidores en el marco de un proceso de migración parcial, generalmente alcanza con informar a los usuarios, ya que la participación activa de los mismos no es necesaria en este caso. La migración de oficinas, en cambio, definitivamente necesita de la participación activa y del apoyo de los usuarios afectados.

Determinación de la situación de partida

Otro factor crucial para el éxito es el análisis preciso de la situación de partida. Esto generalmente requiere de bastante tiempo y trabajo. Además, la determinación de la situación de partida es también la base para la identificación de los requerimientos funcionales para los sistemas que serán objeto de la migración. Algunos aspectos importantes a tener en cuenta en este contexto son, por ejemplo, los siguientes:

Bases de datos y estructuras de datos

Documentos y formatos de documentos

Aplicaciones y sus interfaces

Funcionalidades disponibles

Disponibilidad de datos y aplicaciones

Contratiempos y problemas

...

Satisfacción de requerimientos funcionales

El software al que se apunta debería satisfacer (en la medida de lo posible) las funcionalidades y requerimientos existentes. Debe estar de acuerdo con estándares objetivos de evaluación. Difícilmente puede aceptarse un empeoramiento respecto de la situación de partida.

La descripción de la situación de partida es el primer paso hacia la identificación de los requerimientos funcionales. En el contexto de un examen preliminar, deben ser identificadas las demandas y requerimientos concretos aplicables a los componentes individuales, desde el punto de vista de usuarios y administradores. Estas demandas y requerimientos deben ser revisados y compilados en una lista de requerimientos o prioridades. Este procedimiento también incluye una evaluación crítica de si las funcionalidades existentes son necesarias y razonables. En particular, funcionalidades críticas faltantes o incompletas deben ser evaluadas y consideradas en el marco de los criterios de selección. La falta de funcionalidades en el entorno al que se migra puede afectar la aceptación por parte de los ususarios, dependiendo de la medida en que éstas sean críticas. Esto puede servir como base para la comparación de los componentes de software disponibles, de modo que el software al cual se migre, para una cierta demanda, pueda ser seleccionado en otra etapa.

El grado de cumplimiento de los requerimientos individuales servirá como vara de medida para el éxito global del proyecto.

Uso de valores empíricos

El uso de valores empíricos por parte de múltiples empresas públicas con proyectos de migración a Linux es otro factor clave para el éxito. Esto es aún más importante debido a que la experiencia en el área es aún relativamente limitada (desde una perspectiva histórica). El uso de la experiencia activa de un proceso piloto u otros procesos de migración y su integración a los proyectos que se planeen será beneficiosa tanto para los administradores como para los usuarios. Dentro de este contexto, es recomendable el establecimiento de una base de datos para el proyecto.

Planificación del proyecto, tiempo y recursos

Para la migración de Microsoft hacia entornos caracterizados por software libre son aplicables los métodos clásicos de trabajo en proyectos.

Plan del proyecto: El trabajo comienza por esbozar un plan para el proyecto, el cual describe el camino a seguir para la migración y puede ser entendido por terceros. Como mínimo el plan del proyecto debe contener la siguiente información: fecha límite, material y recursos humanos, participación de colaboradores externos, hitos y costes. El plan del proyecto es además la base para la administración efectiva del mismo.

Los siguientes temas deben definirse dentro del plan del proyecto:

¿Quién está involucrado? Organización del proyecto

¿Cuándo deben hacerse las cosas? Previsión en el tiempo

¿Cómo deben hacerse las cosas? Estructura del proyecto

¿Qué debe hacerse? Tareas

Para asegurar Costes

en forma rápida y segura Estrategia

el éxito del proyecto Orden pre-clarificado

Los resultados alcanzados se documentan en el manual del proyecto.

Previsión de tiempo: La previsión en el tiempo se usa para dividir el proyecto en partes detalladas. La existencia de un marco de tiempo previsto asegura la adopción de fechas y metas realistas para los bloques individuales de trabajo. El esquema de distribución de tiempo para el proyecto dependerá de la fecha de finalización definida para el mismo. Además, en la previsión de tiempo deben especificarse el comienzo, las distintas etapas a cumplir, y las fechas de terminación de los distintos bloques de trabajo. La organización temporal del proyecto también sirve de base para la administración efectiva y el seguimiento del mismo.

Plan de costes y recursos: Debe hacerse una estimación de costes a fin de establecer qué aportes (medidos en días-hombre) y que recursos serán posiblemente necesarios para alcanzar el resultado deseado. En este contexto se deben diferenciar los aportes (dependientes del contenido del trabajo) del tiempo (dependiente de la intensidad del trabajo).

En la planificación de los aportes individuales se deben tomar en cuenta los siguientes tipos de costes:

Costes personales (recursos humanos multiplicados por la tasa de coste)

Participación de la comunidad en proyectos de migración hacia entornos de software libre

Recursos para el establecimiento de entornos operativos de control

costes materiales (insumos, como por ejemplo costes de impresiones y papel)

costes de hardware (equipos o software que deban ser comprados)

Otros costes (viajes, servicios externos)

costes de compras y licencias

costes de servicios, apoyo y entrenamiento

Administración y control del proyecto

La función de control del proyecto es parte importante de la organización. El control no se limita puramente a la supervisión de costes y tiempos. Especialmente en el contexto de proyectos IT, el control no significa revisión retrospectiva sino intervención preventiva tan pronto como se prevean desviaciones de los valores planificados, con el objetivo de asegurar el cumplimiento de los propósitos del proyecto en términos de calidad y productos finales, fecha de terminación y costes del trabajo.

Documentación y certificación de calidad del proyecto

Aún durante el curso del proyecto y sobre todo después de su finalización, los pasos individuales del trabajo deben ser siempre comprensibles para terceras partes que no estuvieron involucradas en el proceso de migración. Esta es una condición previa vital para el subsiguiente mantenimiento del sistema. Los medios disponibles con propósitos de documentación son los siguientes:

Manuales de configuración

Manuales de usuario

Documentación de entrenamiento

Listas de inventario

Manual del proyecto

Bitácoras/ informes de estado

Control de calidad y/o informe de pruebas

Documentación final

La inspección de calidad no se limita al control y evaluación del diseño del sistema, sino que también debe considerar el análisis de fallos y errores potenciales así como el tratamiento de sus consecuencias durante cada una de las fases del proyecto. Este análisis de errores debe estar documentado de la misma manera que todo el resto del trabajo del proyecto.

Por ejemplo, el establecimiento de entornos de prueba dentro del marco de proyectos piloto, resutó ser un factor de éxito para asegurar la calidad de los mismos.

En los proyectos grandes, el área de certificación de la calidad global es un campo de actividad separado. Esta función puede ser ejercida por el administrador del proyecto o por un controlador del

proyecto, dependiendo de las características del proyecto determinado y de la cualificación del personal.

La siguiente ilustración muestra los pasos para el control interno de calidad.

Figura 88: Pasos en el control de calidad

Al final de cada paso o fase del proyecto, el encargado del control de calidad preparará las correspondientes listas de comprobación (check-lists) y métodos de prueba.

Dado un resultado positivo del control de calidad, se iniciará el siguiente paso. Si el resutado no está de acuerdo con los requerimientos de calidad definidos, será devuelto para rehacer. Los aspectos concretos a rehacer deberán especificarse en detalle y serán consignados en un informe de prueba. Finalmente, se convendrá en una fecha para la nueva entrega del trabajo, la cual será ingresada en el plan del proyecto.

Apoyo durante la fase operativa

Otra condición previa para garantizar el éxito de un proyecto de migración es un grado razonable de apoyo a los administradores. Sin embargo, en este punto no es posible establecer una orientación que sea generalemente válida para describir la extensión de esta necesidad. Lo importante es que se disponga de una rápida respuesta tan pronto como se identifiquen los requerimientos correspondientes. En vista de la falta de experiencia en migraciones, se necesitará el apoyo de expertos externos durante la fase de familiarización con las nuevas tareas, especialmente por parte de los administradores. Esto tiene particuar importancia si las personas involucradas tienen poca o ninguna experiencia con los nuevos sistemas (Linux, OSS). En todo caso, la mejor opción sería la disponibilidad de un experto en el lugar.

6.- Autores y contribuciones expertas

ma@es.-es

La lista en orden alfabético:

Bernd Dersch, Experto en estrategia en TI, conceptos operacionales, aplicaciones de base de datos y aplicaciones web. Ha sido Director y Autor en este proyecto.

Entre otras cosas a contribuido como autor en las discusiones técnicas de la migración del escritorio. <bernd.dersch@csar-ag.com>

Frank Gamerdinger, experto en Open Office y StarOffice, ha contribuido en las discusiones técnicas de la migración de Office. <frank.gamerdinger@sun.com>

Peter Ganten está especializado en servicios de directorio, migración de Windows basado en dominios NT a Samba y OpenLDAP bajo Linux, as well as thin clients y integración de aplicaciones Windows sobre escritorio Linux. Como autor ha estado implicado en las correspondientes secciones de esta guía de migración. <ganten@univention.de>

Birgit Gregor es experta en organización, workflow y optimización de procesos. Ella escribió la parte de los factores de sucesos críticos. <birgit.gregor@eds.com>

Roberto Herrmann está especializado en análisis económicos y administrando proyectos en TI. En este proyecto ha contribuido como autor, en la evaluación de la eficiencia económica. <roberto.herrmann@csar-ag.com>

Sebastián Hetze ha contribuido como autor, en las secciones sobre bases de datos, archivos de sistema, redes y administración de los servicios del sistema en esta guía de migración. Está especializado en bases de datos y archivos de sistema bajo Linux así como en formatos de intercambio de datos. <s.hetze@linux-ag.de>

Volker Lendecke es miembro del equipo de desarrollo del núcleo de Samba. En este aspecto ha hecho importantes contribuciones en las discusiones técnicas de los siguientes servicios de infraestructura: archivos de sistema, autentificación y servicios de impresión. <vl@sernet.de>

Gregor Lietz puso su énfasis también, en el ámbito de las arquitecturas corporativas y se ocupó en particular de alinear la eficiencia en estrategias de TI para organizaciones y corporaciones. Es miembro en la comisión de expertos SAGA del Ministerio del Interior Federal Alemán y fue responsable de la redacción del manual de migración. Como autor ha participado en varias secciones, entre otras cosas en vista de economía, así como caminos de migración y recomendaciones. <gregor.lietz@eds.com>

Michael Meskes está especializado en DBMS y particularmente en PostgreSQL y ha contribuido con las discusiones técnicas en estos aspectos. <Michael.Meskes@credativ.de>

Kurt Pfeifle está especializado en la integración de servicios de impresión en entornos heterogéneos de redes amplias y ha contribuido como autor con las discusiones de servicios de impresión. <kpfeifle@danka.de>

Dr. Klaus Schmidt es experto en infraestructura de TI y desarrollo de producto. En esta capacidad, el es, en particular, especialista en soluciones de alta disponibilidad. Ha estado implicado en las secciones correspondientes de esta guía de migración.

Holger Stautmeister es especialista en tecnologías web, contenido y conocimientos de administrador de sistemas. En esta conexión ha contribuido entre otras cosas como autor en los capitulos de migración de servidores web y aplicaciones para trabajo en grupo. <holger.stautmeister@eds.com>

Sebastián Stöcker está especializado en infraestructuras Microsoft y arquitectura de sistemas, ha escrito partes importantes de las discusiones técnicas relacionadas con los componentes de Microsoft.

Thomas Uhl trabaja en integración de sistemas abiertos, especialmente en el área del Código Abierto. Escribió partes de las discusiones técnicas de apliciones para trabajo en grupo y servicios de terminal. <thomas.uhl@to.com>

7 Abbreviations

ACE Access Control Entries (Entradas de Control de Acceso)

ACL Access Control List (Lista de Control de Acceso)

AD Active Directory (Directorio Activo)

ADAM Active Directory Application Mode (Modo de Aplicación del Directorio Activo)

ADC Active Directory Connector (Conector Activo de Directorio)

ADO ActiveX Data Objects (Objetos de Datos Actives)

ADS Active Directory Service (Servicio Activo de Directorio)

ADSI Active Directory Service Interface (Servicio de Interface de Directorio Activo)

AFS Andrew File System (Archivos de Sistema Andrew)

API Application Programming Interface (Interface de Programación de Aplicaciones)

APOP Authenticated Post Office Protocol (Protocolo Autentificado de Envio de Correo)

APT Advanced Package Tool (Paquete de Herramientas Avanzado)

ASCII American Standard Code for Information Interchange (Código Estandar Americano para Intercambio de Información)

ASF Apache Software Foundation (Fundación Apache Software)

ASP Active Server Pages (Servidor de Páginas Activas)

BB Bulletin Boards (Tablón de Boletines)

BDC Backup Domain Controller (Controlador de Backup de Dominio)

BfD The Federal Data Protection Commissioner (Comisión de Protección de Datos Federal)

BHO Federal Budget Code ()

BIND Berkeley Internet Name Domain (Nombre de Dominio de Internet de Berkeley)

BMI Federal Ministry of the Interior (Ministerio del Interior Federal)

BSD Berkeley Software Distribution (Distribución de Software de Berkeley)

BSI German Federal Office for Information Security (Oficina Federal Alemana para la Seguridad de la Información)

BVA Bundesverwaltungsamt

CA Certification Authority (Autoridad de Certificación)

CDO Collaboration Data Objects (Colaboración de Objetos de Datos)

CGI Common Gateway Interface (Interfaz de Entrada Común)

CIFS Common Internet File System (Archivos de Sistema de Internet Comunes)

CIM Common Information Model (Modelo de Información Común)

CIS COM Internet Service (CIS COM Servicio de Internet)

CLR Common Language Runtime (Lenguaje Común de Activación)

cn commonName (Nombre Común)

CO Crossover Office ()

COM Component Object Models (Modelos de Objetos de Componentes)

COM+ Component Object Models (Modelos de Objetos de Componentes)

CORBA Common Objects Request Broker Architecture (

COLS Commercial Linux Software (Software Linux Comercial)

CPU Central Processing Unit (Unidad Central de Proceso)

CSS Cascading Style Sheets (hojas de Estilo en Cascada)

CUPS Common UNIX Printing System (Sistema de Impresión Común UNIX)

DACL Discretionary Access Control List

DAV Distributed Authoring and Versioning

DBMS Database management system (Sistema de Administración de Base de Datos)

dc domainComponent (Componente de Dominio)

DCOM Distributed Component Object Models (Componentes de Mdelos de Objetos Distribuidos)

DDE Dynamic Data Exchange (Intercambio de Datos Dinámico)

DDNS Dynamic DNS (DNS Dinámica)

DFS Distributed File System (Archivos de Sistema Distribuidos)

DHCP Dynamic Host Configuration Protocol (Protocolo de Configuración de Host Dinámico)

DLC Data Link Control (Control de Enlace a Datos)

DLL Dynamic Link Libraries (Enlace a Librerias Dinámicas)

DMS Document management system (Sistema de Administración de Documentos)

DNS Domain Name Server (Servidor de Nombres de Dominio)

DNSSEC Domain Name System Security (Servidor de Nombres de Dominio Seguro)

DRBD Distributed Replicated Block Device

DS Directory Service (Servicio de Directorio)

DSO Dynamic Shared Objects (Objetos Dinámicos Compartidos)

DTD Document Type Definition (Definición de Tipode Documento)

DTS Data Transformation Services (Servicios de Transformación de Datos)

E2K Exchange 2000

EFS Encrypting File System (Sistema de Ficheros Encriptado)

EJB Enterprise Java Beans

EMF Enhanced Meta Format

ESC/P	Epson Printer Language (Lenguaje de Impresoras Epson)

EXT2	Extendend Filesysten Version 2 (Sistema de ficheros extendido version 2)

EXT3	Extended Filesystem Version 3 (Sistema de ficheros extendido version 3)

FAT	File Allocation Table (Tabla de localizacion de Ficheros)

FQDN	Full Qualified Domain Name (nombre calificado completo de dominio)

FRS	File Replication Service (Servicio de replicacion de ficheros)

FSG	Free Standard Group (Grupo de estandares libres)

FSMO	Flexible Single Master Operation ()

FTP	File Transfer Protocol (Protocolo de transferencia de ficheros)

GC	Global Catalog (Catalogo Global)

GDI	Graphics Device Interface (Dispositivo de Interface Grafica)

GNOME	GNU Network Object Model Environment (Ambiente de modelacion de objetos de red GNU)

GNU	GNU's Not UNIX (GNU no es Unix)

GPL	General/Gnu Public License (Licensia Publica General)

GPOs	Group Policy Objects (Objetos de Politicas de grupos)

GPS	Global Positioning System (Sistema de posicionamiento global)

GUID	Global Unique Identifier (Identificador unico global)

HACMP	High Availability Cluster Management Protocol (Protocolo de administracion de clusters de alta disponibilidad)

HD	Harddisk (Disco Duro)

HIS	Host Integration Server ()

HP	Hewlett-Packard ()

HSM	Hierarchical Storage Management ()

HTML	Hypertext Markup Language (Lenguaje de etiquetas de hipertexto)

HTTP	Hypertext Transfer Protocol (Protocolo de transferencia de hipertexto)

HTTPS	Hyper-Text Transfer Protocol Secure (Protocolo seguro de transferencia de hypertexto)

ICA	Independent Computing Architecture ()

IDE	Integrated Development Enviroment (Ambiente de desarollo integrado)

IEAK	Internet Explorer Administration Kit (Kit de adminstracion de Internet Explorer)

IETF	Internet Engineering Task Force (Fuerza de trabajo de Ingenieria de internet)

IIOP	Internet Inter-ORB Protocol ()

IIS	Internet Information Server (Servidor de Informacion de internet)

IMAP4	Internet Mail Access Protocol 4 (Protocolo de acceso al correo de internet version 4)

IMAPS	Internet Mail Access Protocol Secure (Protocolo Seguro de acceso al correo de internet)

IPC	Interprocess Communication (Comunicacion interprocesos)

IPP	Internet Printing Protocol (protocolo de impresion sobre internet)

Ipsec	Internet Protocol Security Protocol (protocolo seguro de internet)

IPv6	IP Version 6 (Protocolo de internet version 6)

IPX	Internet Packet Exchange (Intercambio de paquetes entre redes)

IRC	Internet Relay Chats ()

IS	Information Store (Almacenamiento de informacion)

ISA	Internet Security and Acceleration (Servidor de seguridad y aceleracion de internet)

ISAPI	Internet Service Application Programming Interface (interface de programacion para aplicaciones de servicios de internet)

ISC	Internet Software Consortium (Consorcio de software de Internet)

IT-WiBe	Recommendations on economic efficiency assessments for IT

systems at the federal administration ()

J2EE	Java 2 Enterprise Edition (Edicion empresarial de Java2)

J2SE	Java 2 Standard Edition (Edicion estandard de Java2)

JAXP	Java API for XML (API de java para XML)

JDBC	Java Database Connection (Conector de java para base de datos)

JFS	Journaled File System (Sistema de ficheros con journal)

JIT	Just In Time (Justo a tiempo)

JMC	Java Message Service (Servicio de mensajes Java)

JNDI	Java Naming and Directory Interface (Interface de nombres y directorios de Java)

JRE	Java Runtime Environment (Ambiente de ejecucion de Java)

JRMI	Java Remote Methode Invocation (invocacion a metodos remotos de java)

JSP	Java Server Pages (Servidor de Paginas Java)

JTA	Java Transaction API (API de transacciones Java)

JVM	Java Virtual Machine (Maquina Virtual de Java)

KBSt	Co-ordinating and Advisory Agency of the Federal Government

for Information Technology in the Federal Administration(Agencia federal de Coordinacion y alertas patra tecnologias de la informacion de la administracion Federal)

KDC	Key Distribution Center (Centro distribuidor de claves)

KDE	K Desktop Environment (Ambiente de escritorio K)

KMS	Key Management Server (Servidor de administracion de claves)

LAMP	Linux, Apache, MySQL, PHP

LAN	Local Area Network(Red de area local)

LANANA	Linux Assigned Names and Numbers Authority (Autoridad de asignacion de nombres y numeros de linux)

LDAP	Lightweight Directory Access Protocol (Protocolo liviano de acceso a directorio)

LDIF	LDAP Data Interchange Format (Formato de intercambio de informacion de datos Ldap)

LGPL	Lesser General Public License ()

Li18nux	Linux Internationalization Initiative (Iniciativa de internacionalizacion de linux)

LM	LAN Manager (Administrador de red)

LMRepl	Directory replication service (Servicio de replicacion de directorios)

LPD	Line Printing Daemon (Demonio de impresion en linea)

LPI	Linux Professional Institute (Instituto profesional de linux)

LPR	Line Printing Redirector (Redirector de impresiones en linea)

LSB	Linux Standard Base (Base estandard de linux)

LTSP	Linux Terminal Server Project (Proyecto de servicios de terminal en Linux)

LVM	Logical Volume Manager (Administrador de volumenes logicos)

LVS	Linux Virtual Server (Servidor virtual de linux)

MAC	Media Access Control (Control de acceso al medio)

MAPI	Messaging Application Programming Interface (Interface de programacion para mensajes)

MD	Man-day (hombre-dia)

MDX	Message Digest X ()

MLP	Message/Multilayer Link Protocol (Protocolo de enlaces de mensaje/Multicapas)

MMC	Microsoft Management Console (Consola de administracion de Microsoft)

MMQS	Microsoft Message Queue Server (Servidor de colas de mensajes de microsoft)

MOM	Microsoft Operation Manager (Servidor de operaciones de microsoft)

MPL	Mozilla Public License (Lisencia publica de mozilla)

MRTG/RRD	Multi Router Traffic Grapher/Round Robin Database (graficas de trafico e mltiples rutas)

MS	Microsoft

MSMQ	Microsoft Message Queuing (Coola de mensajes de Microsoft)

MSPS	Microsoft Proprietary Standards (Estandares propietarios de microsoft)

MTA	Message Transfer Agent (Agente transmisor de mensajes)

MTBF	mean time between failure ( tiempo entre fallas)

MTS	Microsoft Transaction Server (Servidor de transacciones de microsoft)

MTTR	Mean Time To Repair (tiempos de reparacion)

NAS	Network Attached Storage (Almacenamiento adjunto a la red)

NAT: Network Address Translation o traducción de direcciones de red.

NCSA National Center for Supercomputing Application, o centro nacional para la aplicación de superordenadores

NetBEUI NetBIOS Extended User Interface, o interfaz de usuario ampliada para NetBIOS

NetBIOS Network Basic Input and Output System, o sistema básico de entrada y salida en red

NetBT NetBIOS over TCP/IP, o NetBIOS sobre TCP/IP

NFS Network File System, o sistema de archivos de red

NIS Network Information Service, o servicio de información de red

NNTP Network News Transport Protocol, o protocolo de transporte de noticias por la red

NPL Netscape Public License, o licencia pública de Netscape

NTDS NT Directory Service, o servicio de directorios NT

NTFS NT File System

NTFS4 NT File System 4

NTFS5 New Technology File System 5

NTLM Windows NT LAN Manager

NTLMv2 Windows NT LAN Manager Version 2

NTP Network Time Protocol, o protocolo de tiempo en la red

ODBC Open Database Connectivity, o conexiones con bases de datos abiertas

OLAP Online Analytical Processing, o impresión analítica en línea

OLE Object Linking and Embedding, o incrustación y enlazado de objetos

OMG Object Management Group, o grupo de gestión de objetos

OOo OpenOffice.org

OOo/SO Open Office.org/StarOffice

OpenLDAP Directory service, o servicio de directorios

OSI Open Systems Interconnection, o interconexión de sistemas abiertos

OSOS Open Standards mit Open Source, o estándares abiertos con código abierto

OSS Open Source Software, o software de código abierto

OU Organizational Unit, o unidad organizativa

OWA Outlook Web Access

PAM Pluggable Authentication Module, o módulo conectable de autenticación

PBS Portable Batch System, o sistema adaptable de lotes

PCL Printer Control Language, o lenguaje de control de impresoras

PDA Personal Digital Assistant, o asistente personal digital

PDC Primary Domain Controller, o controlador principal del dominio

ABREVIATURAS

Versión: 29.08.2003 Página 383

PDF Portable Document Format, o formato de documento portátil

Perl Practical Extraction and Report Language, o lenguaje Perl de extracción práctica e informes

PHP PHP Hypertext Pre-processor, o preprocesador de hipertexto

PIM Personal Information Manager, o gestor de información personal

PKI Public Key Infrastructure, o infraestructura de clave pública

POP3 Post Office Protocol Version 3, o versión 3 del protocolo de oficina de correos

POSIX Portable Operating System Interface for UNIX, o interfaz de sistema operativo adaptable para UNIX

PPD PostScript Printer Descriptions, o descripción de impresora PostScript

RAC Real Application Cluster, o granja real de aplicaciones

RAID Redundant Array of Inexpensive/Independent Discs, o conjunto redundante de discos asequibles/independientes

RAM Random Access Machine/Memory, o máquina/memoria de acceso aleatorio

RAS Remote Access Service, o servicio de acceso remoto

RAW Read After Write, o lectura tras actualización

RDBMS Relational Database Management System, o sistema de gestión de bases de datos relacionales

RDP Remote Desktop Protocol, o protocolo de acceso remoto

ReiserFS Reiser File System, o sistema de archivos Reiser

RFCs Request for Comments, o solicitud de comentarios

RHCE Red Hat Certified Engineer, o ingeniero de Red Hat certificado

RID Relative Identifier, o identificador relativo

RISC Reduced Instruction Set Computer, u ordenador con conjunto reducido de instrucciones

RPC Remote Procedure Calls, o llamadas de procedimientos remotos

RPM Red Hat Packet Management, o gestión de paquetes de Red Hat

S/MIME Secure MIME (Multipurpose Internet Mail Extensions), o MIME seguro (extensiones para correo electrónico multifunción)

SA System Attendant, o asistente del sistema

SACL System Access Control List, o lista de control de accesos al sistema

SAGA Standards and Architectures for e-government Applications, o estándares y arquitecturas para aplicaciones de gobierno electrónico

SAM Security Accounts Manager, o gestor de cuentas de seguridad

SAN Storage Area Network, o red de área de almacenamiento

SASL Simple Authentication and Security Layer, o capa simple de autenticación y seguridad

SC Samsung Contact

SCM Security Configuration Manager, o gestor de configuraciones de seguridad

SCSI Small Computer System Interface, o interfaz de pequeños sistemas informáticos

Abreviaturas

Página 384 Versión: 28.09.2003

SFU Service for UNIX, o servicio para UNIX

SID Security Identifier, o identificador de seguridad

SISL Sun Industry Source License, o licencia para código fuente industrial de Sun

SLAs Service Level Agreements, o acuerdos a nivel de servicios

SMB Server Message Block, o bloque de mensajes de servidor

SMS Short Message Service, o servicio de mensajes cortos

SMS System Management Server, o servidor de gestión de sistemas

SMTP Simple Mail Transfer Protocol, o protocolo simple de transferencia de correo

SNA Storage Network Attached, o conexión a red de almacenamiento

SNMP Simple Network Management Protocol, o protocolo simple para la gestión de redes

SO StarOffice

SOAP Simple Object Access Protocol, o protocolo simple de acceso a objetos

SPM Standard TCP/IP Port Monitor, o monitor estándar de puertos TCP/IP

SPX Sequenced Packet Exchange, o intercambio secuencial de paquetes

SQL Structured Query Language, o lenguaje estructurado de búsquedas

SQL-DMO SQL Distributed Management Objects, u objetos de gestión distribuida mediante SQL

SRS Standard Replication Service, o servicio de réplica estándar

SSH Secure Shell, o intérprete de comandos seguro

SSL Secure Sockets Layer, capa de comunicaciones seguras

SSL/TLS Secure Sockets Layer / Transport Layer Security, o capa de comunicaciones seguras / seguridad a nivel de transporte

SW Software, o programas

TB Terabyte

TCL Tool Command Language, o lenguaje de órdenes para herramientas

TCO Total Costs of Ownership, o coste total de propiedad

TCP/IP Transmission Control Protocol / Internet Protocol, o protocolo de control de transmisiones / protocolo de Internet

TDS Tabular Data Stream, o secuencia de datos tabulados

TGS Ticket Granting Service, o servicio de seguridad de registros

TGT Ticket Granting Ticket, o regsitro de seguridad de registros

TTS Trouble Ticket System, o sistema de regsitro de incidencias

UDDI Universal Description, Discovery and Integration, o descripción, descubrimiento e integración universal

UDP User Datagram Protocol, o protocolo de datagramas de usuario

UHD User Help Desks, o centro de ayuda para usuarios

UNC Uniform Naming Convention, o convención de nombres uniformes

ABBREVIATIONS

Versión: 29.08.2003 Página 385

UNO Universal Network Objects, u objetos de red universales

URL Uniform Resource Location, o ubicación de recursos uniforme

USB Universal Serial Bus, o bus en serie universal

USN Unique Sequence Number, o número único de secuencia

VBA Visual Basic for Applications, o Visual Basic para aplicaciones

VBS Visual Basic Scripting Edition, o edición de scripts de Visual Basic

VBScript Visual Basic Script, o script de Visual Basic

VFS Virtual File System, o sistema de archivos virtual

VLDB Very Large Database, o base de datos enorme

VPN Virtual Private Network, o red privada virtual

W2K Windows 2000

W3C World Wide Web Consortiums, o consorcio de la red mundial

WAP Wireless Application Protocol, o protocolo de aplicaciones inalámbricas

WBEM Web Based Enterprise Management, o gestión empresarial basada en la red

WebDAVS Web Document Authoring And Versioning, creación y versionado de documentos web

WINS Windows Internet Name Service, o servicio Windows de nombres de Internet

WSDL Web-Services Description Language, o lenguaje para la descripción de servicios web

WSH Windows Sripting Host, anfitrión de scripts de Windows

WWW World Wide Web, o red mundial

XFS Extended File System, o sistema de archivos extendido

XSL Extensible Style Sheet Language, o lenguaje de hojas de estilo ampliable

XML Extensible Markup Language, o lenguaje de etiquetas ampliable

YaST Yet another Setup Tool, u otra herramienta de configuración- página 386 -

Glosario

8	Glosario

ADO	ADO significa Active Data Objects (Objetos de Datos Activos) y representa una interfase de alto nivel (por ejemplo de Visual Basic) para acceso general a datos desde Micorsoft por medio de un proveedor OLE DB (por ejemplo, para SQL Serverm ODBC, Oracle, Active Directory Service – Servicio de directorio activo, etc ). ADO incluye objetos para establecer la conexión a una fuente de datos, y para operaciones de lectura, actualización, escritura y borrado.

ACL	Una Acces Control List (Lista de Control de Accesos) es una lista con privilegios de acceso. Estas listas sirven como base para controlar el acceso a los recursos del sistema de IT, El sistema usa las ACLs para decidir que acceso tiene un usuario a un recurso, como ser un directorio.

ActiveX	Un término colectivo para una tecnología introducida por Microsoft que habilita contenidos (inter) activos en sitios web. El browser baja partes de programa Activex desde el servidor y las ejecuta en la PC del usuario. Activex fue desarrollado por Microsoft como una alternativa a los applets JAVA.

API	Application Programming Interface – Interfase para programación de aplicaciones (un interfase de programación definida que puede ser usada para integración y expansión).

ASP	“Active Server Pages” - Páginas de Servidor Activas; es el concepto de Microsoft para generar sitios web dinámicos (consultar también “JSP”) del lado del servidor (usando, por ejemplo, JavaScript o Visual Basic Script)

C#	Un lenguaje de programación orientada a objetos desarrollado por Microsoft en base a C y C++

CGI	La Interfase Común de Entrada (Common Gateway Interface) fue la primera variante de las interfases de servidores web. Practicamente todos los servidores web modernos soportan esta interfase. Las aplicaciones que usan CGI pueden ser desarrolladas en diferentes lenguajes de porgramación. Además de lenguajes interpretados, como PERL, también es posible utilizar aplicaciones compiladas que hayan sido escritas en C o C++.

COM	El Modelo de Objetos de Componentes(Component Object Model) es un estándar de software de Microsoft que habilita la comunicación entre procesos y programas. Para este propósito, COM define una interfase orientada a objetosque un porgrama o componente de software utiliza para hacer los servicos disponibles.

CORBA	CORBA significa Arquitectura de Intermediario Común para Requisición de Objetos (Common Object Request Broker Arquitecture) y fue desarrollada con el objeto de habilitar la comunicación entre aplicaciones independientemente de la ubicación, plataforma e implementación. CORBA es un estándar abierto definido por el Object Management Group – Grupo de Gerenciamiento de Objectos (OMG)

DCOM	El Modelo de Objetos de Componentes Distribuidos (Distributed Component Object Model) es una variante del estándar COM de Microsoft. DCOM puede usarse para la distribución de servicos de un software. DCOM utiliza RPC (Remote Procedure Calls – Llamada a Procedimientos Remotos) para la implementación con el fin de llamar procesos en una computadora remota por medio del intercambio de mensajes.

- página 387 -

DDE	El Intercambio de Datos Dinámico (Dynamic Data Exchange) es un procedimiento bajo Windows que permite a los porgramas de usuario intercambiar datos. El intercambio de datos en si mismo es un proceso dinámico. Si un archivo conectado por DDE es cambiado, el cambio es automáticamente transferido a todos los archivos comunicados con el archivo involucrado.

DHCP	El Protocolo de Configuración Dinámica de Anfitrión (Dynamic Host Configuration Protocol) crea las bases para la asignación dinámica de direcciones IP. El cliente DHCP dinámicamente recibe una dirección IP desde un servidor DHCP central. Además de la dirección IP, otros parámetros de configuración pueden ser enviados al cliente.

DNS	El Sistema de Nombres de Dominio (Domain Name Server) es un sistema con una estructura jerárquica para la asignación de nombres a las computadoras conectadas a Internet/Intranet.

DTD	Las Definiciones de Tipo de Documento (Document Type Definitions) definen formalmente al estructura de un docuemnto XML. Determinan la sintáxis que se aplica a un tipo de documento particular (y por lo tanto a un formato de datos particular).

Emulación	La capacidad de de un sistema o programa para simular la operación de otro sistema de computación utilizando recursos de hardware o software.

Failover	Esta es una característica específica de software o hardware, por ejemplo de una base de datos, servidor o red, que se configura en una forma que sus servicios se inician automáticamente por un sistema con funciones idénticas o similares en el caso de una falla temporal de sistema.

HTML	Lenguaje de Marcas de Hipertexto (Hypertext Markup Language) – Es el estándar abierto y el formato de archivo para la presentación de contenidos en Internet e Intranets.

HTTP	Un estándar para interacción electrónica durante la transmisión de documentos web en Internet.

IMAP	El Protocolo de Acceso a Correo de Internet (Internet Mail Access Protocol) puede ser usado para administrar casilla de e-mail. A diferencia de POP3, IMAP administra los e-mails en el servidor. Cuando el porgrama de correo comienza, solo los datos de encabezado (remitente, referencia y fecha de recepción) se carga por defecto. El receptor puede entonces seleccionar los mails a bajar en forma completa. Los correos que quedan en el servidro puedens er archivados en carpetas especiales.

IPSec	Un estándar para soluciones de seguridad en redes que es particularmente adecuada para la implementación de VPNs y para acceso remoto a redes privadas por medio de conexiones telefónicas.

Ipv6	La nueva versión 6 del Protocolo de Internet (IP) con direcciones IP de 128 bits en lugar de los 32 bits de Ipv4. Esto puede crear más opciones de direccionamiento para sitios web.

- página 388 -

IPX	Un estándar para la transmisión de datos definido por Novell.

Java	Un lenguaje de programación desarrollado por SUN Microsystems que es usado especialmente en el campo de la tecnología de Internet. Un asi llamado compilador traduce el texto fuente a código intermedio independiente de la plataforma. El código intermedio entonces puede ser ejecutado por un interprete adecuado en cualquier computadora. Esto permite la ejecución de programas Java en cualquier plataforma de computación para la que exista el programa interprete adecuado.

Java Beans	Los Java Beans son componentes de software reusables implementados en Java.

JavaScript	Un lenguaje de script originalmente definido por Netscape para conectar código de programa a páginas HTML estáticas. El código es generalmente ejecutado en el browser del usuario.

JDBC	La Conectividad a Base de Datos Java (Java Database Conectivity) ofrece un mecanismo para comunicarse con las bases de datos existentes. Los drivers sirven como la interfase entre el porgrama Java y la base de datos.

JSP	Las Páginas de Servidor Java (JavaServer Pages) son archivos HTML con código de programa Java embebido que se convierte en servlets por un motor JSP que son luego ejecutados en el servidor web. El resultado se envia luego en formato HTML normal al cliente (consultar también “ASP”).

LAMP	Un plataforma de software libre para desarrolladores web y aplicaciones web basado en Linux, Apache, MySQL y PHP y/o PERL o Python.

LDAP	El Protocolo Liviano de Acceso a Directorio(Lightweight Directory Access Protocol) (X.509) es una versión simplificada de DAP (X.500). LDAP se usa para acceder a servicios de directorio que pueden, por ejemplo, ser usados para consultar características de los usuarios.

Macro	Una combinación de instrucciones individuales y/o una secuencia de comandos y procesos que pueden ser grabados y guardados. Cuando se llama una macro, los procesos y acciones se ejecutan automáticamente en el orden correcto.

MP3	Un formato estándar para archivos de audio comprimido que fue desarrollado por el Instituto Fraunhofer dentro del marco de MPEG que se volvió particularmente popular en Internet.

MTA	Un componente de software responsable de la distribución de e-mails entre diferentes sistemas de computación. Un MTA recibe mensajes de otros MTAs y de MUAs y los pasa a los correspondientes recipientes.

MUA	El Agente de Usuario de Correo (Mail User Agent) es el programa de e-mail que permite a los usuarios acceder, mostrar, leer, editar y adminitrar mensajes electrónicos.

.NET	Una plataforma para servicios web basados en XML de Microsoft. La plataforma se diseño para conectar información, dispositivos y usuarios de forma uniforme y personalizada.

NTP: El Protocolo de Tiempo en Red (Network Time Protocol) se emplea para sincronizar la información horaria de diferentes ordenadores usando la red. NTP permite sincronizar los ordenadores al orden de milisegundos. Esto es un aspecto particularmente importante para procesos en los que están involucrados varios ordenadores a la vez.

ODBC: Conectividad a Bases de Datos Abierta (Open DataBase Access). Es un proceso de estandarización del acceso a bases de datos. Las aplicaciones, por ejemplo, pueden usar ODBC para acceder a un gran número de bases de datos de diferentes fabricantes.

OLE: Enlazado e incrustación de objetos (Object Linking and Embedding). Es un método para la compartición de información. Esta información puede estar representada en diferentes formatos y puede haber sido generada por diferentes aplicaciones. Los datos de un documento fuente se enlazan o incrustan en un documento destino. Cuando se marcan los contenidos en el documento destino, la aplicación origen se ejecuta, por lo que los datos pueden editarse utilizando las herramientas disponibles en el entorno original. Otro término empleado es “OLE Compound Documents” (Documentos Compuestos de OLE).

OSI: Interfaz de Sistemas Abiertos (Open Systems Interface). Un estándar internacional para el intercambio de datos en redes. El estándar OSI está compuesto por siete capas, que describen los procesos individuales de la comunicación.

PDF: Formato de Documento Portable (Portable Document Format). Un formato de documento legible en varias plataformas, desarrollado por Adobe Systems, que permite la generación y presentación de documentos formados por texto, imágenes y dibujos.

Perl: Lenguaje Práctico de Extracción e Informe (Pratical Extraction and Report Language). El lenguaje Perl está disponible de manera libre y está ampliamente utilizado en la escritura de scripts CGI. Gracias a la cantidad de opciones, especialmente en el tratamiento y procesado de cadenas de texto, los programas Perl también se emplean en tareas rutinarias de administración.

PHP: Preprocesador de Hipertexto (Hypertext Preprocessor). Lenguaje de script del lado servidor para la generación de contenido dinámico y acceso a bases de datos.

POP3: Protocolo de Oficina de Correos (Post Office Protocol). Cuando se emplea la versión 3 de este protocolo de correo electrónico, el cliente de correo descarga todos los nuevos mensajes desde el servidor de correo a la máquina local. Los clientes suelen estar configurados para eliminar los mensajes del servidor una vez se han descargado correctamente.

POSIX: Una interfaz estandarizada estilo UNIX, de acuerdo a IEEE, que está soportada por todos los derivados de UNIX.

PostScript: un lenguaje de descripción de páginas desarrollado por Adobe para controlar las impresoras. Las impresoras que admiten PostScript reciben los comandos de impresión desde los programas en forma de una secuencia estandarizada de instrucciones, que la impresora interpreta y traduce a un proceso de impresión.RAS: Servicio de acceso remoto (Remote Access Service). Microsoft utiliza este nombre para proporcionar servicios basados en llamadas de teléfono dentro del sistema operativo de Microsoft.

RDBMS: Sistema de Gestión de Bases de Datos Relacionales (Relational DataBases Management System). Los datos de una base de datos en un RDBMS se almacena en tablas, que están relacionadas unas con otras. Esta organización se basa en un modelo relacional.

Servidor: un proceso, un programa o un ordenador que procesa peticiones de clientes o que proporciona servicios que puede ser utilizados por un cliente.

SQL: Lenguaje de Interrogación Estructurado (Structured Querying Language). El lenguaje de interrogación estándar para las base de datos relacionales.

SSH: Un protocolo y la implementación (sistemas UNIX/Linux) correspondiente al protocolo, que permite el acceso seguro a ordenadores conectados a una red. La implementación permite la transmisión segura de datos a través de conexiones de red no seguras.

SSL: Capa de Sockets Seguros (Secure Sockets Layer). Una tecnología de cifrado desarrollada por Netscape y un protocolo para la comunicación segura y la transmisión de documentos entre navegadores web y servidores web.

TCP/IP: protocolo de control de la transmisión/Protocolo de Internet (Transmission Control Protocol/Internet Protocol). Un conjunto de protocolos de red que se emplean sobre una red física para ofertar a los usuarios distintos servicios. TCP e IP son las bases fundamentales para la definición de paquetes de datos, así como su envío y servicio.

UNO: Objetos de Red Universales (Universal Network Objects). UNO es un modelo de componentes que permite la interoperabilidad entre diferentes lenguajes de programación, entre diferentes modelos de objetos, entre diferentes arquitecturas de máquinas y entre diferentes procesos. Esto puede ser implementado sobre una LAN o sobre Internet. UNO está siendo desarrollado por la Comunidad OpenOffice en cooperación con los laboratorios de desarrollo de Sun Microsystems. La bibliotecas básicas de UNO son independientes de OpenOffice y StarOffice y pueden ser utilizadas como marco de trabajo para otras aplicaciones. UNO está disponible libremente bajo los términos de la licencia LGPL. Actualmente se soportan los lenguajes Java, C y C++ en Windows, Linux y Solaris (consultar también http://udk.openoffice.org/common/man/uno.html).

URL: Localizador de Recursos Universal (Universal Resources Locator). Identifica una dirección distinta en la web, como “http://www.csar-ag.com”.

VBA: Visual Basic para Aplicaciones (Visual Basic for Applications).

W3C: Este consorcio (Worl Wide Web Consortium) coordina el desarrollo de la web y la estandarización de HTML, XML y sus derivados.

WebDAV: Control de versiones y Autoría Distribuida basada en la web (Web-based Distributed Authoring and Versioning). Este protocolo es una extensión del Protocolo para la Transferencia de Hipertexto (HTTP – HyperText Transfer Protocol) y ofrece un soporte estandarizado para la una creación de contenidos asíncrona y en colaboración a través de Internet o Intranet.

_____________________________________________________________________

GLOSARIO

WINS	Un sistema de Microsoft para la resolución de nombres dentro de una red

(nombres de red <-> Direcciones IP).

XML	Una especificación en la definición de lenguajes para formatear documentos.

XML ofrece una estricta separación de contenidos y diseño

XSLT	Un lenguaje recomendado por la W3C para la creación de plantillas de estilo

que convierta estructuras-XML a otras estructuras XML en un proceso basado en

reglas, por ejemplo, desde un lenguaje de descripción de página, como es HTML.9 Tablas

Tabla 1: SuSE Linux................................................................................................................	28
Tabla 2: Red Hat......................................................................................................................	29
Tabla 3: Propiedades de los privilegios de grupo de Windows...............................................	42
Tabla 4: Atributos de Windows...............................................................................................	42
Tabla 5: Comparación de servidores de archivos....................................................................	49
Tabla 6: Comparación de sistemas de archivos.......................................................................	52
Tabla 7: Privilegios POSIX y agregaciones Windows............................................................	55
Tabla 8: Privilegios POSIX y Windows..................................................................................	56
Tabla 9: Tipos de grupos..........................................................................................................	59
Tabla 10: Conexión de clientes a CUPS..................................................................................	76
Tabla 11: Identificaciones únicas de los nombres NETBIOS..................................................	95
Tabla 12: Identificaciones con multiples valores de los nombres NETBIOS..........................	95
Tabla 13: Resumen de los tipos de registros de recursos DNS soportados.............................	96
Tabla 14: Opciones DHCP.......................................................................................................	97
Tabla 15: Comparación de los servicios de directorio.............................................................	129
Tabla 16: Comparación de J2EE y .NET.................................................................................	139
Tabla 17: Modulos Apache......................................................................................................	153
Tabla 18: Funcionalidades extendidas de Internet Information Server 5.0.............................	158
Tabla 19: Componentes que existen como objetos en MS SQL Server..................................	166
Tabla 20: Sistemas de bases de datos disponibles bajo licencia Open Source........................	171
Tabla 21: Resumen de los sistemas de bases de datos SQL....................................................	174
Tabla 22: Soluciones extendidas de Internet e intranet con MS SQL Server 2000.................	176
Tabla 23: Funcionalidades de administración y desarrollo......................................................	176
Tabla 24: Componentes basicos de Exchange 5.5...................................................................	179
Tabla 25: Seleciión de modulos de phpGroupware.................................................................	184
Tabla 26: Componentes Kolab.................................................................................................	185
Tabla 27: Exchange para componentes Linux.........................................................................	188
Tabla 28: Componentes centrales de OpenExchange Server 4................................................	191
Tabla 29: Componentes de Samsung Contact.........................................................................	195
Tabla 30: Soluciones alternativas de software de trabajo en grupo.........................................	199

Tabla 31: Matriz de compatibilidad – Exchange.....................................................................	205
Tabla 32: Versiones VBA........................................................................................................	209
Tabla 33: Extensiones de archivos de las aplicaciones más importantes de Ms Office..........	215
Tabla 34: Propiedades problematicas de Ms Office respecto a la conversión OOo/SO..........	216
Tabla 35: Comparación de plantillas y tipos de formatos disponibles....................................	217
Tabla 36: Diferencias en las funcionalidades má importantes.................................................	218
Tabla 37: Visión de conjunto de navegadores web OSS.........................................................	239
Tabla 38: Ventajas de servidores de terminales y clientes ligeros...........................................	255
Tabla 39: Desventajas principales de servidores de terminales y clientes ligeros...................	255
Tabla 40: Requerimientos de un sistema HA..........................................................................	263
Tabla 41: Resumén de niveles de abstracción.........................................................................	264
Tabla 42: Visión de conjunto...................................................................................................	267
Tabla 43: Comparación de costos del usuario para migración completa / continua................	284
Tabla 44: Distribución de costos de una “migración completa” de agencias publicas............	285
Tabla 45: Costo total por usuario en caso de una migración completa...................................	285
Tabla 46: Costo total por usuario en caso de una migración continua...................................	286
Tabla 47: Costo total por usuario en caso de una migración selectiva...................................	287
Tabla 48: Distribución del costo de la migración....................................................................	287
Tabla 49: Costo total por usuario con una migración parcial en el lado servidor ...................	288
Tabla 50: Comparación de costos de una migración completa en el lado servidor.................	288
Tabla 51: Descripción del escenario de migración de Windows NT a Windows 2000...........	291
Tabla 52: Requerimientos dia-hombre en caso de migración continua...................................	292
Tabla 53: Descripción del escenario de migración de Windows NT a Linux.........................	294
Tabla 54: Requerimientos dia-hombre en caso de migración de reemplazo...........................	295

9 Tablas

Tabla 55: Requerimientos dias-hombre para migración de Exchange 5.5 a Exchange2000...	297
Tabla 56: Requerimientos dias-hombre para migración de Exchange 5.5 a SamsungContact	298
Tabla 57: Ejemplo de migración: infraestructura servidor – agencia publica pequeña...........	301
Tabla 58: Ejemplo WiBe 1, infraestructura servidor [WindowsNT / Linux], agencia publica pequeña.......................................................................................................................	302
Tabla 59: Ejemplo de migración: infraestructura de servidor – agencia publica media..........	302
Tabla 60: Ejemplo WiBe – infraestructura servidor [Windows NT / Linux], agencia publica media...........................................................................................................................	304
Tabla 61: Ejemplo de migración: infraestructura de servidor – agencia publica grande.........	304
Tabla 62: Ejemplo WiBe – infraestructura servidor [Windows NT / Linux], agencia publica grande..........................................................................................................................	306
Tabla 63: Ejemplos de migración: Office / cliente de escritorio.............................................	306
Tabla 64: Ejemplo WiBe: - Office / cliente de escritorio [Ms Office / Open Office], agencia publica pequeña..........................................................................................................	308
Tabla 65: Ejemplo WiBe: - Office / cliente de escritorio [Ms Office / Open Office], agencia publica media..............................................................................................................	309
Tabla 66: Ejemplo WiBe: - Office / cliente de escritorio [Ms Office / Open Office], agencia publica grande.............................................................................................................	310
Tabla 67: Ejemplo de migración: de Windows / Microsoft Office a Linux / Open Office.....	310
Tabla 68: Ejemplo WiBe – Windows / Office a Linux / Open Office; amortización despues de los 3 años.............................................................................................................................	311
Tabla 69: Ejemplo WiBe – Windows / Office a Linux / Open Office; amortización despues de los 5 años.............................................................................................................................	312
Tabla 70: Ejemplo de migración: mensajeria/software de grupo – agencia publica pequeña.	313
Tabla 71: Ejemplo WiBe - mensajeria/software de grupo [Exchange 5.5 a Contact], agencia publica pequeña..........................................................................................................	314
Tabla 72: Ejemplo de migración: mensajeria/software de grupo – agencia publica media...	315
Tabla 73: Ejemplo WiBe - mensajeria/software de grupo [Exchange 5.5 a Contact], agencia publica media..............................................................................................................	316
Tabla 74: Ejemplo de migración: mensajeria/software de grupo – agencia publica grande....	317

Tabla 75: Ejemplo WiBe – mensajeria/software de grupo [Exchange 5.5 a Contact], agencia publica grande.............................................................................................................	318
Tabla 76: Ejemplo: analisis de beneficios para factores de urgencia.......................................	331
Tabla 77: Ejemplo: analisis de beneficios para factores de calidad/estrategia.........................	333
Tabla 75: Sumário propuesto de formularios de organización de proyecto............................	370

10 Ilustraciones

Figura 1: Vista del sistema – situación inicial.........................................................................	19
Figura 2: Vista del sistema – migración de reemplazo............................................................	22
Figura 3: Vista del sistema – migración continua....................................................................	23
Figura 4: Método U-G-L-R......................................................................................................	44
Figura 5: Método U-G-R..........................................................................................................	45
Figura 6: Entorno de impresión...............................................................................................	65
Figura 7: El proceso con el método de “apuntar e imprimir”..................................................	68
Figura 8: Imprimiendo bajo CUPS..........................................................................................	75
Figura 9: Escenario de autentificación (logon)........................................................................	88
Figura 10: Ejemplo de una estructura de dominio de NT........................................................	116
Figura 11: Ejemplo de Windows 2000....................................................................................	116
Figura 12: Ejemplo de un sitio y estructura de dominio..........................................................	118
Figura 13: Situación inicial......................................................................................................	119
Figura 14: Dominio maestro: W2K.BEHOERDE.DE.............................................................	120
Figura 15: Dominio maestro: BEHOERDE.DE......................................................................	121
Figura 16: Dominio maestro: NEU.DE....................................................................................	122
Figura 17: Dominio maestro y estructura: NEU.DE/INTRA.NEU.DE...................................	123
Figura 18: Dominio maestro: INTRA.BEHOERDE-ONLINE.DE.........................................	124
Figura 19: Dominio maestro: AMT.LOCAL...........................................................................	125
Figura 20: Migración por actualización o reorganización.......................................................	132
Figura 21: Migración ADS – actualización mas reorganización.............................................	133
Figura 22: Migración ADS – dominio nuevo más reorganización..........................................	134
Figura 23: Migración ADS – clonando usuarios y grupos......................................................	134
Figura 24: Migración ADS – mundo paralelo y recursos de migración..................................	135
Figura 25: Migración ADS – llenando el mundo paralelo con cuentas de usuarios y grupos.	136
Figura 26: Componentes del marco de trabajo .NET...............................................................	142
Figura 27: Modelo de capas de J2EE.......................................................................................	143
Figura 28: Marco de trabajo de Microsoft .NET......................................................................	146
Figura 29: Arquitectura del servidor SharePoint Portal...........................................................	162
Figura 30: Arquitectura del servidor de MS SQL Server........................................................	165

Figura 31: Arquitectura Samsung Contact...............................................................................	194
Figura 32: Entorrnos hibridos – Exchange...............................................................................	205
Figura 33: VBA en la aplicación Office...................................................................................	209
Figura 34: Opciones de expansibilidad de Office....................................................................	210
Figura 35: Mapeo de fuentes Ms Office OOo/SO....................................................................	213
Figura 36: Contenido de un archivo OOo/SO tal como lo muestra un visor de archivos ZIP	215
Figura 37: Objetos shadow en PowerPoint e Impress..............................................................	224
Figura 38: Conversor de documento: seleccionando el formato del fuente.............................	225
Figura 39: Conversor de documento: seleccionando los directorios fuente y destinos...........	225
Figura 40: Escritorio KDE – ejemplo 1...................................................................................	235
Figura 41: Escritorio KDE – ejemplo 2...................................................................................	235
Figura 42: Escritorio GNOME – ejemplo 1.............................................................................	237
Figura 43: Escritorio GNOME – ejemplo 2.............................................................................	237
Figura 44: Escritorio Windows bajo Linux utilizando Vmware..............................................	243
Figura 45: Escritorio Windows bajo Linux utilizando Win4Lin.............................................	246
Figura 46: Aplicaciones Windows en el escritorio Linux utilizando WINE...........................	249
Figura 47: Ejecutando aplicaciones X en un cliente pesado....................................................	256
Figura 48: Ejecutando aplicaciones X y Windows en un cliente ligero..................................	257
Figura 49: Cargando un sistema Linux a traves de la red........................................................	257
Figura 50: Granjas de servidores bajo Metaframe XP.............................................................	262
Figura 51: Soluciones HA........................................................................................................	266
Figura 52: Solución con heartbeat y DRDB............................................................................	269
Figura 53: Metodologia IT-WiBe............................................................................................	274
Figura 54: Matriz del costo de migración por categorias y aplicaciones.................................	279
Figura 55: Costo migración desarrollo.....................................................................................	285
Figura 56: Costos de migración por usuario............................................................................	288
Figura 57: Tipos / productos migración...................................................................................	319
Figura 58: Ejemplo de calculo de eficiencia economica de migración de Windows NT a Linux, agencia publica grande, analisis de los costos del proyecto.........................................	320

Figura 59: Ejemplo de cálculo de eficiencia económica de migración de Windows NT a Linux, gran agencia pública, análisis de valor actual neto...................................................................................320

Figura 60: Ejemplo de cálculo de eficiencia económica de migración de Windows NT a Linux, agencia pública mediana, anñalisis de los costes de proyecto..........................................................321

Figura 61: Ejemplo de cálculo de eficiencia económica de migración de Windows NT a Linux, agencia pública mediana, análisis de valor actual neto....................................................................322

Figura 62: Ejemplo de cálculo de eficiencia económica de migración de Windows NT a Linux, agencia pública pequeña, análisis de los costes de proyecto............................................................322

Figura 63: Ejemplo de cálculo de eficiencia económica de migración de Windows NT a Linux, agencia pública pequeña, análisis de valor actual neto.....................................................................323

Figura 64: Ejemplo de cálculo de eficiencia económica de migración de Windows NT a Windows 2000, gran agencia pública...............................................................................................................324

Figura 65: Ejemplo de cálculo de eficiencia económica de migración de Windows NT a Windows 2000, gran agencia pública, alternativa: leasing de Windows/Office..............................................324

Figura 66: Ejemplo de cálculo de eficiencia económica de migración de Windows NT a Windows 2000, agencia pública mediana........................................................................................................325

Figura 67: Ejemplo de cálculo de eficiencia económica de migración de Windows NT a Windows 2000, agencia pública mediana, alternativa: leasing de Windows/Office........................................325

Figura 68: Ejemplo de cálculo de eficiencia económica de migración de Windows NT a Windows 2000, agencia pública pequeña.........................................................................................................326

Figura 69: Ejemplo de cálculo de eficiencia económica de migración de Windows NT a Windows 2000, agencia pública pequeña, alternativa: leasing de Windows/Office........................................326

Figura 70: Ejemplo de cálculo de costes de proyecto, migración de Exchange 5.5 a Samsung Contact, gran agencia pública...........................................................................................................327

Figura 71: Ejemplo de cálculo de costes de proyecto, migración de Exchange 5.5 a Samsung Contact, agencia pública mediana....................................................................................................327

Figura 72: Ejemplo de cálculo de costes de proyecto, migración de Exchange 5.5 a Samsung Contact, agencia pública pequeña....................................................................................................328

Figura 73: Ejemplo de cálculo de costes de proyecto, migración de Windows NT a Linux en el servidor, gran agencia pública..........................................................................................................328Figura 74: Ejemplo de proyeccion de calculos de costos, migracion de Windows NT Server a Linux , agencia publica mediana......329

Figura 75: Ejemplo de proyeccion de calculos de costos, migracion de Windows NT Server a Linux , agencia publica pequeña......329

Figura 76: Evaluacion de modelo de urgencia y calidad para la migracion de proyectos......331

Figura 77: Toma de decisiones en migraciones a OSS....337

Figura 78: Arquitectura de sistema basada en un cliente “gordo” Linux....340

Figura 79: Arquitectura IT recomendada para agencias publicas grandes en el caso de migracion de reemplazo completa.....344

Figura 80: Campos de aplicación de los directorios de servicio usando el ejemplo de la plataforma SunOne.....345

Figura 81:Arquitectura IT recomendada para agencias publicas especializadas en el caso de migracion de reemplazo completa.....347

Figura 82:Arquitectura IT recomendada para agencias publicas pequeñas en el caso de migracion de reemplazo completa.....349

Figura 83: Situacion de inicio de una migracion continua....351

Figura 84:Variantes de reemplazo de Exchange para migraciones parciales....356

Figura 85: Migracion del Personal....361

Figura 86: Cambio de fases con migracion de personas....362

Figura 87:Modelo: Proceso de migracion gradual...363

Figura 88: Pasos para el control de la calidad....373

11 Apéndice

Apéndice WIBe (Recomendaciones de ejecucion de eficeincia economica para sistemas IT)

Resumen de recomendación de catalogos de analisis

Catalogo General de Criterios IT-WIBe21, para escenarios de migracion por el Dr Peter Rothing Organization, Projektberatun. Empfehlung zur Durchfuhrung von Wirtschaftlich keitsbetracthtungen in der Bundesverawaltung, in sbesondere beim Einsatz der IT, Version 3.0 – 2001 publicada por KBSt, Ministerio Federal del Interior, KBSt serie de publicacion , ISSN 0179-7263. volumen 52. Mayo 2001.

Catalogo especial de Criterios, IT-WIBe21, para la actualizacion y migracion de proyectos IT., por el Dr. Peter Rothig Organisations- und Projektberatung y el Profesor Dr. Detlef Leipelt, FH des Bundes fur offentliche Verwaltung – Hinweise und Empfehlungen – zur Durchfuhrung von Wirstschaftlich keitsbetrachtungen bei IT-Update- bzw, Umstellugsvorhaben auf Grundlage der IT-WIBe-97, published bu KBSt, Ministerio Federal del Interior, KBSt , serie de publicación. ISSN 0179-7263, Vol 52, Mayo 2001.

Catalogo de criterios especiales, IT-Wibe21, para objetos de migracion, compilado y seleccionado por encargo del catalogo general de criterios durante un workshop en el Ministerio Federal del Interior en cooperacion con los miembros de BSI, BVA y C_sar en Marzo 2003

Catalogo General de criterios, IT-WIBe21, para escenarios de migracion

Los criterios estan descriptos en las siguientes paginas del catalogo:

Criterio acorde a WIBE 21 para escenarios de migracion completos (color azul oscuro)

Criterio que puede ser omitido para los objetos de migración (color naranaja)198

Criterio que puede ser adoptado para la migracion de proyectos en adicion a aquellos de WIBe 21 (color celeste)

Las estructuras estan orientadas hacia WIBe21:

desarrollo/Introduccion de costos y beneficios

Costos operativos y beneficios operativos.

198 se refiere al catalogo especial de criterios para los objetos de migración.

Criterio de unrgencia

Criterio de calidad/strategia

Notas y explicaciones

11.1.2.1 Costes de desarrollo/introducción y beneficios de desarrollo

	x	b	n	Costes de desarrollo/introducción y beneficios de desarrollo
	x	b	n	Costes de desarrollo/introducción para el nuevo metodo IT
	x	b	n	Costes de planificación y introducción/desarrollo
	x		n	Costes de personal (personal propio)
	x	b		Costes de consultores externos
	x	b		Costes del medio de desarrollo
	x	b		Otros costes
	x	b		Coste de viaje (personal propio)
	x	b	n	Costes del sistema
	x	b		Costes de hardware
	x	b		Operaciones de red host/servidor
	x	b		Ordenadores para estaciones de trabajo
	x	b		Costes de software
	x	b		Costes para el desarrollo y/o adquisición de software
	x	b		Costes para la adaptación de software y/o interfaces
	#	b		Costes para la evaluación, certificación y garantía de calidad
	#	b	n	Costes de instalación
	#	b		Costes de costrucción/montaje
	#	b		Instalación de infraestructura tecnica
	#	b		Equipos y accesorios de oficinas
	#			Costes de personal para la instalación del sistema
	#	b	n	Costes de introducción del sistema
	#		n	Pruebas de sistema e integración
	x	b	n	Costes de instalación del sistema
	x	b		Inportación de los datos almacenados
	x		n	Entrenamiento inicial de usuarios y especialistas IT
	x	b	n	Otros costes de migración
	x			Desarrollo/intrucción de beneficios por el reemplazo del método anterior
	x	b		Ahorro de costes extras (evitar costes de mantenimiento/actualizacion del sistema antiguo)
	x	b		Ingresos extras (provenientes de la venta del sistema antiguo

Costes y beneficios de la operación:

Aquí va la tabla

Anotaciones relativas a los costes/beneficios de la operación:

Todos los items incluyen información de los tipos de costes y beficios mostrados en 2.1.1 y 2.4.4, por ejemplo. Esta información no es mostrada aquí por motivos de falta de espacio. APÉNDICE

11.1.2.3 Criterios de urgencia

Ítem | nota/recomendación | influye en el presupuesto |no influye en el presupuesto | descripción del criterio

3 | | | | criterios de urgencia

3.1 Urgenica en reemplazar el sistema anterior

3.1.1 Continuidad del soporte para el sistema anterior

3.1.2 Estabilidad del sistema anterior

3.1.2.1 ´Bugs´, errores, y tiempo muerto

3.1.2.2 Problemas con el servicio, ´cuellos de botella´ para el personal

3.1.3 Flexibilidad del sistema anterior

3.1.3.1 Límites de la expansión/mejoramiento

3.1.3.2 Interoperabilidad, problemas con las interfaces en el presente/futuro

3.2.3.3 Facilidad/comodidad en el uso (“user-friendliness”)

3.2 Cumplimiento de reglas y leyes de la administración

3.2.1 Cumplimiento de la ley

3.2.2 Garantía de la protección/integridad de los datos

3.2.3 Corrección de procesos de trabajo

3.2.4 Cumplimiento de tareas y recomendaciones

11.1.2.4 Criterios de calidad/estrategia

Ítem | nota/recomendación | influye en el presupuesto | no influye en el presupuesto | descripción del criterio

4 | | | | criterios de calidad/estrategia

4.1 Prioridad del proyecto IT

4.1.1. Relevancia dentro del concepto general IT

4.1.2 Integración dentro del paisaje IT de la administración federal en general

4.1.3 Efectos de seguimiento para compañeros de comunicación

4.1.4 Carácter de proyecto piloto

4.1.5 Independencia del manufacutrador

4.2 Incremento en la calidad del trabajo especializado

4.2.1 Incremento en la performance del trabajo

4.2.2 Aceleración de los procesos y procedimientos de trabajo

4.3 Control de la información a nivel administrativo/político

4.3.1 Provisión de información para quienes toman decisiones y ejercen tareas de control

4.3.2 Apoyo a procesos de toma de decisiones y liderazgo

4.4 Efectos relativos al staff

4.4.1 Atractivo de las condiciones de trabajo

4.4.2 Asegurar/intensificar la calificación

4.4.3 Diseminación/disponibilidad de entrenamiento

4.5 Efectos relacionados con la orientación ciudadana

4.5.1 Acción administrativa uniforme y estandarizada

4.5.2 Incremento en la claridad y transparencia

4.5.3 Aceleración de decisiones administrativas con repercusión en partes externas

4.5.4 Mejoramiento de la imagen

4.6 Diseminación/disponibilidad del software

4.6.1 Penetración en el mercado

4.6.2 Soporte independiente

4.6.3 Certificación de software dispinible

4.6.4 Herramientas disponibiles de administración de software

4.7 Seguridad IT

4.7.1 Seguridad de la comunicación

4.7.2 Seguridad de las aplicaciones

4.7.3 Seguridad contra fallas

4.7.4 Seguridad en la organización

4.7.5 Seguridad en las inversiones y planeamiento APÉNDICE

11.1.2.5 Notas y explicaciones

Notas:

a) En esta columna, los criterios mencionados en las ´´Hinweisen und Empfehlungen zur Durchführung von Wirtschaftlichkeitsbetrachtungen bei IT-Update- und Umstellungsvorhaben´´ auf Grundlage der IT-WiBe 97 (Recomendaciones sobre consideraciones de eficiencia económica para sistemas IT en conjunción con actualización IT y proyectos de migración) están marcados sobre la base de

IT-WiBe 97 como sigue: X = el criterio debe ser incluido, # el criterio es omitido.

b) El catálogo completo de criterios es aplicable a escenarios de migración (incluyendo, por ejemplo,

aplicaciones especializadas).

c) Los ítems en azul y en celeste son aplicables mayormente a objetos de migración.

d) Los ítems en celeste fueron agregados al catálogo para proyectos de migración en adición al

catálogo general de criterios de acuerdo a WiBe21.

e) Los ítems en naranja pueden ser omitidos en proyectos de migración, especialmente en el caso de objetos de migración o grupos de objetos de migración.

11.1.3 Catálogo especial de criterios, IT-WiBe21, para objetos de migración

Ítem | Descripción del criterio

1 | Costos de desarrollo / constos de introducción y beneficios de desarrollo / beneficios de introducción

1.1 Costos de desarrollo/introducción para el nuevo método IT

1.1.1 Costos de planeamiento e introducción/desarrollo

1.1.1.1 Costos de personal (personal propio)

1.1.1.2 Costos de asesores externos

1.1.1.3 Costos de desarrollo del entorno

1.1.2 Costos de sistema

1.1.2.1 Costos de hardware

1.1.2.1.1 Operación de servidor y network

1.1.2.1.2 Estaciones de trabajo

1.1.2.2 Costos de software

1.1.2.2.1 Costos de desarrollo y adquisición de software

1.1.2.2.2 Costos de modificación de software y/o de interfaces

1.1.2.2.3 Costos de evaluacioón, certificación y control de calidad

1.1.2.3 Costos de instalación

1.1.2.3.4 Costos de personal para instalación del sistema

1.1.3.2 Costos de introducción del sistema

1.1.3.3 Traslado de datos existentes

1.1.3.4 Entrenamiento inicial para usuarios y especialistas IT

1.1..3.5 Costos de familiarización para usuarios y especialistas IT.

APÉNDICE

Ítem | Descripción del criterio

2 | Costos y beneficios de operación

2.1 Costos de operación / ahorro en costos de operación

2.1.2 Costos prorrateados de servidor, hosts y network

2.1.2.1 Costos de operación del proceso NEW IT

2.1.2.2 Beneficios de operación por omisión de anteriores procesos IT

2.1.3 Costos prorrateados por estación de trabajo

2.1.3.1 Costos de operación de los procesos NEW IT

2.2 Costos de personal operativo / ahorros en costos de personal

2.2.2 Organización y administración del sistema

2.2.2.1 Costos operativos del proceso NEW IT

2.2.2.2. Beneficios operativos por la omisión del proceso antiguo

2.2.3 Entrenamiento y capacitación gradual

2.2.3.1 Costos operativos del proceso NEW IT

2.2.3.2 Beneficios operativos de la omisión del proceso antiguo

2.3 Costos operativos / ahorros por mantenimiento / service del sistema

2.3.1 Mantenimiento/ service del hardware

2.3.1.1 Costos operativos del sistema NEW IT

2.3.1.2 Beneficios operativos de la emisión del proceso antiguo

2.3.2 Mantenimiento / actualización de software

2.3.2.1 Costos operativos del proceso NEW IT

2.3.2.2 Beneficios opertivos de la omisión de procesos antiguos

2.3.3 Costos de reemplazos y suplementos

2.3.3.1 Costos operativos de los procesos NEW IT

2.3.3.2 Beneficios operativos de la omisión de procesos antiguos

2.4 Otros costos y beneficios operativos

2.4.2 Costos de asesores externos trabajando paralelamente

2.4.2.1 Costos operativos de procesos NEW IT

2.4.2.2 Beneficios operativos de la omisión de los procesos antiguos

2.4.4 Otros costos y beneficios operativos

2.4.4.1 Costos operativos de procesos NEW IT

2.4.4.2 Beneficios operativos de la omisión de los procesos antiguos

3 | Criterios de urgencia

Urgencia por reemplazar el viejo sistema

Continuidad en el soporte para el sistema anterior

Estabilidad del viejo sistema

3.1.2.1 ´Bugs´, errores y tiempo muerto

3.1.2.2 Problemas de service, cuellos de botella del personal

3.1.3 Flexibilidad del viejo sistema

3.1.3.1 Límites a la expansión/ mejoramiento

3.1.3.2 Interoperabilidad, problemas de interfaces presentes o futuros

3.2.3.3 Facilidad de uso

APÉNDICE

Ítem | Descripción del criterio

3.2 Cumplimiento de regulaciones y leyes administrativas

3.2.1 Cumplimiento de las leyes

3.2.2 Adecuación a la necesidad de protección y seguridad de datos

3.2.3 Corregir procedimientos y procesos de trabajo

3.2.4 Cumplimiento de requerimientos y recomendaciones

4 | Criterios de calidad/estrategia

4.1 Prioridad del proyecto IT

4.1.1. Relevancia dentro del concepto general IT

4.1.2 Integración dentro del paisaje IT de la administración federal en general

4.1.3 Efectos de seguimiento para compañeros de comunicación

4.1.4 Carácter de proyecto piloto

4.1.5 Independencia del manufacutrador

4.2 Incremento en la calidad del trabajo especializado

4.2.1 Incremento en la performance del trabajo

4.2.2 Aceleración de los procesos y procedimientos de trabajo

4.3 Control de la información a nivel administrativo/político

4.3.1 Provisión de información para quienes toman decisiones y ejercen tareas de control

4.3.2 Apoyo a procesos de toma de decisiones y liderazgo

4.4 Efectos relativos al staff

4.4.1 Atractivo de las condiciones de trabajo

4.4.2 Asegurar/intensificar la calificación

4.4.3 Diseminación/disponibilidad de entrenamiento

4.5 Efectos relacionados con la orientación ciudadana

4.5.1 Acción administrativa uniforme y estandarizada

4.5.2 Incremento en la claridad y transparencia

4.5.3 Aceleración de decisiones administrativas con repercusión en partes externas

4.5.4 Mejoramiento de la imagen

4.6 Diseminación/disponibilidad del software

4.6.1 Penetración en el mercado

4.6.2 Soporte independiente

4.6.3 Certificación de software dispinible

4.6.4 Herramientas disponibiles de administración de software

4.7 Seguridad IT

4.7.1 Seguridad de la comunicación

4.7.2 Seguridad de las aplicaciones

4.7.3 Seguridad contra fallas

4.7.4 Seguridad en la organización

4.7.5 Seguridad en las inversiones y planeamiento

Explicación de los criterios adicionales

Los criterios que han sido agregados para la evaluación de la eficiencia económica de los proyectos de migración en adición a los criterios originales contenidos en el contexto de WiBe 21 versión 3.0 así como los suplementos en forma de anotaciones y recomendaciones del 2000 .....anotaciones y recomendaciones del 2000(mirar lo anterior) . La sistemática es orientada para que el WiBe 21 se aproxime y este referido entre parentesis "()" siguiendo la descripción.

WiBe 21 capítulo 1 costes de desarrollo/beneficios

Introdución costes/beneficios (1.1)

La migración de una vista completa también incluye las aplicaciones especializadas que será necesaria para nuevos desarrollos o reprogamaciones. Estas actividades deben considerarse como "costes de desarrollo". La migración de objetos típica requiere costes de introdución, pero no de desarrollo. En orden de subrayar estas circunstancias, los criterios de "costes de desarrollo" están corregidos por el periodo de "Introdución ".

WiBe 21 cápitulo 4 calidad/criterios de estrategia

Difusión / disponibilidad de entrenamiento (4.4.3)

Este criterio dirige la difusión del entrenamiento y la disponibilidad del equipo necesario. La importancia de este criterio debe ser evaluada en términos cualitativos.

0	2	4	6	8	10
Personnel having the required skills is available on the market. Training is offered on an area-wide basis.	Personnel is available. Training is, however, of-fered at a few centers only.	Personnel is available. Training is organized mostly on an internal basis.	Personnel is available to a limited extent. Training must be organized internally.	Personnel is hardly avail-able. Training is possible to a limited ex-tent only.	The required training is not available on the market and is not offered either.

Difusión/disponibilidad de software (4.6)

Penetración en el mercado (4.6.1)

Este aspecto se refiere al mercado compartido del software usado. La penetración en un mercado en merma u obsoleto tiene el riesgo de que el software y/o su nuevo desarrollo sea discontinuo. Además, una buena penetración en el mercadoConlleva un alto grado de aceptación y/o el uso intensivo del software que promete la continuidad en la existencia del software.

Penetración en el mercado

0	2	4	6	8	10
The product is offered on an area-wide basis.	The product is available from selected dis-tributors only.	The product is offered on a regional basis only.	The product is offered on an occasional basis only.	The product is offered on a case-to-case basis only.	The product is not offered (any longer).

Soporte independiente (4.6.2)

Este criterio dirige la disponibilidad de soporte por compañias independientes para el software usado. Contra el fondo de las inversiones de protección, esto garantiza la continuidad del uso regular del software si esta epresa a largo plazo no es capaz de asegurar esto.

Soporte independiente

0	2	4	6	8	10
Support is offered on an area-wide basis.	Support is available from selected dis-tributors only.	Support is offered on a regional basis only.	Support is offered only seldom.	Support is offered on a case-to-case basis only.	Support is not offered (any longer).

Dsiponibilidad de certificados de software (4.6.3)

Este criterio dirige la cuestion de como el software es usado de acuerdo con estatutos y/o requerimientos especificos de la agencia o la industria o como tales consentimientos deben ser organizados por la propia organización del usuario. En este caso, el fabricante/proveedor del software asegura esta certificación, que no debe incurrir en costes adicionales. En el último caso, la organización del usuario debe asegurar la certificación de acuerdo a cubrir sus procesos de negocio. En este caso, la propia organización del usuario incurrira en costes que no pueden ser calculados en una base general.

Disponibilidad de certificación de software

0	2	4	6	8	10
The software is certified, and certifica-tion is re-newed on a regular basis.	The software is certified, and certifica-tion is re-newed on an occasional basis.	The software comes with once-off certi-fication.	The software comes with partial certifi-cation.	The software comes with rudimentary certification and/or rec-ommendations only.	The software is not certified. Certification is not possible either.

Disponibilidad de herramientas de administración para el software (4.6.4)

La administración de los productos software a utilizar a veces no es muy amigable o incluso puede ser complicada. Este criterio es aplicable a herramientas que realizan o soportan la administración de tablas y datos maestros. Adecuadamente, herramientas inteligentes pueden incrementar la eficiencia y calidad de la administración así como optimizar el uso de los recursos.

11.1.4.4 Seguridad en TI (4.7)

Los aspectos de “seguridad” se incluyen en parte dentro de los criterios a insistir (refiérase a “tiempo de inactividad” o “protección de datos y seguridad de los datos”). En este punto, este tema se retoma de nuevo bajo los aspectos de estrategia y calidad y se discute el acercamiento a su manejo.

Seguridad en las comunicaciones (4.7.1)

Este criterio engloba la seguridad de las comunicaciones internas y sobre todo externas. ¿Como se asegura la transmisión de datos?. ¿Se emplean protocolos de seguridad?. ¿Existen protección de las transmisiones, mecanismos de control de acceso, etc. ?.

Aplicaciones de salvaguarda/seguridad (4.7.2)

¿Puede el software ser testeado en relación a la seguridad de TI?. ¿Cuán susceptible puede ser el software a ataques externos, virus, etc.?. ¿Dispone el software de un diseño modular (separación entre programas del sistema y aplicaciones, opciones para restringir los programas de aplicación a sus funciones necesarias)?. ¿Esisten mecanismos de control de acceso?.

Fallos en la salvaguarda (4.7.3)

¿Cuán seriamente se ve afectada la salvaguarda por los fallos del sistema?. ¿Existen rutinas de recuperación?.

Administración de la seguridad (4.7.4)

¿Esiste administración de la seguridad?. ¿Existe un concepto de seguridad conocido por todos aquellos implicados en ella?. ¿Existe un proceso descriptivo para comprobaciones de seguridad y su documentación asociada?.

Investigación y planificación de la salvaguarda (4.7.5)

Este criterio cubre los efectos agregados de todos los criterios relevantes a la seguridad listados hasta ahora, y plantea la pregunta de si investigación y planes basados en esto continuarán existiendo en el futuro.

Berlecon Research, 2002

Migración por reemplazamiento completo, migración contínua completa y migración parcial.

Administración pública pequeña, mediana, grande y especializada.

En inglés “propietary”, del latín “propietario”

http://www.gnu.org/copyleft/lesser.html

http://www.opensource.org/licenses/bsd-license.html

La licencia afecta sólo al código fuente producido por UC Berkeley.

Especialmente, un estudio de funcionalidad realizado para un Ministerio Federal en 2001.

Actualmente disponible como versión beta – Aunque la Oficina Federal Alemana Cartel ya utiliza está versión en operaciones de producción.

No es fiable en algunas versiones.

Puede implementarse mediante el sistema operativo (crypto-api/loopback y cfs/rpc) para todo el sistema de ficheros o árboles parciales.

Consultar en “encriptación en XFS”.

Consultar en “encriptación en XFS”.

La compresión, a nivel del sistema de ficheros, puede realizarse mediante loopback.

Un atributo de compresión está previsto en el código de los sistemas de ficheros ext2 y ext3. Hasta el núcleo 2.2. había parches disponibles para un proyecto e2compr que, sobre estas bases, permitía la compresión transparente de ficheros utilizando distintos algoritmos. Desde el núcleo 2.4, este proyecto está discontinuado porque no existe demanda real para esta compresión. La compresión, a nivel del sistema de ficheros, puede realizarse mediante loopback.

Consultar en “compresión XFS”

Dependiendo si es 32 o 64 bits; máximo teórico en 9 exabytes; en el núcleo de Linux 2.4 limitado a 2 teras en vista del tamaño máximo del sistema de ficheros.

Dependiendo si es 32 o 64 bits; en el núcleo de Linux 2.4 limitado a 2 teras en vista del tamaño máximo del sistema de ficheros.

Dependiendo si es 32 o 64 bits; máximo teórico en 1 exabytes; en el núcleo de Linux 2.4 limitado a 2 teras en vista del tamaño máximo del sistema de ficheros.

Se han desarrollado métodos de auditoría varias veces en Linux. Uno de los proyectos iniciales ha dejado de ser actualizado desde el comienzo de 2000. El proyecto grsecurity implementa ACL's basadas en procesos en el kernel (http://www.grsecurity.net/). Esto permite auditorías completas de ficheros y otras actividades del sistema.

Ver “Auditando en XFS”

Ver “Auditando en XFS”

Aunque se representa, esta configuración no se permite porque todo el agregado “Lectura” quedaría activado.

Tanto estándares abiertos, como cerrados

Véase también http://sun.de/Produkte/software/chilisoft/

http://asp2php.naken.cc

http://jakarta.apache.org/tomcat/index.html

http://www.jboss.org

http://developer.iplanet.com/docs/migration/webserver/IIS_50.pdf

http://otn.oracle.com/tech/migration/asp/content.html

Fuente: Einführung in Microsoft SharePoint Portal Server 2001 – Whitepaper März 2001

Whitepaper alemán “ Microsoft Exchange Server – Kompatibilität mit Windows Server 2003”

Whitepaper alemán de Microsoft "Microsoft Exchange Server – Kompatibilität mit Windows

Server 2003 “ (http://www.microsoft.com/germany/library/resourcesmod/exchange+titanium+und+ windows+

server+2003.doc)

Fuente: Whitepaper alemán "Microsoft Exchange Server – Kompatibilität mit Windows Server

2003"

El visual Basic Script (VBS) no permite semejante integración

Para más información sobre el formato XML de OOo/SO, por favor dirijase a http://xml.openoffice.org (general), http://xml.openoffice.org/xml_specification_draft.pdf (technical details) y http://xml.openoffice.org/package.html (Zip file format).

http://uk.sun.com/software/staroffice/pdf/somigrationguide.pdf

Remitirse a la "Guía de Software StarOffice 6.0", página 47 "Regrabación o narración dividida".

Fuente: "Guía de Migración a StarOffice 6.0"

http://www.gnome.org/

http://www.gnu.org/

Quelle: http://vhost.dulug.duke.edu/~louie/screenshots/2.2/

Quelle: http://vhost.dulug.duke.edu/~louie/screenshots/2.2/

http://www.gnome.org

http://www.gnu.org

Fuente:http://vhost.dulug.duke.edu/~louie/screenshots/2.2/

Fuente:http://vhost.dulug.duke.edu/~louie/screenshots/2.2/

http://galeon.sourceforge.net/

http://www.konqueror.org/

http://www.mozilla.org/

http://www.mozilla.org/MPL/

http://www.opera.com/

http://www.opera.com/download/index.dml?custom=yes

http://www.ltsp.org/

http://www.gonicus.de/

http://www.univention.de

http://www.nomachine.com

Referencia al capítulo “Dimensión monetaria”, diagrama “matriz de costes de migración”

Referencia a la definición de objetos en el capítulo “Aproximación”

Aplicaciones de escritorio como objetos de migración con procesadores de texto, análisis de hojas de cálculo, gráficos y navegación por Internet como productos.

En contraste con el catálogo general de criterios, los criterios para el desarrollo han sido quitados y reemplazados por los criterios para la introducción.

IDC lo confirma en su estudio “Windows 2000 vs Linux für Unternehmensanwendungen” [Windows 2000 vs Linux para aplicaciones empresariales”], 2002, el cuál fue encargado por Microsoft.

podría ser necesario combinar agencias públicas de tamaño medio y grande y analizar loc centros de computadoras como tipos separados de agencias públicas.

Refiérase al estudio de IDC “Windows 2000 vs. Linux für Unternehmensanwendugen” [Windows 2000 versus Linux para Aplicaciones Empresariales], 2002

Los casos son, por ejemplo, concebibles en cuya migración de determinadas aplicaciones especiales no es posible, forzando por ello a una agencia pública a mantener sus sistemas Microsoft. En otros casos, las condiciones de servidor y cliente podrían requerir un cambio completo.

Dirigirse al capítulo "Recomendaciones de migración..."

Dirigirse al capítulo "Recomendaciones de tasación" y capítulos siguientes.

Agencias públicas pequeñas, medianas y grandes.

La migración de Windows NT a Windows 2000 será denominada “migración de contienuidad” en lo sucesivo.

Identificador para todos los tipos de agencia pública.

c.p. = ceteris paribus; esto es, "el resto de condiciones permanecen inalteradas". Es decir que los demás parámetros generales y sus correlaciones se mantuvieron constantes en estos ejemplos.

Véase 'Coste y beneficios del cambio a StarOffice 6.0 de Sun' 1 de julio de 2002

Referido al Ministerio Federal del interior, "Handbuch für Organisationsuntersuchungen in der Bundesverwaltung" Bonn, 5 th edition1988, pp. 23 and following

Se refiere a "Spezieller Kriterienkatalog IT-WiBe21 fr Migrationsobjekte", preparado por el proyecto de cooperación del Ministerio federal del interior, BSI, BVA and C_sar.

Se refiere a los criterios de los items 1., 1.1, y 1.1.1

La aceptación no es siempre la prioridad más importante. El tribunal de comercio ocasionalmente adopta decisiones a favor de sistemas mejores o más económicos

2004-06-09T20:00:03