Guia Libre Formatado

��

Versión 0.96 Beta - Mercosul Página 1

Guía Libre

Referencia de Migración para Software Libre del Gobierno Federal

��


Organización Coordinación • Secretaria de Logística y Tecnología de Información - SLTI Ministerio de Planeamiento,

Presupuesto y Gestión • Comité Técnico para Implementación de Software Libre - CISL Comité Ejecutivo de

Gobierno Electrónico • Comité Técnico de Sistemas Legados y Licencia de Software - CTSLL Comité Ejecutivo

de Gobierno Electrónico

Colaboración1 • Ministerio de Ciudades • Ministerio de Ciencia y Tecnología • Ministerio de Comunicaciones • Ministerio de Defensa • Ministerio de Desenvolvimiento Agrario • Ministerio de Desenvolvimiento, Industria y Comercio Exterior • Ministerio de Desenvolvimiento Social y Combate al Hambre • Ministerio de Integración Nacional • Ministerio de Medio Ambiente • Ministerio de las Minas y Energía • Ministerio de Planeamiento, Presupuesto y Gestión • Ministerio de Salud • Abogacía - General de la Unión • Agencia Nacional de Transportes Terrestres – ANTT • Controladoría - General de la Unión • Empresa Brasileña de Correos y Telégrafos – ECT • Empresa Brasileña de Investigación Agropecuaria – EMBRAPA • Empresa de Proceso de Datos de la Previdencia Social – DATAPREV • Fundación Nacional de Salud – FUNASA • Instituto Nacional de Tecnología de Información – ITI • Servicio Federal de Procesamiento de Datos – SERPRO • RADIOBRÁS • Departamento de Informática de Sistema Único de Salud – DATASUS • Comunidad Brasileña de Software Libre.

1 Instituciones con representantes en el Grupo de Trabajo de Migración para Software Libre

��


Equipo Técnico

Este es un trabajo colectivo, unión de esfuerzos de cerca de 50 personas que integran el Comité Técnico para Implementación de Software Libre, el Comité Técnico de Sistemas Legados y Licencias de Software, y la estructura de la Secretaría de Logística y Tecnología de Información.

Quedan aquí registrados los agradecimientos a cada uno, en especial, a los integrantes del Grupo de Trabajo Migración para Software Libre.

��


El presente Manual fue elaborado por grupo de trabajo interinstitucional constituido en agosto del 2.003 por deliberación conjunta de dos Comités Técnicos del Gobierno Electrónico: Implementación de Software Libre y Sistemas Legados y Licencias de Software, homologados en Decreto el día 29 de octubre de 2003 por el Presidente de la República. El Grupo tiene como objetivo principal formular orientaciones para a migración para software libre de órganos integrantes de la Administración Pública Federal, en consonancia con directrices de los comités técnicos citados.

Aunque originalmente el espectro de las actividades del grupo estuviera restricto a definiciones referentes al ambiente de estaciones de trabajo, se notó que para atender efectivamente a las demandas de los órganos sería necesario tratar la migración en todas las “capas” de los ambientes computacionales. De esta forma, los integrantes del grupo – que representan porcentual expresivo de los órganos de la Administración Pública Federal (APF) que iniciaron sus acciones de migración – se concentraron en la elaboración del presente documento, teniendo como referencia básica el Guía de IDA2 (Comunidad Europea) en su versión 023 y con base empírica en experiencias reales de migración en que los participantes de este Grupo de Trabajo estuvieron o están envueltos.

Este es el contexto general de elaboración del presente documento, que visa ser una referencia para procesos de Migración para Software Libre en el Gobierno Federal, bien como en cualquier otro nivel de gobierno o esfera de poder, que por ventura necesiten utilizar tal material como referencial o deseen planear y ejecutar sus procesos de migración con base de sustentación en casos concretos de estrategias ya implementadas.

2 Intercambio de Datos entre Administradores 3 Original disponible en http://europa.eu.int/ISPO/ida/export/files/en/1618.pdf.

��


0.1 HISTÓRICO DEL DOCUMENTO

Fecha Versión Autor Alteración 16/01/04 0.0 Secretaría de Logística y Tecnología de

Información (SLTI) Traducción al portugués de la Guía con base en las directrices de la IDA de Migraciones para Fuente Abierta – Comunidad Europea

07/04/04 0.1 8ª, 9ª, y 10ª Reunión del Grupo de Trabajo Migración para Software Libre (GT-MSL)

Alteraciones y reorganización de las Partes 1 y 2.

14/05/04 0.2 11ª, 12ª y 13ª Reunión GT-MSL Alteraciones y reorganización de las Partes 1, 2, y 3

18/05/04 0.3 Reunión del Comité Tecnológico de Implementación del Software Libre y Comité Técnico de Licencias y Legados

Alteraciones y reorganización de las Partes 1, 2, y 3

21/05/04 0.4 14ª. Reunión GT-MSL Contribución individual de cada institución colaboradora

Alteraciones y reorganización de las Partes 1, 2, y 3. Creación de la Parte 4.

01/06/04 0.5 15ª. Reunión GT-MSL. Contribución individual de cada institución colaboradora

Reorganización y alteración para el lanzamiento de la versión Beta para el V. Foro Internacional de Software Libre.

15/06/04 0.6 Conversión de la Guía para procesamiento LATEX 2.

Alteraciones y reorganizaciones de las Partes 1, 2, 3 y 4.

17/06/04 0.7 16ª. Reunión GT-MSL Reorganización y alteraciones para lanzamiento del X Congreso Nacional de Informática Pública (CONIP).

21/06/04 0.8 17ª. Reunión GT-MSL Comentarios, correcciones e inclusiones enviadas por la Comunidad Brasilera de Software Libre

23/06/04 0.9 SLTI Consolidación para Consulta Pública en el X CONIP – de acuerdo con la publicación en el D.O.U. del 18 de junio del 2004 – Aviso de consulta pública N. 02/2004.

20/07/04 0.91 SLTI Reestructuración de las partes 1 y 2. 27/07/04 0.92 SLTI Organización de las partes 1, 2, 3 y 4.

Encaminamiento al PNUD – Término de Referencia no. 110727.

19/08/04 0.93 SLTI. 18ª. Reunión GT-MSL Inclusión de las contribuciones recibidas por la Consulta Pública y por las Audiencias Públicas realizadas en Salvador, Brasilia, Belo Horizonte.

03/09/04 0.94 SLTI Inclusión de las contribuciones recibidas por la Consulta Pública, cerrada en 31/08/2004. y por las Audiencias Públicas realizadas en Curitiba, Recife y Rio de Janeiro. Ajustes en las partes 1, 2, 3, 4 y del Apéndice.

07/09/04 0.95 SLTI Lanzamiento web de la versión Ipiranga. Versión distribuida en el CD-ROM

��


Kurumin.gov. 28/09/04 0.96 SLTI Creación de la Parte 5. Ajustes,

reorganizaciones e inclusión de contenido de las Partes 1, 2, 3, 4 y Apéndice. Encaminamiento para la traducción del documento al Español.

Nota Inicial de la Comisión de Redacción

El contenido de este documento expresa la visión consensual de técnicos y gerentes de informática, que integran el Grupo de Trabajo “Migración para Software Libre” (GT-MSL), formalmente instituido en el ámbito de los Comités Técnicos Implementación de Software Libre y Sistemas Legados y Licencias de Software. Las versiones futuras serán publicadas después de finalizados los procesos de sumisión a estos Comités y al Comité Ejecutivo del Gobierno Electrónico, en la fase de consolidación. El contenido de este documento expresa la posición inicial del Gobierno Brasileño sobre el asunto.

Aunque todos los cuidados hayan sido tomados para disminuir las imprecisiones en las informaciones publicadas, puede ser que en la eventual identificación de ese tipo de ocurrencia la comisión de redacción sea informada por e-mail:

[email protected]

La comisión de redacción buscó atender a todos titulares de derechos autorales de partes de documentos originales utilizados, en especial los del Guía de IDA Versión 2, fuente primaria para la elaboración del presente texto.

Nota técnica de la edición para la Comunidad Brasileña de Software Libre (V0.5)

Esta versión Beta (0.5), abierta a la contribución de la comunidad hasta el día 19/06/04, se presenta con posibles inconsistencias técnicas, en especial desactualizaciones cuanto a estado del arte de las soluciones libres, que poseen una dinámica acelerada en su desarrollo. El equipo técnico responsable cuenta con la colaboración de la comunidad para suplir tales vacíos, originados por la complejidad e inclusión del contenido del Guía Libre.

Nota técnica para edición de Consulta Pública

Esta versión Beta (0.9), representa, además de la visión consensual del GT-MSL, las contribuciones encaminadas por la Comunidad Brasileña de Software Libre hasta el día 21/06/04 (dos días de prorrogación).

��


El encaminamiento de este documento para Consulta Pública objetiva, con las colaboraciones advenidas de la sociedad como un todo, la consolidación de los contenidos aquí registrados, los cuales pueden todavía presentar inconsistencias en su elaboración.

Creemos que, de esta manera, estamos garantizando la participación de la Sociedad en este proyecto, que juzgamos ser de importancia y de interés nacional, y aprimorando el presente trabajo.

Nota técnica para edición de la versión Ipiranga

Esta versión Beta (0.95) contempla reestructuración aprobada por el Grupo de Trabajo de Migración para Software Libre del Gobierno Federal y conjuga contribuciones sobre la versión 0.9, disponibilizada en Consulta Pública hasta el 31/08/04, encaminadas por la sociedad por medio del sitio del Gobierno Electrónico, además de las presentadas en las Audiencias Públicas realizadas en Salvador (06/08), Brasilia (12/08), Belo Horizonte (16/08), Curitiba (27/08), Recife (30/08) y Rio de Janeiro (02/09).

Esta todavía no es una versión final, y de esta forma, existe posibilidad de este documento presente

eventuales inconsistencias técnicas en alguna parte de su contenido. Algunas contribuciones, en función de su complejidad, se encuentran todavía en proceso de evaluación por el Grupo de Trabajo. Está previsto adiciones, correcciones y ajustes para la versión 1.0. Actualizaciones de este documento estarán disponibles en:

http://www.governoeletronico.gov.br/guialivre

��


0.2 DISTRIBUCIÓN

Secretaria de Logística y Tecnología de Información Versión 0.5, 0.9 y 0.95 Instituto Nacional de Tecnología de Información Versión 0.5, 0.9 y 0.95 Servicio Federal de Procesamiento de Dados – SERPRO Versión 0.95 Caixa Económica Federal – Distribución de la versión Ipiranga Versión 0.95 en el CD Kurumin.gov.

0.3 DERECHOS AUTORALES

Gobierno Brasileño – la reproducción es autorizada desde que la fuente sea reconocida, de acuerdo con las orientaciones da CC-GNU GPL4

4 GNU General Public License, cuyo contenido esta disponibilizado en el apéndice C.

��


Sumario

0.1 Histórico del documento ....................................................................................................... 5 0.2 Distribución........................................................................................................................... 8 0.3 Derechos Autorales ............................................................................................................... 8 Capítulo 1 .................................................................................................................................. 14 1. Prefacio ................................................................................................................................. 14

1.1 Abreviaturas y terminología ........................................................................................... 14 1.2 Público............................................................................................................................ 14 1.3 Autores ........................................................................................................................... 15 1.4 Agradecimientos............................................................................................................. 15

Parte I - DIRECTRICES GENERALES ................................................................................... 16 Capítulo 2 .................................................................................................................................. 17 2. El Gobierno Brasileño y la temática del Software Libre....................................................... 17

2.1 Contextualización ........................................................................................................... 17 2.1.1 Sociedad de Información ........................................................................................ 17 2.1.2 Gobierno Electrónico Brasileño.............................................................................. 18 2.1.3 Directrices del Gobierno Electrónico Brasileño ..................................................... 19 2.1.4 Padrones de Interoperabilidad del Gobierno Electrónico ....................................... 19

2.2 Software Libre en la Administración Pública................................................................. 21 2.2.1 Definiciones............................................................................................................ 21 2.2.2 Razones para adopción de Software Libre.............................................................. 21

2.3 Base de Elaboración de la Guía Libre ............................................................................ 22 Capítulo 3 .................................................................................................................................. 24 3.¿Por que el Software Libre es libre y cuáles las razones jurídicas para migración?............... 24 Capítulo 4 .................................................................................................................................. 26 4. Visión General ...................................................................................................................... 26

4.1 Introducción.................................................................................................................... 26 4.2 Consideraciones Iniciales ............................................................................................... 27

Capítulo 5 .................................................................................................................................. 31 5. Metodología .......................................................................................................................... 31 Parte II - DIRECTRICES DE GESTION.................................................................................. 34 Capítulo 6 .................................................................................................................................. 35 6. Visión General de la Migración ............................................................................................ 35

6.1 La sensibilización es el mejor comienzo ........................................................................ 35 6.2 Gerenciando la Migración .............................................................................................. 36

Capítulo 7 .................................................................................................................................. 43 7. Cuestiones Humanas ............................................................................................................. 43 Capítulo 8 .................................................................................................................................. 45 8. Facilitando la vida ................................................................................................................. 45

8.1 Introduzca aplicativos libres en ambiente propietario .................................................... 45 8.2 Haga primero las cosas fáciles........................................................................................ 45

��


8.3 Piense más allá ................................................................................................................46 P a r t e I I I - DIRECTRICES TÉCNICAS ..............................................................................48 Capítulo 9 ..................................................................................................................................49 9. Arquitectura de Referencia ....................................................................................................49

9.1 Arquitecturas genéricas...................................................................................................49 9.2 Arquitectura Básica de Referencia ..................................................................................51

Capítulo 10.................................................................................................................................53 10. Grupos Funcionales .............................................................................................................53

10.1 Sistema Operacional .....................................................................................................54 10.2 Estación de Trabajo.......................................................................................................55

10.2.1 Gerenciadores de Ventanas ...................................................................................56 10.2.2 Oficina...................................................................................................................56 10.2.3 Gerenciamento de Proyectos .................................................................................61 10.2.4 Correos ..................................................................................................................62 10.2.5 Calendarios y Groupware......................................................................................64 10.2.6 Navegador .............................................................................................................65 10.2.7 Banco de Datos Personales o Locales ...................................................................68

10.3 Servidores .....................................................................................................................68 10.3.1 Servicio de Correo.................................................................................................68 10.3.2 Servicio de Webmail .............................................................................................71 10.3.3 Servicio de Antivirus.............................................................................................72 10.3.4 Servicio de Calendario y Groupware.....................................................................73 10.3.5 Servicios de Web Servidores Web ........................................................................74 10.3.6 Servicio de Gestión de Documento .......................................................................75 10.3.7 Servicio de Bancos de Datos .................................................................................76 10.3.8 Servicios de Seguridad ..........................................................................................77 10.3.9 Servicios de Gestión..............................................................................................79 10.3.10 Servicio de Backup y Recuperación....................................................................84 10.3.11 Sistema de Lista de Discusión.............................................................................85 10.3.12 Sistemas de Informaciones Georeferenciadas .....................................................85 10.3.13 Otros servicios.....................................................................................................86

Capítulo 11.................................................................................................................................91 11. Visión General de la Migración de Aplicativo ....................................................................91

11.1 Aplicativos propietarios que poseen un software libre equivalente ..............................91 11.2 Aplicativos propietarios que operan en un ambiente software libre..............................91 11.3 Software que puede ser accesado por exhibición remota. .............................................91 11.4 Software que funcionará bajo un emulador...................................................................93

11.4.1 Emulación de hardware .........................................................................................93 11.4.2 Emulación de software...........................................................................................94

11.5 Software que puede ser recompilado en software libre.................................................98 P a r t e I V - PLANEANDO LA MIGRACIÓN.....................................................................99 Capítulo 12...............................................................................................................................100 12. Escenario 1 – Windows ®..................................................................................................100

12.1 Como Planear la Migración ........................................................................................100 12.2 Dominios ...............................................................................................................100 12.2.1 Modelo de “grupo de trabajo” del Windows ® .................................................100 12.2.2 Dominio Windows NT ®....................................................................................101 12.2.3 Domínio del Active Directory ® del Windows 2000 ® ....................................101 1.2..3 Visión general de posibles rotas de migración .....................................................102

12.4 Cuestiones Generales ..................................................................................................102

��


12.4.1 Nombres de usuarios y señas .............................................................................. 105 12.4.2 Servicios de autenticación ................................................................................ 106 12.4.3 Archivos.............................................................................................................. 106

12.5 Herramientas .............................................................................................................. 109 12.5.1 Samba ................................................................................................................. 109 12.5.2 OpenLDAP ....................................................................................................... 110 12.5.3 NSS e PAM ........................................................................................................ 110 12.5.4 Acceso a archivo GNU/Linux SMBFS............................................................... 111 12.5.5 Winbind .............................................................................................................. 111

12.6 Migrando el ambiente del sistema operacional........................................................... 112 12.6.1 Acrecentar servidores GNU/Linux individuales a um dominio Windows NT ® existente la configuración es extremamente simple: ........................................... 112 12.6.2 Ejecutar estaciones de trabajo GNU/Linux en dominios Windows NT R .......... 112 12.6.3 Ejecutar estaciones de trabajo GNU/Linux en dominios Active Directory ®..... 116 12.6.4 Sustituir el Windows NT ® PDC/BDC por Samba+LDAP................................. 116 12.6.5 Sustituir el Active Directory ® Windows 2000 ® por LDAP ............................ 117 12.6.6 Ejecutar una infraestructura GNU/Linux paralela y migrar usuarios en grupos 118

12.7 Migrando aplicativos tipo servidor............................................................................... 119 12.7.1 Servidores de la Web: cambiando del IIS para el Apache................................ 119 12.7.2 Bancos de Datos: mudando del Access ® y del Servidor SQL para el MySQL o PostgreSQL ................................................................................................................. 123 12.7.3 Groupware: mudando del Exchange................................................................... 126

12.8 Migrando aplicativos estación de trabajo para software libre .................................... 128 12.8.1 Office ® .............................................................................................................. 128 12.8.2 Correo ................................................................................................................. 131 12.8.3 Calendarios y Groupware ................................................................................... 132 12.8.4 Navegación Internet ........................................................................................... 133 12.8.5 Bancos de Datos Personales ............................................................................... 133

12.9 Migrando servicios de impresión para software libre................................................. 134 12.9.1 El modelo de impresión en el ambiente propietario............................................ 134 12.9.2 El modelo de impresión Unix y GNU/Linux ...................................................... 135 12.9.3 Configurando un servicio de impresión basado en software libre ...................... 136 12.9.4 Imprimiendo a partir de clientes propietarios para impresoras GNU/Linux anexas....................................................................................................................................... 136 12.9.5 Imprimindo esquemas de migración................................................................... 138 12.9.6 Problemas Potenciales ........................................................................................ 138 12.9.7 Informaciones adicionales sobre impresión........................................................ 139

12.10 Aplicativos legados .................................................................................................. 139 12.11 Protección antivírus .................................................................................................. 139 12.12 Referencias............................................................................................................... 140

Capítulo 13.............................................................................................................................. 141 13. Escenario 2 – Unix ........................................................................................................... 141 Capítulo 14.............................................................................................................................. 143 14. Escenario 3 – Mainframe ................................................................................................. 143 Capítulo 15.............................................................................................................................. 144 15. Escenario 4 – Cliente Leve.................................................................................................. 144 Parte V - ESTUDIOS DE CASOS.......................................................................................... 146 Capítulo 16.............................................................................................................................. 147 16. Estudios de Casos.............................................................................................................. 147 Capítulo 17.............................................................................................................................. 148

��


17. Ministerio de Desarrollo Agrario.......................................................................................148 17.1 Migración de servidores..............................................................................................148

17.1.1 Los Motivos.........................................................................................................149 17.1.2 Plan de Acción ....................................................................................................149 17.1.3 Aspectos Culturales.............................................................................................149 17.1.4 Capacitación de los Usuarios y Equipo Técnico .................................................150 17.1.5 Los Servicios de RED y Correo electrónico........................................................150 17.1.6 Customización de los Sistemas ...........................................................................151 17.1.7 Los Desafios Enfrentados....................................................................................152 17.1.8 Economía Alcanzada...........................................................................................153 17.1.9 Experiencia Adquirida.........................................................................................155 17.1.10 Resultados Positivos..........................................................................................156

Capítulo 18...............................................................................................................................157 18. Ministerio de Comunicaciones ..........................................................................................157

18.1 Plan de migración........................................................................................................157 18.1.1 Introducción ........................................................................................................157 18.1.2 Escopo .................................................................................................................157 18.1.3 Planeamiento y Ejecución ...................................................................................157

Capítulo 19...............................................................................................................................160 19. RADIOBRÁS ....................................................................................................................160

19.1 Migración de estaciones de trabajo .............................................................................160 Capítulo 20...............................................................................................................................163 20. Marina de Brasil.................................................................................................................163

20.1 Plan de migración para mainframe..............................................................................163 Capítulo 21...............................................................................................................................164 21. DATAPREV ......................................................................................................................164

21.1 Servidores de autenticación.........................................................................................164 21.2 Herramienta de control de versión ..............................................................................169

21.2.1 Introducción ........................................................................................................169 21.2.2 Resumo de la migración de los objetos ...............................................................169 21.2.3 Datos técnicos del ambiente CVS en la DATAPREV.........................................170

Capítulo 22...............................................................................................................................172 22. Embrapa.............................................................................................................................172

22.1 AgroLibre....................................................................................................................172 Capitulo 23...............................................................................................................................174 23. SERPRO ............................................................................................................................174

23.1 Gerenciamento de Redes.............................................................................................174 23.1.1 Introducción ........................................................................................................174 23.1.2 Objetivo...............................................................................................................174 23.1.3 Escenario .............................................................................................................174 23.1.4 Procesos de gerenciamento..................................................................................175 23.1.5 Procedimientos, Actividades, Herramientas y Resultados de la Gerencia de la Red Local ..............................................................................................................................177 23.1.6 Funciones de la Gerencia de Redes Locales, Competencias y Requisitos...........180

Capítulo 24...............................................................................................................................184 24.1 Migración de Red Local – servidores y estaciones de trabajo........................................184

24.1.1 Contexto – ITI y la adopción del SL ...................................................................184 24.1.2 Etapas – Plan Estratégico de Migración ..........................................................185

��


24.1.3 Detalles – Migración de la Red-ITI................................................................. 189 24.1.4 Solución Web – Sitio www.iti.br y Twiki PKI-enable ............................. 192

24.2 Resultados - Atendiendo a las Expectativas ............................................................... 193 24.2.1 Referencias - Bibliografía y Consultas ............................................................ 193 24.2.2 Conclusiones - Experiencia Adquirida y Recomendaciones ................ 195

Apendices................................................................................................................................ 196 apendice A Referencia de software libre................................................................................ 197 Apéndice B Marcas Registradas............................................................................................. 201 Apéndice C - W i n e – h i s t ó r i co ...................................................................................... 203 Apéndice D - Sistemas de Correo ........................................................................................... 205

B.1 MTA ............................................................................................................................ 207 B.2 MUA............................................................................................................................ 208 B.3 Almacenaje de Correo ................................................................................................. 208

ApÉndice E - Licencia CC-GNU GPL.................................................................................... 210 Introducción ....................................................................................................................... 210 EXCLUSIÓN DE GARANTÍA ......................................................................................... 213 FINAL DE LOS TÉRMINOS Y CONDICIONES ............................................................ 214

Apéndice F - G l o s a r i o ........................................................................................................ 216

�

��


CAPÍTULO 1

1. PREFACIO

1.1 Abreviaturas y terminología

Siempre que posible, la primera vez que se use una abreviatura, será incluida también la versión por extenso. En el Apéndice F se encuentra un glosario de términos.

Cada uno de los términos de los Software de Fuente Abierta (Open Source Software) y Software Libre (Free Software) tienen sus defensores y sus diferencias conceptuales y jurídicas. En este relato, usaremos el término Software Libre con la intención de destacar las características que lo diferencian del Software de Fuente Abierta, especialmente a su disponibilidad en la forma de Licencia Pública General (GPL).

De esta manera, los dos términos: Software de Fuente Abierta y Software Libre, serán tratados separadamente o conjuntamente, conforme la necesidad de este Guía.

Para más informaciones sobre estos términos, vea:

http://www.fsf.org/home.es.html http://www.gnu.org/philosophy/free-sw.es.html http://www.gnu.org/licenses/license-list.es.html http://www.opensource.org http://www.sourceforge.org

Nombres de productos serán presentados de esta forma: Nombre de Producto.

Términos de Sistema Operativo, como nombres de archivos, serán presentados de esta forma: Nombre de archivo.

Código de programa será presentado de esta forma: Código.

1.2 Público

Este documento es dirigido a los Gerentes de Tecnología de Información (TI) de todo el

Gobierno Federal Brasileño, en todas las esferas: ejecutivo, legislativo y judicial, sirviendo también como referencia para los gobiernos estaduales y municipales. El término Administración es usado en todo el documento con relación a la Administración Pública, y el término Administradores se refiere al grupo de gestores y implementadores anteriormente descrito.

��


1.3 Autores

El informe fue producido por el Grupo de Trabajo Migración para Software Libre, cuyas

instituciones integrantes fueron relacionadas al inicio de este documento (Página 2).

Tuvo como referencia básica la estructura y parte de los contenidos constantes en el guía “directrices

del IDA para Migraciones para Fuente Abierta”, desarrollado por la netprojetc Ltd. y Frequentous Consultants Ltd.1, para la Comunidad Europea.

1.4 Agradecimientos

El Gobierno Brasileño agradece a la Comunidad Europea por el trabajo que subsidió a la elaboración de la Guía Libre – Referencia de Migración para Software Libre, a la Comunidad Brasileña de Software Libre por las motivadoras y preciosas contribuciones, y a todos los ciudadanos y organizaciones que contribuyeron para el éxito de este proyecto.

��


PARTE I - DIRECTRICES GENERALES

��


Capítulo 2

2. EL GOBIERNO BRASILEÑO Y LA TEMÁTICA DEL

SOFTWARE LIBRE

2.1 Contextualización

En las últimas décadas del Siglo XX, la sociedad experimentó una profunda evolución tecnológica especialmente difundida por la utilización de computadoras en las más diversas áreas de actuación.

Esa evolución viene posibilitando significativas mudanzas en los escenarios sociales, políticos, económicos y culturales en todos los países, sea por el uso intensivo de las tecnologías de información, sea por el retardo de aplicación de las mismas. Aplicación ésta que delimita el grado de desarrollo de una nación.

En este contexto, el Gobierno Brasileño viene actuando en la busca de una inserción adecuada del país en la llamada Sociedad de Información.

2.1.1 Sociedad de Información Para inserción en el nuevo escenario destacado, cada país desarrolló estrategias que

consideraron su grado de desarrollo tecnológico conjugado con sus peculiaridades. En Brasil, el marco inicial de ese proceso fue la creación del programa “Sociedad de Información”, por medio del Decreto 3.294 de 15 de Diciembre de 1999, con objetivo de “viabilizar la nueva generación de la Internet y sus aplicaciones en beneficio de la Sociedad Brasileña5”, estructurado en siete líneas de acción:

• Mercado, trabajo y oportunidades; • Universalización de servicios para la ciudadanía; • Educación en la sociedad de información; • Contenidos e identidad cultural; • Gobierno al alcance de todos; • P&D, tecnologías-llave y aplicaciones; • Infraestructura avanzada y nuevos servicios.

Esa iniciativa buscó ofrecer “subsidios para definición de una estrategia para concebir la inserción adecuada de la sociedad brasileña en la Sociedad de Información6”.

5 “El objetivo del Programa Sociedad de Información es integrar, coordinar y fomentar acciones para la utilización de tecnologías de información y comunicación, de forma a contribuir para que la economía del país tenga condiciones de competir en el mercado global y, al mismo tiempo, contribuir para la inclusión social de todos los brasileños en la nueva sociedad” – disponible en http://www.socinfo.org.br/sobre/programa.htm. 6 Programa Sociedad de Información. Ministerio de Ciencia Tecnología. 1999. pág. 5.

��


Con tal esfuerzo, en septiembre de 2000, el Gobierno Brasileño producía, entre otros documentos, el llamado “Libro Verde”, que identificó el conjunto de las acciones establecidas para impulsar la Sociedad de Información en Brasil, contemplando: ampliación de acceso a la internet, medios de conectividad, formación de recursos humanos, incentivo a la pesquisa y desarrollo, comercio electrónico y desarrollo de nuevas aplicaciones.

2.1.2 Gobierno Electrónico Brasileño

Después de la producción del “Libro Verde”, fue creado en el Ámbito del Gobierno Federal, por medio del Decreto de 18 de octubre de 2000, el Comité Ejecutivo de Gobierno Electrónico, con objetivo de formular políticas, establecer directrices, coordinar y articular las acciones de implantación del Gobierno Electrónico, hacia la prestación de servicios e informaciones al ciudadano7 .

El Gobierno Electrónico fue concebido como un instrumento de transformación de la sociedad brasileña, estableciendo directrices y parámetros para la creación de una sociedad digital.

Con el pasar del tiempo, la llamada Sociedad de Información presentó nuevos paradigmas que merecerían igualmente la atención del Gobierno Electrónico. Las cuestiones relativas a la Inclusión Digital, que amplían la dimensión de la participación del ciudadano en las relaciones con el Gobierno, otras entidades y sus pares, y expanden los mercados en la economía virtual, presentaron nuevas vertientes relacionadas8:

• Inclusión digital orientada hacia la ciudadanía – con base en el derecho de interacción y de

comunicación de los individuos por medio de las redes de información. • Inserción de los estratos más pobres en el mercado de trabajo – con base en la

profesionalización y capacitación. • Inclusión digital orientada hacia la educación – con base formación sociocultural de los

jóvenes y no fomento de una inteligencia colectiva capaz de asegurar inserción autónoma del país en la sociedad de información.

De esa forma, se hizo necesaria una rearticulación de las acciones inicialmente determinadas para una mejor adecuación del país en ese escenario. Con esa preocupación, se crearon, por medio del Decreto de 29 de octubre de 2003, comités técnicos específicos en el ámbito del Comité Ejecutivo del Gobierno Electrónico: Implementación de Software Libre, Inclusión Digital, Integración de Sistemas, Sistemas Legados y Licencias de Software, Gestión de Sitios y Servicios On-Line, Infraestructura de Red, Gobierno para Gobierno (G2G), Gestión de Conocimiento e Información Estratégica.

7 Decreto de 18 de octubre de 2000. Crea, en el ámbito de Consejo de Gobierno, el Comité Ejecutivo de Gobierno Electrónico, y da otras providencias. Mayores detalles sobre Gobierno Electrónico pueden ser obtenidos en http://www.governoeletronico.gov.br. 8 Una discusión profunda sobre esas vertientes es presentada en: SILVEIRA, Sérgio Amadeu da. Inclusión Digital, Software Libre y Globalización Contra-Hegemónica, in SILVEIRA, Sérgio Amadeu da; CASSINO, Joáo (Org.) Software libre e inclusión digital Sao Paulo, Conrad Libros, 2003. pp 17-47.

��


Con esa medida, el actual gobierno profundizó y dio nuevos focos de actuación al Gobierno Electrónico, con especial atención para Inclusión Digital e incentivo al uso de Software Libre. A cuestión del Software Libre presentó enfoque en su popularización y utilizó, con previsión de migración gradativa de los sistemas propietarios con garantía de interoperabilidad, en acciones de los Comités de Implementación del Software Libre y de Sistemas Legados y Licencias de Software.

2.1.3 Directrices del Gobierno Electrónico Brasileño

En recurrencia al Decreto del 29 de octubre de 2003, la implementación del Gobierno Electrónico pasó a ser realizada a partir de siete principios, que fueron concebidos “como referencia general para estructurar las estrategias de intervención, adoptadas como orientaciones para todas las acciones de Gobierno Electrónico, gestión do conocimiento y gestión del TI en el gobierno federal:

• Promoción de la ciudadanía como prioridad; • Indisociabilidad entre inclusión digital el gobierno electrónico; • Utilización del software libre como recurso estratégico; • Gestión del Conocimiento como instrumento estratégico de articulación y gestión de las

políticas públicas; • Racionalización de los recursos; • Adopción de políticas, normas y padrones comunes; • Integración con otros niveles de gobierno y con los demás poderes9”

En ese nuevo contexto, la actuación del Gobierno Electrónico objetiva la mejora de prestación de servicios a los ciudadanos, con aumento de la transparencia y disminución de la burocracia, contribuyendo para democratización del proceso decisorio, mayor efectividad de las acciones gubernamentales y promoción de la inclusión digital.

2.1.4 Padrones de Interoperabilidad del Gobierno Electrónico

Con la intención de crear mecanismos capaces de promover la eficiencia de la Administración Pública en el contexto de la Sociedad de Información, articulada a las acciones establecidas para implantación del Gobierno Electrónico, el gobierno brasileño elaboró un conjunto de premisas, políticas y especificaciones técnicas reguladoras para utilización de Tecnología de la Información y Comunicación, denominada arquitectura e-PING – Padrones de Interoperabilidad10 de Gobierno Electrónico.

9 Oficinas de Planeamiento Estratégico. INFORME CONSOLIDADO. Comité Ejecutivo del Gobierno Electrónico. Mayo de 2004. pág 8 10 Los conceptos de interoperabilidad adoptados en esta arquitectura están evidenciados en el Documento de Referencia disponible en http://www.eping.e.gov.br.

��


La arquitectura e-PING define un conjunto mínimo de premisas, políticas y especificaciones técnicas que reglamentan la utilización de la Tecnología de Información y Comunicación (TIC) en el Gobierno Federal, estableciendo las condiciones de interacción con los demás poderes y esferas de gobierno y con la sociedad en general, como demostrado en la figura 2.1.

La e-PING presenta, en cada uno de sus segmentos, políticas técnicas encaminadoras para

establecimiento de las especificaciones de sus componentes. En especial, e-PING define adopción preferencial de padrones abiertos, conforme especificado11:

(...) e-PING define que, siempre que posible, serán adoptados padrones abiertos en las especificaciones técnicas. Padrones propietarios son aceptos, de forma transitoria, manteniéndose las perspectivas de sustitución siempre que haya condiciones de migración. Sin perjuicio de esas metas, serán respetadas las situaciones en que haya necesidad de consideración de requisitos de seguridad e integridad de informaciones. Cuando disponibles, soluciones en Software Libre serán consideradas preferenciales.

Con esa visión, se hizo necesario la elaboración del Guía Libre: un documento de referencia para servir de auxilio en los procesos de migración para Software Libre del Gobierno Federal, de acuerdo con las orientaciones de e-PING.

Además de la preocupación en garantizar los padrones de interoperabilidad previstos, existen otras argumentaciones para adopción de Software Libre en la Administración Pública, como serán destacadas a seguir.

11 e-PING. Padrones de interoperabilidad de Gobierno Electrónico. Documento de Referencia – Versión 0 – pág. 9.

��


2.2 Software Libre en la Administración Pública

2.2.1 Definiciones

“Software Libre es el software disponible, gratuita o comercialmente, con las premisas de libertad de instalación; plena utilización; acceso al código fuente; posibilidad de modificaciones/perfeccionamientos para necesidades específicas; distribución de la forma original o modificada, con o sin costos12”. Esa definición remarca que es importante “no confundir software libre con software gratis porque la libertad asociada al software libre de copiar, modificar y redistribuir, independe de gratuidad. Existen programas que pueden ser obtenidos gratuitamente pero que no pueden ser modificados, ni redistribuidos13”.

Otro factor relevante se refiere a socialización del conocimiento. El acceso al código fuente permite que la Administración Pública tenga dominio sobre la tecnología aplicada. Esa es una preocupación recurrente, que ya fuera evidenciada en el “Libro Verde”:

El conocimiento se tornó, hoy más que en el pasado, uno de los principales factores de superación de desigualdades, de agregación de valor, creación de empleo cualificado y de propagación de bienestar. La nueva situación tiene reflejo en el sistema económico y político. La soberanía y la autonomía de los países pasa mundialmente por una nueva lectura, y su manutención – que es esencial – depende nítidamente del conocimiento, de la educación y del conocimiento científico y tecnológico14.

De esa forma, el uso y el dominio de la tecnología son esenciales para la integración del país en las directrices de la Sociedad de Información y apropiación soberana del conocimiento.

En ese escenario la filosofía de Software Libre surge como una oportunidad para diseminación del conocimiento y una nueva modalidad de desarrollo tecnológico, en función del nuevo paradigma que se establece en relación de quien produce software (sean empresas o programadores autónomos) con la tecnología propiamente dicha. El Software Libre cumple, todavía, las determinaciones del Gobierno Electrónico, bien como los padrones establecidos por la e-PING.

2.2.2 Razones para adopción de Software Libre

En este capítulo son presentados, en varios momentos, razones para que las instituciones públicas establezcan programas de migración para Software Libre, en especial:

• necesidad de adopción de padrones abiertos para el Gobierno Electrónico (e-Gov); 12 Definición adaptada de RIBEIRO, Daniel Darlen Correa. Software Libre na Administracáo Pública. Estúdio de caso sobre adopción do SAMBA en la Auditoria Geral do Estado de Minas Gerais. Lavras, UFLA, 2004. Monografía de conclusión do curso de Especialización en Administración de Redes Linux. 13 HEXSEL, Roberto André. Propuestas de Acciones del Gobierno para Incentivar el Uso de Software Libre. Curitiba, UFPR 2002. Informe Técnico RT-DINF 004/2002. Disponible en http://www.inf.ufpr.br/~roberto. 14 TAKAHASHI, Tadao (Org.). Sociedad da Informacáo no Brasil. Libro Verde. Brasília, Ministério da Ciencia e Tecnología. 2000.

��


• nivel de seguridad proporcionado por el software libre; • eliminación de cambios compulsorios que los modelos propietarios imponen

periódicamente a sus usuarios, face a la discontinuidad de soporte a versiones; • independencia tecnológica; • desarrollo de conocimiento local; • posibilidad de auditabilidad de los sistemas; • independencia de fornecedor único.

Esos beneficios, agregados al hecho de que gastos referentes a licencias de uso no son aplicables a soluciones basadas en software libre, resultan en economía progresiva para sus usuarios, cuyos valores pueden ser reaplicados en inversiones en área de Tecnología de Información.

De esa forma, la adopción de Software Libre por parte del Estado es amparada principalmente por los principios de Impersoalidad, Eficiencia y Razonabilidad15, visando la mejora en la calidad de los servicios prestados y promoción de desarrollo tecnológico y social.

Por lo tanto, el Estado se beneficia directamente con la adopción de Software Libre tanto en el aspecto de su estructuración para atendimiento a las demandas sociales como en su papel de promover desarrollo. De esa forma, se torna posible, la integración de las políticas de modernización administrativa, de inclusión social basadas en tecnología de información y de desarrollo industrial.

La cuestión de Software Libre está inserida en un amplio escenario integrado, compuesto por acciones de desarrollo tecnológico, inserción adecuada del país en la llamada Sociedad de Información, promoción de la ciudadanía, inclusión digital y racionalización de recursos.

Delante del contexto presentado, se tornó fundamental la creación de un documento con propósito de nortear las acciones de migraciones para Software Libre de la Administración Pública Federal, cuya iniciativa de elaboración está consolidada en este Guía Libre.

2.3 Base de Elaboración de la Guía Libre

En el año de 2003 los Comités Técnicos de Implementación del Software Libre y de Sistemas Legados y Licencias de Software presentaron sus planeamientos estratégicos para los ejercicios 2003-2004.

El Planeamiento Estratégico del Comité Técnico de Implementación del Software Libre presentó 18 directrices para implementación del Software Libre en el Gobierno Federal16 , con 15 El articulo 37 de la Constitución de la República presenta los Principios Basilares de la Administración Pública: legalidad, impersonalidad, moralidad, publicidad y eficiencia. El principio de la racionabilidad posee fundamento implícita, siendo evidenciado en algunas Constituciones Estaduales. Mayores informaciones sobre los principios constitucionales relacionados con la adopción de Software Libre pueden ser obtenidas en: RIBEIRO, Daniel Darlen Correa. Software Libre en la Administración Pública. Estudio de caso sobre adopción del SAMBA en la Auditoria General del Estado de Minas Gerais. Lavras, UFLA, 2004. Monografía de conclusión del curso de Especialización en Administración de Redes Linux.

��


enfoque en la optimización del recursos e inversiones en tecnología de información, popularización y utilización del Software Libre como base de los programas de inclusión digital, migración gradactiva de los sistemas propietarios para Software Libre con garantía de interoperabilidad e inserción del Software Libre en la Política Nacional de Tecnología de la Información. En estos términos, son previstas acciones para elabo-ración de documentación de migraciones de servicios de red, sistemas operacionales y herramientas de automación de oficina.

Por su vez, el Planeamiento Estratégico del Comité Técnico Sistemas Legados y Licencias de Software, también muestra la necesidad documentacional como garantía de interoperabilidad de los sistemas, base de referencias técnicas y de gestión durante los procesos de migración.

Delante de ese contexto, por deliberación conjunta de los dos comités, se creó el Grupo de Trabajo Migración para Software Libre17, con objetivo prioritario de formular orientaciones para migración de las entidades de Administración Pública Federal. Entre sus acciones del GT-MSL, inició el proyecto de elaboración de Guía Libre – Referencia de las Migraciones para Software Libre, cuyo resultado se consolida en este documento.

16 Documento Disponible en http://www.softwarelibre.gov.br/diretrizes 17 Grupo de trabajo interinstitucional mencionado en inicio de este documento

��


CAPÍTULO 3

3.¿POR QUE EL SOFTWARE LIBRE ES LIBRE Y CUÁLES

LAS RAZONES JURÍDICAS PARA MIGRACIÓN?

Software libre no es un tipo diferente de software. No es una especie distinta dentro del género software.

Internamente, en su arquitectura, lo que llamamos de software libre no tiene una sustancia técnica diferente de aquel que llamamos de software propietario. El modelo del desarrollo de que llamamos de software libre – colaborativo, compartido – y de transmisión de derechos sobre él es que son diferentes.

La ley dice que un programa de computador es la expresión de un conjunto organizado de instrucciones en lenguaje natural o codificada, contenida en soporte físico de cualquier naturaleza, de empleo necesario en máquinas automáticas de tratamiento de información, dispositivos, instrumentos o equipos periféricos, basados en técnica digital o análoga, para hacerlos funcionar de modo y para fines determinados

Esa definición no cambia, caso el software sea libre o propietario.

Entonces, si en cualquier momento durante la lectura de esta Guía alguna referencia al software libre como un producto distinto sea encontrado en el contenido, entienda que esa referencia no fue intencional y por favor envié un mensaje para [email protected] alertando sobre ese hecho.

Lo que hace un software ser libre para el gobierno es la forma como los derechos sobre él son adquiridos o transmitidos por el gobierno. Entonces, cuando el gobierno “contrata software libre”, él no está dando preferencia a un tipo de programa o a alguna empresa.

Lo que él está haciendo es contratando de una forma mejor para el ciudadano, para el país y para todo el mundo que se beneficia de compartir las informaciones que existen en el código del programa. Contratando de una forma que permitirá la transparencia sobre innumeros actos del gobierno que son practicados con el auxilio de programas de computador.

El gobierno tiene acceso al código de su programa (además de pagar mucho menos por él) tiene que ver con eficiencia, con independencia y con soberanía. Que el ciudadano tenga acceso al código del programa de computador que el gobierno usa tiene que ver con democracia y con ciudadanía. Y que todo el mundo consiga utilizar las informaciones de ese

��


programa y criar con base en ellas tiene que ver con el desarrollo de la economía y de la sociedad.

Y eso todo solo pasa a causa del contrato, que hace con que el software sea libre.

Es importante entonces que los Administradores envuelvan los abogados o procuradores del órgano o institución en el proceso de migración, conversando con ellos sobre este guía y mostrando este capítulo en especial. Como sugerencia: para cada vez que un Administrador instale un programa de computador, es interesante que él converse con el jurídico sobre la cuestión de la licencia.

En fin, lo que se debe percibir es que el gobierno tendrá siempre a su frente dos formas de contratación distintas. Una en que el gobierno y el ciudadano preservan más derechos – derechos inherentes a la democracia – y otra en que el gobierno y el ciudadano abren mano de esos mismos derechos.

Son dos modelos contractuales distintos. Adoptar uno u otro modelo no es una opción para él gobierno: es, al contrario, un deber. El gobierno tiene el deber de contratar preservando los valores de libertad y de abertura. El gobierno tiene el deber de contratar de la forma mejor para el ciudadano.

Así, si pudiéramos resumir la política gubernamental en relación a software libre en una única frase, diríamos:

“Software Libre: Un Contrato Abierto con el Ciudadano”.

��


CAPÍTULO 4

4. VISIÓN GENERAL

4.1 Introducción

Las directrices presentadas en este trabajo fueron objeto de estudio del Grupo de Trabajo Migración para Software Libre del Gobierno Federal, con participación de la Comunidad Software Libre Brasileña, en intención de construir un guía cuyo respaldo alcance también cualquier entidad interesada en promover equivalentes proyectos de migración.

Los objetivos de estas directrices son:

1. Ayudar los Administradores a definir una estrategia para migración planeada y gerenciada.

2. Orientar el conjunto de directrices y definiciones de este Guía a los Padrones de Interoperabilidad del Gobierno Brasileño (e-PING), cuyas informaciones detalladas pueden ser obtenidas en

http://www.eping.e.gov.br.

3. Criar condiciones para un mayor detallamiento técnico de estas migraciones en la página del Software Libre del Gobierno Federal: http://www.softwarelivre.gov.br.

4. Describir, en termos técnicos, como puede ser realizada tal migración. Las directrices pretien-den tener un uso práctico para Administradores y por lo tanto, deben ser relevantes y precisas, además de accesibles y comprensibles. Este no es un manual de referencias técnicas detalladas: o detallamiento sucede en los estudios de caso presentados en la Parte V. La estructura pretende tornar posible y facilitar las mudanzas a la proporción en que los administradores adquieran experiencia, tengan seguridad y los productos disponibles atiendan sus necesidades.

Para alcanzar esos objetivos, es imperativo que el contenido sea mantenido actualizado y que cualesquiera imprecisiones sean removidas. Para eso, los lectores son incentivados a hacer comentarios y contribuciones a cualquier ítem de las directrices.

��


En ese sentido, visando mantener dinamismo en las actualizaciones de las informaciones del Guía Libre, fue disponibilizado un sistema de participación colaborativa18 en la dirección electrónica:

http://www.governoeletronico.gov.br/guialivre

Opcionalmente, comentarios e sugerencia también pueden ser encaminados para [email protected].

Las informaciones contenidas en este guía no se refieren a la política de software libre en términos generales o a los méritos relativos de las varias licencias existentes. Esas informaciones, juntamente con una grande cantidad de otras informaciones norteadoras, pueden ser encontrados en los siguientes sitios del Gobierno Federal:

http://www.governoeletronico.gov.br

http://www.softwarelivre.gov.br.

4.2 Consideraciones Iniciales

Las informaciones aquí disponibilizadas se destinan a los Gerentes de TI y a los

profesionales que estén planeando o realizando una migración para software libre. Son basadas en las experiencias prácticas de los autores y en un número creciente de estudios de casos públicamente conocidos, que fueron validadas en proyectos exitosos de migración.

Vale destacar la línea general de las directrices recomendadas para cualquier proceso de migración para software libre:

• antes de comenzar, tener un claro entendimiento sobre las razones para la migración; • asegurarse que exista apoyo activo de equipo y de los usuarios de TI para el cambio; • certificarse que existan defensores del cambio, cuanto más altos en la jerarquía de la

organización, mejor; • formar peritos y construir relacionamientos con la comunidad del movimiento Software

libre • comenzar con sistemas no críticos; • garantizar que cada paso de migración sea administrable; • crear canales de comunicación y bases de conocimiento internos y externos a la

institución.

Estratégicamente, sugerimos un tratamiento diferenciado para el cuerpo funcional de las instituciones públicas, con la intención de establecer un ambiente propicio a la migración, además de mecanismos motivacionales.

18 Rau-Tu personalizado por la Dataprev y el Ministerio de Planificación.

��


No se pretende, con esa división, destacar un grupo dentro de los demás, pues todos poseen alta relevancia institucional, y por lo tanto son fundamentales en proyectos a seren implementados.

Creemos que la falta de enganchamiento de cualquier un de ellos perjudica toda dinámica de trabajo, y por eso se entiende que la actuación concomitante con los tres grupos pode facilitar el proceso de migración. Se busca con esa clasificación realizar un mapeamiento ambiental para subsidiar las acciones del equipo de migración.

De esa forma, pueden ser establecidos tres grupos estratégicos:

Cuerpo Gerencial: apoyo gerencial es importante para cualquier mudanza institucional.

Además de las cuestiones pertinentes al cuerpo funcional, ese grupo debe ser despertado para las ventajas estratégicas obtenidas con la adopción de Software Libre, como independencia de proveedor, calidad de servicio y desarrollo tecnológico, directamente ligadas al “negocio” de organización. Específicamente en el caso de la Administración Pública Federal, los Administra-dores están familiarizados con los principios y directrices constantes de los documentos estratégicos del Gobierno Electrónico Brasileño.

Cuerpo Técnico: ese grupo posee el diferencial de desarrollo directo con las cuestiones

tecnológicas y se caracteriza por el alto grado de especialización de sus elementos. De esa forma, precisan estar convencidos de las ventajas operacionales a ser obtenidas con las nuevas herra-mientas, y también motivados con la utilización de nueva tecnología. Deben despertarse para su desarrollo profesional, especializándose en el nuevo modelo tecnológico a ser instituido. Se busca con eso, motivación y valorización del profesional.

Cuerpo Funcional: en ultima instancia, ese será el grupo que mayor contacto mantendrá con

las nuevas herramientas. Precisan ser sensibilizados sobre los motivos de adopción de Software Libre, bien como los beneficios reales oriundos de la migración, como seguridad, robustez y pro-dutividad. Así, podrán ser realizadas palestras o seminarios para entendimiento de los objetivos y ventajas a ser alcanzados. Es interesante que el grupo utilice la nueva tecnología lo más rápido posible.

Esas medidas, aliadas al entrenamiento, son capaces de promover participación efectiva en el proceso de migración y utilización de las herramientas libres, generando feedback precioso para el proyecto.

La mudanza para software libre debe ser vista como cualquier otro tipo de migración de sistemas de TI. Por lo tanto, son aplicables a esas migraciones, desafíos y posibilidades ya experimentadas por todo gerente de informática. En especial, la migración de sistemas de TI proporciona la oportunidad de realizar a reingeniería de los mismos, para satisfacer las nuevas demandas a ellos propuestas. Las cuestiones pertinentes incluyen:

• como garantizar la interoperabilidad de los sistemas; • como dar suporte a los usuarios; • como identificar usuarios remotos de forma segura; • como construir sistemas administrables.

��


Además de todo, como certificarse de que la seguridad sea planeada desde el inicio, y no acrecentada como una cuestión posterior.

En el caso específico de migraciones para software libre es importante destacar que las decisiones referentes a servidores tienen diferencias significativas con relación a las referentes a las estaciones de trabajo. A final, para utilización en servidor, el software libre es bien estable y ya empleado ampliamente. La migración de servidores para software libre puede ser hecha, en términos generales, sin cualquier efecto adverso para los usuarios, por eso, es normalmente, por donde se debe comenzar.

Ya el uso de distribuciones basadas en software libre en las estaciones de trabajo envuelve mayores desafíos, aunque potencialice, para la mayoría de las organizaciones, una mayor economía de costos de propiedad de software. Los principales desafíos en migrar estaciones de trabajo, están en la necesidad de que aplicativos libres mantengan interacción con los aplicativos existentes. Debe ser objeto de atención, particularmente, la forma como herramientas de trabajo en grupo (groupware) y emuladores de mainframe interaje con los ambientes basados en software libre y propietario.

Adicionalmente, en la sustitución de automación de la oficina propietaria, los documentos modelo deben ser verificados para garantir que generen el producto correcto. Las macros deben ser rescritas, preferiblemente como scripts. Aplicativos para los cuales no haya equivalentes en software libre pueden funcionar como cliente leve (thin clients – mayores informaciones en el Capítulo 9). Con el decorrer del tiempo, aplicativos de estación de trabajo podrán ser crecientemente sustituidos por equivalentes libres.

Aunque las directrices objetiven una mudanza completa para el software libre, la tendencia es que un ambiente heterogéneo sea construido, especialmente por que una migración de centenas de estaciones de trabajo llevará tiempo. Es posible todavía la posibilidad de utilización simultanea de aplicativos libres y propietarios, en la eventualidad de no haber versiones estables de aplicativos libres.

En cualquier de las decisiones asumidas por los Administradores, es importante asegurarse de que las elecciones, mismo que no estén directamente relacionadas a la migración, no aten la Administración, en el futuro, a formatos propietarios, sea de archivos o de protocolos.

Es recomendable reflejar cuanto al carácter diferenciado del desarrollo de software libre, lo cual posibilita una mudanza fundamental en la forma como las organizaciones realizan servicios de TI. Es una mudanza de una industria basada en el producto, para una industria basada en el servicio. El software libre tiene nítidamente costo menor de instalación. La cuestión es como formar profesionales en gran escala para el soporte, pues ese generalmente está mas familiarizados con los productos propietarios. Existe un cierto número de compañías de prestación de servicios, bien como representantes de distribuciones. Sin embargo, si la postura de Administración delante de la TI es “¿Quién será procesado si las cosas dieren erradas?”, entonces será necesaria una mejor reflexión sobre las reales condiciones de responsabilidad por problemas, en la utilización de software propietario. Los mitos de que ambientes de TI basados en este modelo de licenciamiento sean “gerenciales” están profundamente construidos en nuestra sociedad.

��


Sin embargo, son mitos. Conforme señala Hexsel19:

El simple hecho de existir un propietario de software, y por lo tanto legalmente imputable, no provee necesariamente garantía cuanto a perjuicios debido a errores o fallas en los sistemas. Al contrario, frecuentemente el propietario se exime de cualquier responsabilidad por daños o perjuicios debido a la utilización correcta20 de sus productos.

Por otro lado, es necesario un entendimiento de la dinámica del movimiento software libre y su funcionamiento. Es aconsejable saber como relacionarse con la comunidad software libre es usufructuar de los beneficios de un nuevo modelo de negocios. Los dos modelos adoptados presentan riesgos inherentes, pero las condiciones efectivas para administrarlos – aunque no atendidas por los modelos de comercialización instituidos y practicados – están más accesibles en ambientes libres.

19 HEXSEL, Roberto André. Propuesta de acciones del Gobierno para Incentivar el Uso de Software Libre. Curitiba, UFPR 2002. Informe Técnico RT-DINF 004/2002. Disponible en http://www.inf.ufpr.br/~roberto 20 Grifo original del autor

��


CAPÍTULO 5

5. METODOLOGÍA

Cualquier proyecto de migración debe constituirse, en términos generales, de:

1. Una fase de colecta de datos y definiciones de proyecto, incluyendo:

A. Una descripción de las condiciones iniciales relevantes que consisten, por ejemplo:

a. arquitectura de sistemas, b. aplicativos y los datos a ellos asociados, c. protocolos y padrones usados, d. hardware, e. ambiente físico, como ancho de banda de la red, localización, f. requisitos sociales tales como idioma(s) y conjunto de habilidades de

personal. B. Una serie de condiciones objetivo detalladas de la misma forma; C. Una descripción de como pasar de las condiciones existentes para las planeadas;

2. Una justificativa para la migración, incluyendo los beneficios y el costo a ella asociado.

3. Una o más fases-piloto, proyectadas para testar el plan y las justificativas. Los datos de esos pilotos pueden ser realimentados en el modelo de costo usado en el plan.

4. Acompañamiento del plan.

5. Monitorear la experiencia actual junto al plan.

El contenido del ítem 1 define lo que en este Guía es llamado de Escenario y las directrices describen como migrar para el software libre en tales circunstancias.

Para permitir la producción de un conjunto razonable de directrices, de utilidad práctica, se torna necesaria la adopción de presupuestos simplificadores, pues al contrario el número de posibles combinaciones haría inviable

Se elige una de las muchas condiciones objetivo (1.B) y se simplifica la descripción de las condiciones iniciales (1.A). Un abordaje del ambiente objetivo es presentado en el Capítulo 8. Con el ambiente objetivo padrón asumido, queda definido un Escenario, por referencia a las condiciones iniciales simplificadas y por el camino de migración de estas hasta el objetivo.

��


Si es necesario, en el futuro, nuevos capítulos pueden ser adicionados a este documento. En la Parte IV, cada capítulo ofrece una descripción razonablemente detallada de un Escenario, describiendo como migrar para o albo, inclusive con la discusión de migraciones parciales. El contenido de los capítulos fue actualizado llevándose en consideración experiencias con migraciones reales, especialmente aquellas retratadas en el Capítulo 16.

La mensuración de los costos envueltos en el proceso de migración de los estudios de caso presentados en el Capítulo 16, conforme destaca el ítem 2, extrapoló el enfoque meramente financiero, alcanzando puntos cruciales para la Administración Pública, como autonomía, desburocratización, transparencia y reingeniería tecnológica21.

El detalle disponible en el levantamiento de estudios de casos disponibles al público era muy amplio. Fue encontrado un grande número de tales estudios pero con poca documentación (que ofreciesen mayor detalle), restando sólo la divulgación de informaciones genéricas.

Esto significa que la mayor parte de las directrices es basada en las experiencias del Gobierno Federal Brasileño y referencia de otros niveles de la federación, y sus discusiones con personas/órganos que realizaron una migración.

21 Un ejemplo de este enfoque es presentado en el capítulo 17.

��


El expresivo número de diferentes combinaciones de condiciones iniciales y finales de escenarios, juntamente con las variadas formas de pasarse de unas para otras, demuestra la imposibilidad de cubrirse todas las posibilidades con cualquier conjunto de directrices. Por lo tanto las directrices deben ser consideradas mas como indicativas y referenciales de lo que puede ser echo, de lo que prescrititas de lo que debería ser hecho. Ellas deben ser usadas como un punto de partida en el proceso de migración. No se puede esperar que ofrezcan una respuesta para todas las circunstancias. Entretanto, en los estudios de caso son presentados caminos que pueden ser seguidos con seguridad.

Se parte del principio que la migración tiene un albo que es un ambiente totalmente software libre donde es posible y sensato; en tanto, pueden haber razones para que sistemas propietarios deban ser mantenidos o utilizados. La posibilidad de una migración parcial también es discutida y justificada.

��


PARTE II - DIRECTRICES DE GESTION

��


CAPÍTULO 6

6. VISIÓN GENERAL DE LA MIGRACIÓN

6.1 La sensibilización es el mejor comienzo

Como ya descrito en el Capítulo 3, el software puede ser libre o propietario. Esta elección es una decisión del desarrollador o de la institución desarrolladora y muchas veces no se trata de una decisión puramente técnica. Se refiere también a una decisión económica, comercial o que en lo mínimo esté contextualizada en una política tecnológica (por ejemplo, cuando una empresa define su Plan Director de Tecnología de la Información - PDTI) . La decisión sobre el desarrollo y uso de software libre sufre también anuencias de carácter cultural, y estas, pueden ser más limitadoras de que el propio empleo de la tecnología.

Mudar sistemas, alterar soluciones y plataformas, en general, son tareas complejas. Considerando que toda mudanza que mude el comportamiento y las rutinas de las personas aumentan el grado de dificultad, se puede afirmar que al hablar en migración la atención de los Administradores no se puede concentrar exclusivamente en la parte técnica. La migración exige también un esfuerzo

de mudanza cultural, que en las organizaciones se retrata directamente en lo que se concibe como Cultura Organizacional.

La experiencia demuestra que toda mudanza de plataforma, o de paradigma, para ser bien sucedida exige un grande trabajo de convencimiento. Conforme descrito en el capítulo 4, es importante que se desenvuelvan acciones de convencimiento del cuerpo técnico, gerencial, funcional, y consecuentemente, los "ciudadanos usuarios", objetivando establecer un ambiente favorable para la realización de las migraciones y todavía desarrollar mecanismos motivacionales.

En general, toda la migración que desconoce la importancia de sensibilizar las personas envueltas lleva mucho más tiempo o simplemente no es bien sucedida. Explicar los motivos de la migración, afirmar sus ventajas, demostrar su importancia es indispensable, principalmente para traer los grupos directamente atingidos como los principales aliados en el proceso, conforme será discutido en el Capítulo 7.

Antes de capacitar los usuarios en soluciones libres es preciso reunirlos y explicar los motivos de la migración. Los Administradores pueden realizar reuniones generales, por sector, por grupos de gerentes y deben ser en número suficiente para convencer y obtener la simpatía del mayor número de personas. Sin duda, la fuerza del mensaje del software libre es tan contendiente que puede motivar a las personas para una migración ejemplar victoriosa. Pero

��


antes de todo es preciso explicar bien lo que está pasando. Esta es una actividad esencial llamada sensibilización.

Sensibilización y sus técnicas son tan relevantes que merecen especial atención de los administradores y siempre se puede recorrer a diversos estudios referentes al asunto que orienten este debate, como por ejemplo Michael Porter22, al reforzar que “un producto sustituyó otro sí él ofrece al cliente/usuario un incentivo para mudar, en lo cual él cubre los costos de migración (factor económico) o sobreponga las resistencias para mudanza (factor humano y cultural)”.

La sensibilización es una fase tan importante que muchas veces se puede abrir mano del tiempo de ejecución de otras actividades de migración para ejecutar adecuadamente esta fase.

6.2 Gerenciando la Migración

Mucho de lo que es necesario ser hecho para migrar de un ambiente propietario para

software libre es semejante a cualquier migración. Hasta mismo en la migración de un ambiente tecnológicamente idéntico y/o de un mismo proveedor, no se puede presuponer que los formatos de los archivos serán compatibles y siempre habrá necesidad de testeos apropiados antes de proceder a cualquier mudanza más difundida. Todas las migraciones necesitan ser basadas en un cuidadoso planeamiento, conforme programa de fases discriminado en el Capítulo 5.

Las directrices aquí presentes no pretenden ser un manual sobre gestión de proyecto y se supone que la Administración tenga habilidad para gerenciar la migración de forma apropiada y los Administradores capacidad técnica para realizarla. La descripción adelante pretende realzar los puntos importantes de una migración para software libre.

La información encontrada puede indicar que serán necesarias modificaciones en el ambiente actual,

antes de ser concebida la migración para el software libre. Esa es la razón por la cual hasta mismo administraciones que no tiene planes inmediatos para migración, pero que desean mantener esa opción disponible, son instruidas a solicitar sólo padrones multiplataforma y abiertos, como ya mencionado en la e-PING, y evaluar su infraestructura en comparación a esos padrones (vea también Sección 8.3 ).

El proceso de migración debería, en tesis, consistir de las partes que siguen. Algunas de ellas pueden ser hechas en paralelo, tales como la 2, 3 y 4, o de acuerdo con el planeamiento de cada institución.

1- Creación de equipo habilitada con apoyo gerencial

22 Michael Porter, en Estratégia Competitiva (Rio de Janeiro. Campus, 15a. ed. 1986) introduce reconocidas técnicas para análisis de la industria y concurrentes; en Ventaja Competitiva (Rio de Janeiro. Campus, 4a. ed. 1992), Describe como las empresas pueden crear y sustentar ventajas competitivas.

��


La creación de equipo habilitada es el primer paso para realización de cualquier proceso de migración. Además, es importante que haya apoyo gerencial, caso contrario habrá resistencia para salir del modelo de los sistemas propietarios. Ese suporte deberá posibilitar que se construya, en lo mínimo, pilotos representativos; por lo tanto, tendrá que ser producido un informe de implementación/plan de trabajo, y talvez algún documento mas detallado cuando haya más datos disponibles.

2 - Entendimiento del ambiente albo

Es necesario que se entienda el ambiente albo, tanto el software libre cuanto la arquitectura básica (vea Capítulo 9), junto con las varias opciones y elecciones disponibles. Esto significa entrenar el equipo existente, reclutar o utilizar consultores, lo que va demandar un costo inicial y, por lo tanto, requerir soporte gerencial suficiente. Hay, por veces, la idea de que el software libre pueda ser comprendido y utilizado sin peso. Esa expectativa puede provocar inconsistencias en los costos planeados.

3 - Revisión de la arquitectura base y aplicativos utilizados

La migración es una oportunidad para rever la arquitectura base, bien como los aplicativos. La arquitectura recomendada en el Capítulo 9 es basada en el control centralizado y posee algunas ventajas allí discutidas. Ese cambio puede implicar en costos, los cuales deben ser considerados. Se debe atentar que estos costos no se refieren a mudanza para Software Libre, pero si para una nueva arquitectura.

4 - Entendimiento de la “filosofía” de Software Libre

Es muy importante que se entienda la “filosofía” del software libre. Algunas cuestiones necesitan ser bien consideradas antes de tomarse cualquier decisión:

A. Donde haber varias opciones para cada una de las funciones – es necesario que los Administradores conozcan las ventajas y las desventajas de cada producto, para que se pueda optar por la solución que mejor atienda a sus necesidades. En este Guía serán sugeridos los parámetros que deben ser evaluados para cada una de las opciones disponibles, seguidos por las opciones de productos que ya fueron conocidas en la práctica en experiencias de la Administración y, finalmente, uno o más casos de suceso relacionados con estas herramientas.

B. Las diferencias entre las varias distribuciones de los sistemas operacionales libres deben ser consideradas. Algunas son desarrolladas por empresas que ofrecen soporte y reparos. Otras tienen características distintas para esas mismas cuestiones; las diferencias deben ser evaluadas antes de hacer una elección.

C. Los Administradores deben determinar el nivel de soporte necesario. Se puede obtener soporte

��


comercial con los responsables por las soluciones o con los mantenedores de las distribuciones,

en el caso que ofrezcan tal soporte. Caso no ofrezcan, se puede conseguirlo con servicios de terceros, pues el código fuente es disponibilizado y hay muchas compañías ofreciendo sus servicios para tales soluciones y distribuciones.

D. La cuestión del soporte es una diferencia bien clara con relación al mercado de software propietario, donde sólo las empresas que tienen el privilegio de acceso a la fuente pueden dar el soporte con mayor nivel de profundidad – esto se torna crítico caso el revendedor propietario deje el negocio sin liberar el código fuente. Con la adopción del Software Libre, las organizaciones tienen acceso y control al código fuente, y de esa forma adquieren autonomía para negociar con cualquier empresa que preste este servicio.

Además, la mayor parte de esos aplicativos poseen Listas de Discusión activas, donde un pedido de ayuda será respondido por alguien interesado en la herramienta. La presencia de una Lista de Discusión activa y de una comunidad de usuarios es, frecuentemente, uno de los primeros criterios en la selección de componentes del software.

5 - Realización de auditorias en los sistemas existentes

Las informaciones colectadas por las auditorias son necesarias, no sólo para hacer las migraciones, mas en grande parte, para construir un modelo de costo de propiedad para un plan / informe de migración detallado.

Haga el inventario:

A. Para cada aplicativo usado:

a. El nombre del aplicativo, número de versión y contacto para responder las cuestiones relacio-nadas al aplicativo;

b. La cantidad de usuarios que requieren acceso y el acceso simultáneo al aplicativo;

c. Con cuales sistemas operacionales el aplicativo puede ser usado, considerar todos los ambientes;

d. Cuales otros aplicativos son necesarios, tanto en el cliente como en el servidor, para el aplicativo funcionar – pre-requisitos y/o dependencias;

e. El hardware exigido, considerando si es necesario algún equipo fuera de los pa-drones o de última generación – alta performance, etc.

f. Los protocolos y puertas usados para comunicarse con otros aplicativos; g. Los formatos de archivos requeridos y generados

B. Requisición de Datos:

El concepto de dato debe ser interpretado en sentido amplio, lo que incluye, por ejemplo, docu-mentos de procesador de textos y planillas, dados sonido /voz y de imagen, además de los

��


bancos de dados habituales: en general, cualquier cosa que se pretenda procesar en una computadora.

a. Cuales son las dificultades en la interface con sistemas externos o usuarios fuera de los cuadros de funcionarios de la Administración?

b. ¿Cuáles los requisitos para guardar los datos y poder procesarlos en el futuro? ¿Hay un repositorio de datos legados al cual se tenga que dar suporte? Caso positivo, hay necesidad de aplicativos específicos para accesarlos (caso estén almacenados en medios cuya accesibilidad es restricta a determinado sistema o aplicativo) y procesarlos. Divida los datos en las siguientes categorías:

i. Datos que no necesitan ser mantenidos y pueden ser eliminados. Descártelos. Tengan cuidado de hacer el back-up para el descarte en periodo adecuado, de acuerdo con la política de almacenamiento de datos de la institución.

ii. Datos que necesitan ser mantenidos y que se encuentran normalmente en formato abierto, o que pueden ser fácilmente convertidos para formato abierto. En este caso, el costo de la conversión debe ser evaluado. iii. Datos que necesitan ser mantenidos, mas que estén en un formato propietario cerrado, que no permite fácil conversión para formato abierto. Esos datos pueden necesitar de copias del aplicativo propietario especifico para que sean mantenidos. El costo de ese aplicativo debe ser evaluado. El número de copias de esos aplicativos puede ser determinado por el grado de acceso necesario a los datos. Por ejemplo, si los dados fueren raramente accesazos, una única copia en una máquina central será suficiente. También puede ser necesario mantener un hardware específico para usar esos apli-cativos. Finalmente, para tanto, se puede considerar la utilización de características de modelo cliente leve – thin client (vea en la Sección 9.1 ).

C. Requisitos de Seguridad

a. ¿Cuál es el sistema actual para creación de usuarios y señas? ¿Hay una estructura para los nombres de los usuarios? Caso positivo, ¿cuál es ella ? ¿Está de acuerdo con la norma apuntada en la e-PING? ¿Cuál es la política para alteración de señas?

b. ¿Hay sistemas que requieren alguna otra autenticación además de un simple nombre de usuario y de seña?

c. ¿Cuáles las políticas Administrativas y de Gobierno existentes con relación al uso de computadoras? ¿Existen normas internas específicas? Por ejemplo, ¿hay restricciones al uso de Internet y del correo electrónico?

d. ¿Hay planos de seguridad que requieren el uso de hardware o software específico? e. ¿Existe alguna sistemática de uso de Certificación Digital?

6 - Definición de un escenario detallado para migración

La definición del escenario deberá basarse en datos compilados en las etapas sugeridas en los ítenes anteriores y consistirá de algunas secciones, incluso:

A. El costo del ambiente existente durante un período razonable de tiempo, tal como 3 años, con los presupuestos apropiados a la Administración.

B. El costo de ambientes alternativos, bien como el costo de la migración para cada uno, a lo largo del mismo periodo.

��


C. La comparación de costos del ambiente actual y futuro.

D. Los puntos fuertes y flacos del ambiente actual y las varias alternativas.

7 - Atención con los usuarios

La consulta a los usuarios puede ser un elemento favorable. Explique las razones de migración y los efectos sobre ellos. Considere las preocupaciones informadas con seriedad y permita que ellos utilicen la tecnología lo más breve posible. Cuanto más rápido se envuelvan mejor. Esto puede ser una exigencia en algunos órganos, sin embargo debe ser realizado en cualquier caso, para facilitar la introducción de lo que puede venir a ser una mudanza significativa en las prácticas de trabajo.

Cree una central de atendimiento que responda a las dudas de los usuarios. Más tarde, cuando la migración esté establecida, esa Central podrá responder a los problemas y tornarse un centro de excelencia y buenas prácticas. Críe un sitio en la red interna con una Sección de Consejos y un “Cómo hacer”, que puede ser actualizado por los propios usuarios (existen aplicaciones libres propias para permitir esta interacción). Esto es importante para que los usuarios se sientan inclusos y también por-que el sitio dará a las personas del soporte técnico una idea de los tipos de problemas más enfrentados por sus clientes.

8 - Realización de proyectos piloto

Asumiendo que el escenario fue definido y la justificativa elaborada, comience con proyectos piloto de acuerdo con su capacidad de atender a las demandas generadas por los proyectos. Eso se va proporcionar, entre otras cosas:

A. Datos para modelos mas refinados de Costo de Propiedad y Servicios.

B. Opinión del usuario, que puede ser usada para facilitar la introducción de otros sistemas.

C. Validación o modificación da arquitectura albo y del modelo de negocios.

D. Adquisición de experiencia a lo largo del tiempo.

9 - Definición del modelo de migración

Es necesario una definición del modelo del proceso de migración a partir del momento en que comience. Las principales opciones son:

��


A. Big bang: Todos los usuarios mudan del sistema antiguo para el nuevo al mismo tiempo. En la práctica, esto quiere decir, probablemente, que la mudanza deberá ser marcada para un fin

de semana o feriado nacional. Las ventajas son que no son necesarias disposiciones para acceso a más de una plataforma y que las personas no necesiten cambiar de un sistema para otro, manteniendo el ambiente homogéneo. Las desventajas incluyen el alto riesgo y la gran necesidad de recursos durante la mudanza. Este esquema de migración probablemente sólo será atractivo para pequeñas administraciones.

De cualquier forma, si es posible, evite la migración Big Bang. Las migraciones Big Bang tienen tantas variables para controlarse que casi siempre fallan, probablemente por un problema de gestión, y no del software libre, lo que puede no quedarse transparente.

Evitar la migración Big Bang no significa que el Administrador va a protelarla indefinidamente. Ella debe ser hecha de manera progresiva en los estrictos límites en que esta pro-gresividad fuera indispensable a la continuidad de las actividades de su órgano o institución.

B. Transición en fases por grupos: Los usuarios cambian del sistema antiguo para el nuevo en gru-pos. Es probable que grupos funcionales completos sean movidos juntos, para minimizar compartimiento (pierda de seguridad) de datos y problemas del trabajo en grupo. Los

riesgos pueden ser contenidos y los recursos administrados a través de la elección del tamaño apro-piado de los grupos. Es posible aprovechar este momento para hacer alteraciones necesarias en el hardware, con sustitución gradual de la estación de trabajo, al mismo tiempo, haciendo la actu-alización de las máquinas removidas de un grupo e instalándolas después en lugar de las máquinas antiguas del otro grupo. Existe la desventaja para ambientes heterogéneos: as veces puede ser necesario tratar cada ambiente separadamente.

C. Transición usuario por usuario: Esencialmente igual a la opción de transición por grupo, pero con tratamiento diferenciado para cada persona. Este método de alimentación gota a gota, requiere pocos recursos, permite dimensionar el problema, mientras crea islas en el ambiente y es ineficiente y de interés poco probable para grandes Administraciones. Puede, sin embargo, ser una forma apropiada de conducir proyectos piloto. Es probable que los sistemas antiguos y nuevos tengan que funcionar lado a lado por algún tiempo. Es importante poseer una estrategia de transición que posibilite a los sistemas an-

tiguos y nuevos para que trabajen juntos, de forma que las actividades de producción puedan seguir adecuadamente durante el período de transición. Se puede llevar un largo tiempo hasta la sus-tituición de la ultima máquina, por lo tanto, es probable que la coexistencia venga a ser un factor relevante en el proceso.

D. Transición para las personas o tecnologías nuevas en la organización: El ambiente organizacional tiene su propio dinamismo y siempre convive con momentos de mudanza, que suceden, por ejemplo, con la entrada de nuevas personas o tecnologías. Es interesante aprovechar ese momento para capacitar las personas en el ambiente existente en Software Libre o ins-talar soluciones libres en los equipamientos adquiridos. Un ejemplo común es la utilización de herramientas de automación de oficina, en especial editores de texto, planilla electrónica y correo electrónico para las personas recién llegadas a la institución.

��


10 - Posibilitar que la migración alcance toda la Administración

Para tanto será necesario entrenamiento adicional de los usuarios y de técnicos. Considere el entrenamiento de los técnicos primero, con repaso posterior del aprendizaje a los demás, visando disminuir los gastos y las dificultades.

11 - Acompañamiento del feedback del usuario

Es fundamental que el equipo de migración ponga atención al feedback de los usuarios y procure resolver cualesquiera problemas que aparezcan. Algunas necesidades de usuarios pueden ser tan específicas, que no será posible preverlas con antecedencia o descubrirlas durante proyectos piloto. Esté cierto de que habrá recursos suficientes para trabajar con tales necesidades después de la transición, pues la agilidad en el atendimiento a esas demandas dejarán a los usuarios más seguros.

Pueden existir nichos de aplicativos propietarios que eventualmente no poseen soluciones con performance equivalente en Software Libre. En esas circunstancias, dependiendo de la criti-cidad de tales sistemas, el proceso de migración puede ser impracticable en un primer momento, esperando que las soluciones libres equivalentes adquieran relativo grado de estabilidad.

��


CAPÍTULO 7

7. CUESTIONES HUMANAS

Esas directrices no tienen el objetivo de volverse un guía para Gestión de Recursos Humanos.

La intención aquí es destacar los tipos de cuestiones que surgieron en instituciones que realizaron la migración para Software Libre. Las Administraciones ya habrán anteriormente enfrentado muchas de esas cuestiones en otras áreas, y por eso poseen habilidad interna considerable para superarlas de forma solidaria. El sector de Recursos Humanos deberá estar envuelto desde el inicio del proceso.

Es muy importante que todas las personas sean consultadas y mantenidas informadas sobre el desarrollo del proceso. Una forma de hacer eso es crear una intranet que posibilite ser actualizada fácilmente y que pueda tener una sección para feedback del usuario. Existen soluciones en software libre que posibilitan este tipo de interacción, con sistemas de votación, libro de visitas, etc.

La oportunidad de entrenamiento es muy importante. Algunas instituciones permiten que los usuarios decidan por si mismos si desean participar de los entrenamientos, mientras otras determinan quienes serán entrenados. La elección va a depender de la cultura de la Administración y del asunto del entrenamiento. Manuales y documentación están usualmente apenas en inglés y esto puede causar problemas con algunas personas del equipo. La traducción para la lengua portuguesa puede ser considerada como un costo de migración, pero eso causará necesidad de traducción continuada de las actualizaciones.

Algunas interfaces del usuario del software libre, ofrecen opción de idiomas, sin embargo la traducción puede no ser completa, con algunos ítenes todavía en inglés. Además, ni todos los aplicativos tendrán soporte de las configuraciones regionales (localización plena). Mientras, existe un cuadro de mudanza acelerado y la estructura que permite el uso de otro idioma además de inglés estará disponible, si la Administración quiera usarla. Ya existen, incluso, interfaces con buena característica de accesibilidad para deficientes visuales.

Hay algunas reacciones clásicas a cualquier mudanza en las prácticas de trabajo, para las cuales deberá haber un planeamiento:

i) Miedo del Desconocido

El uso del software libre podrá ser completamente nuevo para la mayoría de los usuarios y para el equipo técnico. El miedo natural de lo desconocido, y la tendencia en mantener los sistemas existentes, podrá hacer con que las personas críen resistencias a la migración.

En toda institución siempre habrá usuarios más curiosos, que podrán interesarse en experimentar el nuevo ambiente. Esos son los que deberán ser presentados, en primera instancia,

al nuevo sistema. La experiencia indica que después que las personas pierdan sus reservas, ellas verifican que la utilización del nuevo modelo no defiere profundamente del modelo propietario a que estaban acostumbradas y acaban por utilizar el Software Libre con satisfacción. De esa forma, existe la posibilidad que ese grupo inicial de usuarios cambie para la nueva plataforma de forma entusiasta y también es probable que esas personas sean aquellas que

��


mejor irán a evaluar el desempeño de las nuevas herramientas, transformándose en una fuente de retorno importante para la institución.

Otro factor que debe ser considerado es la posibilidad de que algún funcionario ya posea conocimiento sobre la cuestión del Software Libre y esté, incluso, utilizando herramientas libres en su trabajo. Por eso es interesante que la Administración esté atenta en la identificación de esas personas, las cuales podrán auxiliar positivamente el proceso de migración en función de la experiencia ya adquirida.

El primer grupo de usuarios podrá ser usado en proyectos piloto, y habiendo pasado por la experiencia, podrán incentivar y orientar sus colegas. Se puede pensar en la creación inclusive de un grupo para estos usuarios, con destaque dentro de la Administración, para que sirvan como ejemplo y rompan la barrera de las personas que más se opongan.

De cualquier forma, en la segunda fase, los usuarios mas reservados tendrán que recibir más recursos de apoyo, a través de la central de atención, Intranet, usuarios locales experimentados y entrenamiento presencial.

El mismo proceso puede ser usado para el equipo técnico, todavía es probable que el nivel del entrenamiento sea significativo si el ambiente propietario existente no fuera compatible con UNIX/Linux. El equipo técnico, particularmente, necesita anular sus dudas rápidamente. Esas personas serán un punto focal para todos los problemas que estén por suceder y, si no creen en el proyecto, no podrán incentivar los usuarios de forma positiva.

ii) El efecto dilución de Currículo

Tanto el equipo técnico como los usuarios podrán sentir que, debido al no uso del software propietario “padrón” de la industria, tendrá perjuicio en su habilidad de desarrollarse en la car-rera. Éste es un problema, que demanda un cuidadoso gerenciamiento. La Administración no debe parecer distante de esa realidad en su abordaje con el Cuerpo Técnico. Pero hasta que el software libre sea largamente utilizado, las Administraciones deberán enfrentar este problema con bastante frecuencia e informar que la calificación profesional de quién actúa con Software Libre tiene su valorización en el mercado.

Se hace necesaria una sólida inversión en capacitación técnica y perfeccionamiento profesional en intención de valorar, motivar y especializar el equipo para la nueva realidad.

iii) Conocimiento es poder

Las personas que conocen los sistemas y configuraciones ya en utilización, tienen un cierto poder y pueden demostrar oposición en abrir mano del mismo, si el ambiente del software libre fuera muy diferente del existente. Nuevamente, el problema requiere gerenciamiento cuidadoso ya que esas personas cumplen un papel crítico en el funcionamiento de esos sistemas. Es posible priorizar el entrenamiento de esas personas en el nuevo modelo en la intención de garantirles el status ya adquirido en la organización, agilizando el proceso de migración, y haciendo a esas personas aliadas.

��


CAPÍTULO 8

8. FACILITANDO LA VIDA

Hay algunas consideraciones que pueden facilitar la introducción del software libre. En este capítulo destacamos algunas medidas que podrán atenuar el impacto de migración en el ambiente.

8.1 Introduzca aplicativos libres en ambiente propietario Muchos de los aplicativos software libre irán trabajar en sistemas operacionales

propietarios y eso proporciona la oportunidad de introducir esos aplicativos sin tener que cambiar totalmente el ambiente. Por ejemplo, el pacote de automación de oficina OpenOffice.org, el navegador Mozilla y el servidor web Apache trabajan en Windows ® y, por lo tanto, pueden ser utilizados como sustituto del Microsoft Office ® , del Internet Explorer ® y del IIS ® , respectivamente.

Además de ser menos radical, ese abordaje permite que la reacción del usuario sea evaluada en Una pequeña escala y los planos para entrenamiento del mismo pueden ser basados en la experiencia real. Además, problemas como conversión de formatos de archivos, macros y modelos pueden ser facilitados si el aplicativo propietario permanecer instalado por algún período.

Este abordaje permite decir que la elección del aplicativo en el ambiente albo final (libre) estará limitada a los que trabajan en sistema operacional propietario. Por ejemplo, el navegador web albo puede ser el Galeón, todavía el Mozilla es el único que funciona tanto en Windows ® como en GNU/Linux, y puede ser adoptado primero, por ya funcionar en ambiente propietario.

8.2 Haga primero las cosas fáciles En primera instancia, efectúe mudanzas que no causen “divisiones” en el Cuerpo

Funcional. Esto significa proceder a las mudanzas primero en el servidor, lo que va a dar una plataforma para la introducción de las mudanzas de las estaciones, futuramente. Muchas de las mudanzas serán compatibles con ambiente propietario, y por lo tanto, el efecto de la alteración será minimizado.

Por ejemplo, servidores de nombres DNS, servidores DHCP y servidores de base de datos con software propietario, son todos candidatos a la sustitución por un software libre equivalente y todavía Establecen interfase con el resto de los sistemas corrientes (libres o propietarios) como antes.

También existen soluciones que funcionen en Software Libre y permiten la coexistencia de diversos sistemas operacionales, a ejemplo del Samba. La adopción inmediata de ese tipo de solución flexibiliza el proceso de migración por permitir un mejor gerenciamiento en la migración de los ambientes.

��


8.3 Piense más allá Emplee de inmediato buenas prácticas para minimizar lo que ciertamente podrá dificultar

la migración futura.

1. Insista para que todo desarrollo hecho para web, construido en la institución o

contratado, produzca un contenido que pueda ser visto por los navegadores definidos por la e-PING, o sea, sin utilización de padrones propietarios. Las Administraciones no necesitarán, en cualquier caso, de un software específico para ver su contenido. Existen herramientas disponibles para ayudar a verificar la compatibilidad de las páginas de la web.

2. Desencoraje el uso indiscriminado de macros y scripts en documentos y planillas; encuentre otros medios de proveer funcionalidad. El uso indiscriminado de esos recursos es, comúnmente, un medio a través del cual los virus infectan los sistemas. Las macros también pueden ser fácilmente usadas para robar dados y subvertir documentos, pues pueden hacer el documento “decir” cosas diferentes, dependiendo de quien lo está leyendo, o “decir” otra cosa cuando impreso. Finalmente, muchas de las acciones hechas por medio de macros y scripts deben recibir una sistematización más robusta.

3. Insista en el uso de formatos de archivos padrones abiertos, por ejemplo, Postscript y PDF. Se sabe que hay una discusión sobre ser, el Postscript y el PDF, modelos abiertos o no. Eso es mas un debate sobre definiciones estrictas y, en particular, de quien controla el modelo. En la realidad, esos son los formatos de archivos ampliamente utilizados en el momento, que tiene definiciones disponibles públicamente, y que pueden ser usados sin restricciones significativas. Diversas soluciones en software libre producen con facilidad esos formatos de archivos. Particularmente, no use formatos de archivos propietarios para archivos cuyo objetivo es sólo ser leídos y no editados por el destinatario, pues tales archivos son un medio común de diseminar virus. Al usar formatos propietarios, la Administración estará atada al fornecedor por un tiempo considerable. Además, esos formatos propietarios pueden incluir cantidades considerables de metadatos, en particular textos apagados previamente, los cuales, caso vistos, pueden volverse problemáticos para la Administración. No es difícil accesar esos metadatos.

4. En la elaboración de documentos en colaboración de usuarios, utilice un formato de mayor aproximación posible (o mejor accesibilidad). Eso aumentará la posibilidad de uso de los aplicativos del software libre.

5. Use protocolos de padrones abierto. Se definen protocolos de padrones abierto como

aquellos que son libres de patentes y que tiene implementación del software libre. Los padrones adoptados por el Gobierno Federal están en el documento de referencia de la e-PING, conforme destacado en la sección 2.1.4.

6. Desenvuelva sistemas basados en un modelo, por lo menos, en tres camadas (vea Sección

7. 9.1), en que el código del aplicativo es independiente de la interface humana y de los métodos de acceso a los datos. Por ejemplo, si posible, tenga una interface que pueda ser accesada en un navegador web de software libre. La construcción de aplicativos de esta forma, modular, tornará más fácil la migración a los pocos. Eso reducirá no sólo la escala de cualquier fase de migración, como también el riesgo de fracaso. Los aplicativos de clientes monolíticos tradicionales son, notoriamente, difíciles de manipular.

8. Insista que todos los nuevos aplicativos sean hechos para ser portables. Evite lenguajes de arquitectura específica y APIs. Evite construir aplicativos que exijan la presencia de

��


otros aplicativos propietarios.

9. Sustituya los lectores de correos que usen formatos de almacenaje propietarios y/o que se comuniquen con servidores usando protocolos no padronados por la e-PING. Sí posible, utilizar una solución para almacenar listas de direcciones y calendarios en un formato Abierto.

��


PARTE I I I - DIRECTRICES TÉCNICAS

��


CAPÍTULO 9

9. ARQUITECTURA DE REFERENCIA

9.1 Arquitecturas genéricas Mucho se tiene usado el modelo de 3 camadas para desarrollarse software de

computadoras

Ese modelo separa los aplicativos en 3 partes1:

Camada de acceso a los datos, sistemas de archivos y bancos de datos. 2. Camada de código del aplicativo y lógica del negocio. 3. Camada de la interface humana, pantalla, teclado y mouse.

Figura 9.1: Diagrama 3 Camadas

Cada camada del aplicativo debe preocuparse en realizar sus tareas específicas dejando las otras tareas y funciones para las otras camadas del software. Eso trae beneficio de que el código del aplicativo puede ser más simple y puede trabajar mas fácilmente en ambientes diferentes, porque su dependencia con relación al acceso especifico a la máquina es reducida. Las fechas indican el uso de la información entre las diversas camadas del aplicativo. Es interesante que estos usos de información utilicen padrones abiertos y bien definidos. De esta forma se torna más fácil portar, o migrar el aplicativo para diversas arquitecturas de hardware y software, y además es posible alcanzar la interoperabilidad entre diversos sistemas.

Este modelo en 3 camadas fue generalizado para n-camadas, donde los componentes son todavía más refinados, y es típicamente desarrollado utilizándose la tecnología de objetos o de componentes.

Los detalles sobre este modelo pueden ser encontradas en http://www.corba.ch/e/3tier.html. Muchos aplicativos Cliente/Servidor, en el pasado, sólo usarán un modelo de 2 camadas, donde el código del aplicativo y la interface humana se funden. Esto significa que migrar tales aplicativos es más trabajoso que con los modelos 3/n-camadas, porque probablemente la interface humana irá requerir alteraciones, una vez que el modelo de 2 camadas presenta en su grande mayoría el código de la interface humana combinado con la lógica del negocio.

La comunicación entre las 3 partes de un modelo de tres camadas, normalmente usa protocolos que permiten a cada camada trabajar en una máquina el sistema diferente das otras dos camadas, caso eso sea deseado. Algunas veces, as partes también son divididas entre otras máquinas. La elección de como esta división es hecha da origen a varias arquitecturas genéricas.

En vista de la estación de trabajo, donde en mínimo alguna parte do código da interfase humana es realizada, son usualmente utilizadas las arquitecturas:

��


1 – Cliente Leve (Thin Client) En esta arquitectura la estación de trabajo no precisa de dispositivos de

almacenamiento, tales como drive de CDROM, de disquete, disco rígido, etc. El cliente normalmente es un terminal burro, una computadora antigua y/o un dispositivo especifico para Cliente Leve. Las ventajas de esta arquitectura son el bajo costo y la posibilidad de reutilizarse hardwares antiguos y tecnológicamente desfasados. Además, como un servidor remoto almacena todos los datos y ejecuta todas las aplicaciones, existe mayor facilidad de manutención y actualización de los sistemas. Algunos ejemplos de esta arquitectura son: terminales gráficos, Terminal Services, WebService, terminales VT100, un dispositivo de navegador embutido, emuladores de terminal 3270, etc. 2 – Cliente Pesado (Fat Client)

El código y los datos son mantenidos en la estación de trabajo sin conectividad de red. Las aplicaciones son ejecutadas localmente, exigiendo una mayor capacidad de procesamiento, memoria RAM, almacenamiento en disco rígido, y todavía, utilización de drive de disquete y CDROM. Ventajas: independencia de otros computadores y servidores. Desventajas: costo elevado, mayor dificultad en actualizar y dar manutención al sistema por ser descentralizado.

3 – Arquitecturas intermediarias

Existen diversas formas de desarrollarse, ejecutar y utilizar aplicaciones intermediarias a las arquitecturas Cliente Leve y Cliente Pesado, tales como: Almacenar la aplicación en un servidor y después transferir para la estación de trabajo para que ella sea ejecutada cuando sea necesario. Por ejemplo, esta es la forma como trabajan applets Java. Una otra variante es el acceso remoto a servidores de archivos. Los datos quedan almacenados remotamente, pero son accesados y ejecutados localmente en la estación de trabajo. Como ejemplo de esta variante tenemos la tecnología de compartimiento de archivos NFS.

4 – Elección de la arquitectura

La elección de la arquitectura para algún aplicativo o hasta mismo la estación de trabajo dependerá De los siguientes factores:

a) A largura de banda de la red para los servidores y lo que esa anchura de banda tendrá que cargar. Si las estaciones de trabajo no fuesen “pesadas”, la red tendrá que integrar los controles de interfase humana, dados, o código de aplicativo ejecutado, además del tráfico normal de la red (TCP, UDP, etc.). En algunas circunstancias, el volumen de datos, generados por una única estación de trabajo o un conjunto de ellas, puede ser excesivo para la capacidad de la red. En este caso alternativas tienen que ser evaluadas.

b) La latencia aceptable en el uso del aplicativo. Cuando alguien interactùe con el aplicativo, o estación de trabajo, apretando teclas o moviendo el mouse, el tiempo que el aplicativo lleva para reaccionar y mostrar el resultado en la pantalla, es conocido como latencia. Para algunos aplicativos se puede tolerar una latencia mayor, ya para otros es necesario que los resultados sean en tiempo real. La latencia va depender de la anchura de banda disponible entre la interface humana y el aplicativo, entre el cliente y el servidor, y de la capacidad de la máquina de ejecutar el código del aplicativo. Normalmente, para una menor latencia el aplicativo debe operar en la misma máquina de la interface humana, y esa máquina debe ser poderosa lo suficiente para ejecutar el aplicativo.

c) La política de seguridad de la Institución. Si los datos residen en las estaciones de trabajo distribuidas por toda la Institución, esto significa que si cualquier máquina sea robada, o estuviera accesible en un ambiente inseguro, los dados pueden ser perdidos o divulgados a terceros o a personas desautorizada. Por otro lado si los datos están centralizados en un servidor es necesario verificar la seguridad y privacidad de la conexión de los clientes al servidor. Pues si los datos están traficando de forma no criptografiada y con fallas en el control al

��


acceso, es posible que alguna persona no autorizada vea sus datos mientras trafican por la red. En este momento es necesario rever las normas de seguridad de la institución y analizar cual la mejor forma de adecuar las soluciones a esas normas.

d) La política de backup de la Institución. Si los datos residen en las estaciones de trabajo distribuidas por toda Institución, será necesario algún mecanismo de backup centralizado o la responsabilidad por el backup debe ser distribuida entre muchas personas, probablemente los propios usuarios. Un esquema centralizado de backup podría venir a ser complejo e iría requerir una alta anchura de banda de red y cooperación con los usuarios de las estaciones de trabajo (los cuales, por ejemplo, deben recordarse de no desligar sus máquinas en los períodos en que estuvieren marcados los backups). Ya en un sistema de Cliente Leve como los dados están centralizados en un servidor o en un conjunto de servidores, el backup se torna más fácil.

e) El dibujo del aplicativo. Si sea necesaria interacción humana con el aplicativo, él necesitará tener una interface con el usuario que puede estar en la estación de trabajo o en un servidor. Por ejemplo: un terminal IBM 3270 o DEC VT100 tiene todo el código de exhibición procesado en servidor. Por otro lado, un terminal basado en un navegador, metaframe, Terminal Server, X-window system, terminal gráfico, VNC divide el código de exhibición entre el servidor y el cliente.

f) La capacidad de estación de trabajo de ejecutar el aplicativo. En la arquitectura de Cliente Pesado, cuanto más capacidad de procesamiento los aplicativos exijan, más poderosa (y, por lo tanto, más cara) la estación de trabajo deberá ser.

g) La capacidad de la estación de trabajo de almacenar datos. Algunos aplicativos necesitan tener acceso a grandes banco de datos, los cuales sólo pueden ser sustentados por servidores especializados.

h) El desempeño de los servidores disponibles. Si un aplicativo es ejecutado remotamente en un servidor y no en la estación de trabajo, el servidor debe ser suficientemente poderoso para ejecutar todas las instancias del aplicativo necesarias, en el momento en que el número máximo de cliente esté en uso.

i) Costo total de implementación. Es importante destacar que, de la misma forma que cualquierproblema de ingeniería, no tiene una solución aplicable a todas las situaciones. Por ejemplo, una estación de trabajo puede operar de una determinada forma para un aplicativo y de otra para un aplicativo diferente. Esos detalles deben ser considerados como costos operacionales en los procesos de migración.

9.2 Arquitectura Básica de Referencia La Arquitectura Básica de Referencia (ABR) usada en estas directrices es elegida de forma

a ser aplicable en la mayoría de las situaciones. Ella puede volverse más “leve” o más “pesada” para aplicativos o perfiles específicos, caso necesario. Muchas veces la arquitectura utilizada en una Institución tiende a ser una combinación de varias arquitecturas, cada una elegida para situaciones específicas.

La ABR es caracterizada como una estación de trabajo sin condición específica, en la cual:

Todos los Aplicativos son ejecutados siempre que posible en la estación de trabajo y son almacenados en ella misma.

��


Ningún dato persistente es guardado en la estación de trabajo. Estos datos son almacenados en un servidor central.

Toda la autenticación y autorización son controladas por servidores centrales. d) La gestión del sistema es centralizada.

El objetivo es que las estaciones de trabajo queden operacionales y que no necesiten de soporte local.

Los aplicativos funcionan localmente para reducir cualquier problema de latencia, y la ABR presupone la existencia de banda ancha suficiente para que los datos sean mantenidos centralmente.

Además, ella presupone que todas las estaciones de trabajo sean esencialmente idénticas, permitiendo que cualquier persona se conecte a cualquier máquina que le sea permitido usar. Debe haber un régimen de gestión de sistemas eficiente, para mantener las instalaciones de los aplicativos de las estaciones de trabajos en armonía.

La ABR concentra todos los dados importantes de la Organización en los servidores centrales, visando facilitar la gestión de información y los procesos de backup, y disponibiliza estaciones de trabajo individuales, reduciendo el impacto en la eventual daño de una máquina cliente.

La manutención de los dados de forma local significa que hay una identificación de la máquina con el usuario. Esto causa problemas cuando el usuario muda de lugar o deja la organización. También transforma el lugar da estación de trabajo en local especifico de un usuario, dificultando la implementación de la sistemática de movilidad, donde el usuario tiene sus personalizaciones en cualquier estación que venga a utilizar (concepto hot-desking).

La manutención de dados de forma central elimina esas dificultades y exibiliza la utilización de la estación de trabajo. También permite que se mantenga el menor tamaño posible de almacenamiento local en la estación de trabajo. Con eso, la estación se transforma en un dispositivo del tipo “ligar y funcionar”, facilitando la instalación. De esa forma, la ABR es considerada una buena opción para diversas situaciones.

La ABR no es recomendada para laptops, o para estaciones de trabajo que no sean permanentemente conectados a la red de la Institución. Tales dispositivos necesitarían de más recursos para poder almacenar todos los dados localmente

��


CAPÍTULO 10

10. GRUPOS FUNCIONALES

Este capítulo visa presentar los sistemas y aplicativos en Software Libre disponibles de acuerdo con Su categoría. Para efecto de organización, los sistemas fueron separados en tres grandes grupos:

• Sistema Operacional – una vez que la mayoría de las consideraciones acerca del ambiente operacional es pertinente tanto a estaciones de trabajo como a servidores, ellas serán tratadas a parte;

• Estación de trabajo – consideraciones cuanto a aplicaciones vueltas para utilización en estaciones de trabajo.

• Servidores – abordaje de los módulos de servidores de diversos tipos.

Por su vez, el segundo y el tercero ítenes son organizados dentro de los grupos funcionales, definindo los tipos característicos de actividades genéricas del computador en una Administración. Esto significa que actividades específicas, como Gestión de Proyectos o Sistemas de Información Geográfica no son consideradas en esta versión del documento. Las actividades no consideradas deben ser, en general, las usadas por una pequeña proporción de la población de usuarios.

La grande cantidad de software libre disponible significa que, para muchas funciones, hay varios aplicativos diferentes disponibles. La elección del aplicativo a ser usado no es siempre evidente y debe ser pautada por directrices y especificaciones técnicas.

Otro punto a ser considerado, se refiere a exigencias específicas de la Administración Pública cuanto a los formatos de los archivos generados y padrones de interoperabilidad. En caso del Gobierno Federal Brasilero, esa reglamentación se encuentra establecida en la e-PING.

El modelo de referencia usado en estas directrices debe, por lo tanto, ser tratado como ejemplo de un sistema que, reconocidamente, funciona, más de lo que como una recomendación de sistema para ser usado en todas las circunstancias.

Las directrices discuten los asuntos tomadores de decisiones deben llevar en cuenta y puede acontecer que esas personas lleguen a conclusiones diferentes, pero igualmente válidas. En cualquier caso, restricciones locales al Administrador pueden tornar necesaria la escolia de un modelo diferente. La elección posible para cada grupo son discutidas en detalles en el capítulo 11, para los grupos principales y en el capítulo 12 para los grupos Auxiliares.

Hay algunos sitios de referencia útiles, que contienen listas de aplicativos de software libre, mostrando lo que hay disponible, y los candidatos a sustituciones de cuales aplicativos propietarios. El Sitio http://linuxshop.ru/linuxbegin/win- lin-soft- en/ es un ejemplo.

��


El sitio http://www.osafoundation.org/desktop-linux-overview.pdf, contiene detalles de muchos de los aplicativos discutidos a seguir. Se transforma, de esa forma, en un otro local donde los Administradores pueden obtener más informaciones, especialmente sobre desktop.

Uno de los puntos fuertes del software libre es el hecho de ser modular y poder ser montado de varias formas diferentes, permitiendo que los sistemas sean tallados para satisfacer las necesidades específicas. Esa modularidad es posible porque el software libre se adapta a interfaces abiertas y disponibles públicamente.

Esa flexibilidad puede, a veces, traducirse como una dificultad, ya que los Administradores pueden asustarse con la gran cantidad de opciones disponibles. Hay muchas organizaciones que pueden proveer ayuda y soporte, de la misma forma como existe en el mercado propietario.

10.1 Sistema Operacional Hay varios sistemas operacionales libres, y varias distribuciones (explicado a seguir).

Mientras, muchas personas sólo tienen oído hablar de GNU/Linux, y generalmente por el nombre Linux.

Un sistema operacional consiste de un kernel, programa responsable por la destinación de los recursos de la máquina y que opera en modo supervisor, junto con programas de soporte que operan bajo control del kernel en el modo usuario. El Linux es un kernel, pero demanda cargadores de soporte, compiladores, drivers etc. La mayor parte de esos programas de soporte son abastecidos por el proyecto GNU de la Free Software Foundation, siendo por lo tanto llamados de programas GNU. La conjunción de software GNU con el kernel Linux forma el sistema GNU/Linux, término correcto a ser utilizado.

El kernel del Linux es abastecido en pacote junto con un conjunto de programas de soporte y aplicativos, por algunas compañías como Conectiva, Red Hat ® , SuSE ® y Mandrake, como una Distribución. Los componentes del contenido de una distribución deben interactuar y el kernel puede ser compilado para poseer características específicas no disponibles como padrón. Por lo tanto, la elección de la distribución debe ser considerada, ya que cada una posee sus propias características nativas.

Hay otras Distribuciones como el Kurumin, Debian, Slackware y el Gentoo, que no son pre-parados por una organización comercial y esto puede tener implicaciones en la forma como el soporte es dado. El soporte para esas distribuciones viene de terceros o de accesos a listas de discusión y sitios en la Internet. Esas herramientas pueden ofrecer equivalentes niveles de cobertura.

La distribución Debian es reconocida por su estabilidad y robustez. Las versiones estables presentan códigos cuidadosamente testados por su comunidad de desarrolladores, y raramente incluye aplicativos que no sean distribuidos con licencia de código abierto.

El Gentoo es una distribución que contiene apenas el código fuente, lo que significa que la Administración puede construir sus propios binarios fácilmente, customizando la distribución a su ambiente y sus equipos. Construir una distribución del cero demanda tiempo, sin embargo, una vez producidos los binarios, ellos estarán disponibles y podrán ser fácilmente copiados. Esta es una nueva distribución con características propias que deben ser consideradas. Por el hecho de que la mayor parte de las distribuciones fornecen su código de fuente completo, es

��


posible costear cualquier una de ellas de la misma manera, sin embargo el Gentoo debe ser más receptivo a este tratamiento.

El Kurumin1 es una distribución enjuta que roda a partir del CD y que facilita la migración de sistemas propietarios para GNU/Linux. Él adopta un sistema de instalación y configuración simple usando scripts que facilitan mucho la vida del usuario. Es basado en GNU/Debian y utiliza el sistema de detección de hardware y configuraciones automática del Knoppix.

Las distribuciones comerciales vienen en paquetes, con diferentes niveles de soporte. La distribución disponible vía Internet tiene soporte generalmente por un año, y entonces, los usuarios tienen que hacer un upgrade. La mayor parte de las compañías ofrecen una versión Enterprise que tiene garantía de soporte por cinco años o más y que es basada en versiones estables. Tales versiones también poseen un contrato de soporte asociado a ellas que, a veces es llamado de licencia, aunque el código sea licenciado usando el GPL o LGPL y no puede ser licenciado de otra forma. Lo que muchos Administradores desean es la disponibilidad de tales distribuciones estables y que las mismas poseen soporte. En verdad, una razón para mudar para software libre es la inexistencia de presión para upgrade de forma constante y desnecesaria. Las compañías prometen un reparo de defectos de backport independiente de cualquier renovación contractual.

Se entiende que plataformas GNU/Linux son más indicadas tanto para estaciones de trabajo cuanto para servidores, una vez que ofrecen varias opciones de herramientas y paquetes de configuraciones, servicios nativos, y presentan alta robustez y estabilidad, comparativamente a las plataformas propietarias. Con relación a servidores, la Administración podrá optar también por la utilización de plataformas BSD2: FreeBSD3 , OpenBSD4 o NetBSD5.

10.2 Estación de Trabajo

Conforme ya destacado, GNU/Linux es el sistema operacional más indicado para estaciones de trabajo. Los sistemas de archivos conteniendo binarios (tales como usr) pueden ser montados en formato “sólo para lectura”, para evitar que los usuarios muden su contenido y los remanecientes montados en formato “no ejecutable”, para evitar que el código sea ejecutado a partir de ellos. Para reforzar, la interface del usuario sólo debe permitir a los usuarios ejecutar programas a través de interfaces pré-definidas. Esto significa que el acceso a línea de comando o a habilidad de crear o mudar ítenes de menú o ícones, deve ser removida. Los sistemas de archivos que contienen datos volátiles basados en el usuario deben ser montados a partir de un servidor NFS central. La autenticación de usuario es realizada por un servicio de directorio LDAP.

Se sugiere todavía que servidores centrales puedan fornecer direcciones IP y configuraciones de red a través de DHCP y resoluciones de nombre por un servidor DNS en el momento en que la computadora es prendida y comienza a cargar el sistema operacional.

��


10.2.1 Gerenciadores de Ventanas

Hay varias opciones, que van de los gestores leves de ventanas muy simple, como el icewm, hasta gestores de sesión completas como los incluidos en el GNOME e KDE. La elección depende del uso pretendido.

De los gerenciadores de ventanas, el KDE y el GNOME son los más maduros, pero existen otros en desarrollo aproximándose rápidamente. El GNOME tiene el soporte de la Sun Microsys-tems y de miembros de la GNOME Foundation. Existen opciones de gerenciadores más leves, que serán utilizados en equipos de menor capacidad. Dos ejemplos son los ZAPPWM 6, que poseen características bastante interesantes y un tamaño muy reducido (apenas 2 Mb), y el Blanes 20007 , que tiene la ventaja de una interface gráfica muy parecida con algunas versiones de software propietario.

La Ximian ® lanzó una estación de trabajo basado en lo GNOME llamado XD2. Él trabaja sobre varias distribuciones de base diferentes, inclusive el Red Hat ® e SuSE ® . A Ximian ® se dedicó especialmente a integrar los varios diferentes aplicativos, para certificarse de que trabajan de forma similar. Eso significa que ellos incluyeron sus propias versiones de algunos productos como OpenOffice.org.

Otra opción para Gerenciadores de ventanas es el XFCE 8 que consume menos recursos de hardware que el GNOME o KDE y facilita la migración usuarios de otros sistemas Unix, como Solaris ® , AIX ® , etc.

La elección del gerenciador de ventanas será probablemente definida por el usuario, a menos que la Administración defina un ambiente por cuestiones gerenciales o de padronización. En la hipótesis de limitación de hardware, se sugiere que sean utilizados aplicativos dibujados para la interface gráfica que está siendo utilizada. Los Aplicativos dibujados para trabajar en un ambiente funcionarán en otro, pero habrá necesidad de que se carguen bibliotecas específicas, lo que podrá influenciar en la performance del equipo.

10.2.2 Oficina

Abrange la creación, modificación e impresión de archivos conteniendo datos del negocio en formato padrón, tales como cartas y relatos. También la creación, modificación e impresión de planillas y presentaciones. Es necesario que haya utilitarios para gerenciar esos archivos. Debe ser posible leer y escribir formatos propietarios de la mejor manera posible, cuando esto sea necesario.

Cuanto a los formatos abiertos, obviamente, estos deben ser pasibles de lectura y escrita sin ninguna dificultad. Debe ser disponibilizado el idioma portugués brasileño y, preferencialmente, otros posibles idiomas que serán utilizados, como español e inglés, además de configuraciones de monedas y alfabetos que sean útiles.

Oficinas – Opciones

Un paquete de oficina muy utilizado en la actualidad, principalmente en la administración pública, es el Microsoft ® Office. Incluye los aplicativos propietarios de editor de texto, planilla,

��


presentación y correo electrónico, junto con sus formatos también propietarios. Esos formatos no son abiertos y mudan de una versión del MS-Office para otra. Hasta los propios productos de Microsoft ® no pueden garantir la capacidad de leer y escribir un archivo legado con total precisión, a no ser que los archivo hayan sido creados en la misma versión del producto.

Los aplicativos software libre actualmente son capaces de leer formatos cerrados con tal precisión que los problemas encontrados no son diferentes de los vistos con el uso de las diferentes versiones de los propios productos propietarios. Cuanto más antiguo el formato, mejor los aplicativos del software libre trabajan con el mismo. Los aplicativos software libre tienden a ser mejores en la lectura de archivos en formato propietarios de los que en la escrita de ellos. En términos generales, los aplicativos software libres pueden ser usados con confianza para operaciones con similares propietarios.

La excepción es cuando es requerido algún tipo de trabajo colaborativo y, lo mínimo, una de las partes insista en usar un formato propietario. La lectura, la alteración y la rescrita de los archivos en esos formatos pueden introducir anomalías que el uso de un aplicativo propietario único no haría. Por lo tanto, se debe tener en mente que este tipo de error también puede ocurrir caso sean usadas diferentes versiones del software propietario. Se sugiere en estos casos el uso del formato RTF (Rich Text Format) o mismo texto puro, hasta que formataciones sean requeridas. Para archivos que sólo permiten lectura, sin actualización, el formato PDF o PS puede ser usado.

Se puede juzgar también que la interface del usuario debe ser tan similar cuanto posible al software propietario, para minimizar costos de re-entrenamiento. Algunos scripts de configuración hacen esto de forma automática, por ejemplo, en la suite OpenOffice.org, pudiendo ser utilizadas para instalación en larga escala.

Modelos y Macros son comunes en muchas Administraciones. Ellas tienen un formato propietario cerrado y tendrán que ser reescritos.

Tres conjuntos de oficina que pueden ser considerados en software libre son el OpenOffice.org, KOffice e GNOME Office.

Está disponible en la Internet un estudio piloto que compara la capacidad de los varios conjuntos de oficina en software libre de trabajar con los archivos propietarios:

a. OpenOffice.org

El OpenOffice.org es un conjunto de aplicaciones para oficinas basado en el StarOffice, producido por una empresa alemana llamada StarDivision. La Sun Microsystems, compró la StarDivision y franqueó el código a la comunidad de software libre. Continua colocando en el mercado una versión del OpenOffice.org, todavía llamada de StarOffice, que vende a un precio mucho más barato que los paquetes propietarios correspondientes.

El StarOffice y el OpenOffice.org son esencialmente idénticos, a no ser por:

• La Sun Microsystems fornece soporte comercial para el StarOffice.

��


Figura 10.1: Editor de Texto do OpenOffice.org.

• El StarOffice posee un sistema de banco de datos construido internamente (Adabas).

• El StarOffice tiene algunos filtros extras para migración para/de otros pacotes de oficina (por lo tanto, el filtro del Wordperfect no es disponible en GNU/Linux por razones de licencia).

• El StarOffice posee algunas fuentes propietarias.

• El StarOffice sólo es disponible en un conjunto de idiomas un poco más restricto

(Alemán, Francés, Italiano, Inglés, Español, Sueco y Portugués Brasilero; además de algunos lenguajes asiáticos).

• El OpenOffice.org es actualizado más frecuentemente de que el StarOffice.

Ambos los aplicativos son comparables a las suites de software propietario, sin embargo algunos componentes de estas suites pueden no estar contemplados, pudiendo ser obtenidos a parte, también en software libre. Ambos paquetes trabajan con la mayor parte de los archivos de formato propietario, hasta incluso, las versiones más recientes de estos, aunque la compatibilidad pueda peorar con las versiones más nuevas. No trabajan con archivos protegidos por señas (excepto para protección de planillas página a página) y tienen algunos problemas con objetos gráficos con link con OLE. Aún así, hay algunas de las mejores integraciones de formatos de archivos de otras herramientas de oficina.

Si la Administración está migrando de un ambiente propietario, el OpenOffice.org posee una versión para este sistema operacional, proporcionando a los usuarios un contacto inicial con el nuevo software en un ambiente familiar.

La Sun Microsystems está estableciendo relaciones con compañías, para traducir macros y modelos propietarios para una forma compatible con el StarOffice.

Ellos también ofrecen una interface Java, sin embargo sólo reconocen actualmente el JDK de la Sun Microsystems. La Sun Microsystems anunció un proyecto para desarrollar un traductor de Visual Basic sea Applications (VBA) para Java.

��


Figura 10.2: Editor de presentación del OpenOffice.org.

La versión disponible para copia del OpenOffice.org.br contiene el diccionario portugués brasileño,además existen diccionarios para diversos idiomas disponibles. Ya existen versiones pre-construidas en más de 25 lenguas diferentes.

Aunque el OpenOffice.org no ofrezca actualmente un paquete de banco de datos, él tiene interfaces ODBC y JDBC con muchos sistemas comunes de banco de datos, incluso con los populares del software libre. Además, no hay filtros de conversión para Wordperfect, sin embargo el lanzamiento futuro está planeado. Ambos trabajan en una tira de sistemas operacionales que incluyen ambiente propietario y libre.

El OpenOffice.org posee una versión en portugués brasileño siendo constantemente desarrollada, disponible para copia en la dirección http://www.openoffice.org.br. En este sitio del OpenOffice.org.br – Proyecto Brasil, hay una serie de documentaciones sobre instalación, uso y funcionalidades avanzadas del producto. Vea más en la dirección citada, dentro del área de Ayuda – Documentación.

b. Koffice

Este es el componente office de la estación de trabajo KDE. Es un paquete integrado que ofrece procesador de textos, planillas, mapas y gráficos, presentaciones, ilustraciones, generación de relatos y herramientas para fluxogramas, con un desktop opcional llamado Workspace.

Los filtros de archivos propietarios no son tan buenos cuantos los ofrecidos por el OpenOffice.org. El no tiene un lenguaje macro, pero existen scritps disponibles.

c. GNOME Office

Es una colección de programas escritos en los padrones GNOME y pueden, por lo tanto, integrarse unos a los otros, tiene una interface similar con el usuario y deben ser capaces de empotrarse unos a los otros.

��


Figura 10.3: Editor de Texto Kword.

El OpenOffice.org es considerado ahora parte del GNOME Office, aunque no se prenda a los padrones del GNOME. A Ximian ® , particularmente, está trabajando para tornar el OpenOffice.org más compatible con el GNOME e incluye su propia versión en el más reciente producto para estaciones de trabajo, XD2. Vea http://www.gnome.org/projects para más detalles.

El GNOME Office tiene muchos componentes, incluyendo el AbiWord (procesador de texto), el Gnumeric (planillas), Sodipodi y Sketch (dibujo de gráficos vectoriales), el Gimp (edición de imágenes), el Eye of GNOME (exhibición de imagen), el Día (gráficos de vectores, similar al Visio), el MrProject (Gerencia de Proyectos) y el Agnubis (gráficos para presentaciones), entre otros.

Figura 10.4: Editor de Texto Abiword

Estos componentes presentan grados variados de utilización. Por ejemplo, el Abiword es una solución eficiente para procesamiento de texto, pero presenta limitaciones

��


cuanto a la creación de tablas el Agnubius también presenta limitaciones; el Gnumeric se muestra una buena opción de planilla electrónica.

Figura 10.5: Gnumeric.

El Gnumeric, en particular, tiene el objetivo de desarrollar una planilla que puede hacer todo que los equivalentes en software propietario hacen, y todavía diversas funciones adicionales. Los desarrolladores vienen de una formación financiera y incluyeron varias características que tornan el Gnumeric especialmente útiles para aplicaciones financieras. Es en esa área que ellos creen que el Gnumeric sea superior al software propietario.

El Gnumeric trabaja con diversos formatos de archivos, incluso compatibles con software propietario y otros softwares libres disponibles en el mercado.

La gama de productos disponibles es interesante y, junto con el OpenOffice.org, ofrecen un buen número de soluciones diferentes. Por lo tanto, caso sea necesario un conjunto integrado, el OpenOffice.org es la mejor solución actualmente.

10.2.3 Gerenciamento de Proyectos La gerencia sistematizada de proyectos viene siendo adoptada en muchas organizaciones,

sean ellas públicas o particulares, de grande o pequeño porte. Existe una variedad de herramientas libres destinadas a auxiliar el trabajo de planeamiento y acompañamiento de proyectos. Algunas de estas aplicaciones son instaladas en servidor y accesadas vía navegador web, mientras otras son instaladas en las propias estaciones de trabajo, sirviendo a sus usuarios. En cualquier de los casos, la aplicación necesita ser utilizada a partir de una computadora personal y, por lo tanto, se aborda esta clase de aplicativo dentro del tópico "Estación de Trabajo".

Los recursos que cada aplicativo de auxilio a la gerencia de proyecto disponibiliza varían bastante habiendo algunos más completos y otros con funciones para determinada actividad,

��


como por ejemplo el dibujo de gráficos. Son citados a seguir algunos ejemplos de estas herramientas.

GanttProject

El GanttProject 9 es una alternativa para gerenciamiento de proyectos que no necesiten de elevado grado de sofisticación. Posee la ventaja de ser multiplataforma lo que facilita la migración posterior del sistema operacional. Es ejecutado localmente, en estaciones de trabajo.

DotProject

El DotProject10 es accesado vía navegador web, debiendo ser instalado en un equipo con

servidor web, soporte a PHP y banco de dados MySQL. Es un sistema de gerencia de proyectos bastante completo, contando con interfase en portugués, customizable. Posibilita el registro de usuarios múltiplos, de modo que el acceso se torna personalizado y específico a los proyectos en que

Se está actuando. Otras funcionalidades incluyen:

• Gerenciamiento de Clientes y Instituciones (empresas, departamentos, etc.); • Lista de los proyectos; • Lista jerárquica de actividades;

• Gráfico de Gantt; • Repositorio de archivos; • Lista de contactos; • Calendario; • Forum de discusión.

Planner

El planner11 es una herramienta para planeamiento, agendamiento y acompañamiento de proyectos, vueltos para GNOME Desktop.

El proyecto es realizado por la Imendio, que desarrolla el software en cooperación con la comunidad

Netoffice

El Neoffice12 es una herramienta de gerenciamiento online con la colaboración de los equipos, gerencia de usuario, niveles de acceso simultáneo, tareas, proyectos, acompañamiento de tiempo, histórico de mudanzas de tareas, acompañamiento de archivos aprobados, notas, sitios de proyecto de clientes, CRM, gráfico de Gantt entre otros.

10.2.4 Correos Esta sección contempla la creación, el recibimiento y la presentación de correo

electrónico, incluso soporte para correo seguro

Cliente de e-mail – Opciones

Hay un gran número de clientes de e-mail (MUA) basados en texto y con interfase gráfica disponibles en el campo de software libre.

Para los que están acostumbrados a usar clientes en software propietario y desean tener algo

��


similar, el Evolution es una fuerte opción. El Evolution no es sólo un cliente de correo, pero también un Gestor de Informaciones Personales (Personal Information Manager – PIM). Él posee

soporte a integración LDAP y puede, por lo tanto, accesar datos de nombres y direcciones electrónicos de la Administración. Está siendo desarrollado activamente por la Novell ® . La Novell ® tiene un producto llamado Evolution Connector que permite al Evolution conectarse al Exchange Server ® 2000 y 2003. El Connector era propietario pero tuvo su código abierto y disponibilizado bajo la licencia GPL recientemente, no más necesitando de licencia para ser utilizado.

Figura 10.6: Cliente de e-mail Evolution.

El Evolution tiene una interface con el usuario muy similar a un software propietario muy

común, tornándose fácil para que las personas aprendan. También posee algunos aspectos útiles como las Pastas Virtuales. Más informaciones sobre él en:

http://www.novell.com/products/evolution/.

El Kmail y el Sylpheed son alternativas de clientes de e-mail. Ambos son muy buenos y se integran con los principales ambientes de estaciones de trabajo del software libre. Si la estación de trabajo es KDE, se usa Kmail, mientras que si la estación de trabajo es GNOME, se usa el sylpheed.

En términos de clientes con soporte a correo seguro, Evolution da soporte al GPG, pero no al S/MIME, aunque se espere que lo haga en breve. El Mozilla Mail da soporte al S/MIME,

��


Figura 10.7: Cliente de e-mail Kmail.

Pero no al GPG o PGP, a pesar de que lo hará en breve. El Kmail da soporte al S/MIME, al GPG y PGP, y fue desarrollado recientemente para funcionar como un cliente junto al servidor groupware Kontact.

Pero no al GPG o PGP, a pesar de que lo hará en breve. El Kmail da soporte al S/MIME, al GPG y PGP, y fue desarrollado recientemente para funcionar como un cliente junto al servidor groupware Kontact.

Muchos paquetes de groupware incluyen también paquetes de IMAP y POP3. En general, ellos no son tan buenos como el Evolution, pero pueden ser suficientes, si se integraren bien con las otras funciones del groupware.

En algunos casos, puede ser mejor migrar algunas categorías de usuarios a una interface de usuario basada en la web. Existen diversas opciones disponibles en ese segmento, entre ellas el SquirrelMail13, el IMP14, y el NeoMail15.

La Open Systems Application Foundation tiene un producto llamado Chandler, que está en fase inicial, pero vale la pena monitorar para el futuro. Es un competidor potencial del Evolution.

10.2.5 Calendarios y Groupware

El área de la creación y gestión de calendarios, catálogos de direcciones/contactos, correo, charlas, lista de tareas. Los calendarios también deben permitir funciones como la organización de reuniones y la reserva de salas.

El Evolution es una opción para calendario personal y gestión de contactos. En el momento parece difícil encontrar un groupware con software libre. Solo soluciones basadas en la web están realmente disponibles, aunque recientemente el proyecto Kontact haya producido una solución usando el Kmail como cliente. Por lo tanto, para una verdadera solución de software libre, tendria que ser utilizado un navegador para accesar el groupware.

��


10.2.6 Navegador El mismo que Navegador, programas usados para visualizar páginas Web, como el

Internet

Explorer, Netscape, Opera, Konqueror, etc. Al inicio los navegadores eran meros visualizadores

de páginas en html, pero ellos fueron evolucionando e incorporando nuevas funciones. Hoy, un navegador como el Internet Explorer es casi un sistema operacional completo, capaz de rodar aplicativos (Java, XML, Active-X, etc.) entre muchas otras funciones. Es por eso que se volvió tan complejo desarrollar un navegador y tornarlo compatible con todas las tecnologías. Hay mucha cosa a ser implementada.

��


Programa responsable para acceso a contenidos en la Internet. También puede incluir funcionalidad de creación de documentos para publicación.

Diversidades de Navegadores

Los principales navegadores en software libre son Mozilla, Galeon y Konqueror. Hay otros como Lynx, que es sólo texto, y es frecuentemente usado como base para navegadores para personas con deficiencia física, y el Mozilla Firefox (anteriormente conocido como Phoenix y después como Firebird), una variante del Mozilla.

El Mozilla es un proyecto software libre abrangente, incluso siendo la base para el Netscape 7. Él contiene correo y componentes de noticias junto con catálogo de direcciones y una herramienta de autoría de páginas de Internet. Grande parte del código de Mozilla es usado por otros proyectos, incluso el Galeon y el OpenOffice.org

Figura 10.10: Navegador Mozilla.

El Mozilla es una alternativa en el caso de requerirse un producto que incluya los recursos de lector de correos y catálogo de direcciones. El Mozilla también sería una opción en el caso de la Administración estar usando en el momento estaciones de trabajo con ambiente propietario, entonces sería necesario que el navegador trabajase en el ambiente existente, para permitir a los usuarios un contacto inicial con el nuevo software, en un ambiente familiar.

El Galeon es sólo un navegador y es proyectado para ser pequeño y rápido. Es basado en el Gecko, el motor de renderización en el cual se basa el proyecto del Mozilla, junto con una interface de usuario GNOME. Ambos, Galeon y Mozilla dan soporte a todos los padrones de Internet abierta y pueden ejecutar Java y Javascript escritos apropiadamente. El Galeon es un navegador rápido, de una única función, que posee una buena interface con el usuario.

El Galeon es un navegador proyectado para ser leve y rápido. Es basado en el Gecko, el motor de renderización en lo cual se basa el proyecto del Mozilla, junto con una interface de usuario GNOME. Ambos, Galeon y Mozilla dan soporte a todos los padrones de Internet abierta y pueden ejecutar Java y Javascript escritos apropiadamente.

��


Algunos contenidos requieren plugins que sólo están disponibles para ambientes propietarios. El producto propietario CodeWeavers CrossOver Plugin permite que plugins que trabajan en ambiente propietario trabajen en el GNU/Linux.

Figura 10.11: Navegador Galeon.

El Konqueror es el navegador escrito para estaciones de trabajo KDE es también usado como un gerenciador de archivos “arrastre y suelte”. Se basa en el motor de renderización KHTML, con Mozilla Gecko como opción, junto con una interface de usuario KDE. El Konqueror permite el acceso a todos los protocolos soportados en el KDE. Por ejemplo, permite adentrar compartimientos Windows ® vía el protocolo SMB. Además se integra de manera transparente con otros programas y permite acceso a todos los dispositivos e impresoras.

Figura 10.12: Navegador Konqueror.

��


El Firefox se aproxima de su versión final 1.0, estando actualmente en el canditado a distribución 0.9. Él ha sido bien visto por el mercado, siendo apuntado como un aplicativo que podrá revolucionar este segmento.

10.2.7 Banco de Datos Personales o Locales

Son las herramientas de gerencia de informaciones estructuradas en banco de datos personales que son utilizados de forma local, o sea, en la propia estación de trabajo. Tiene soporte a través de algunos productos que también ya son considerados SGBD’s centrales y completos.

Para que tengan funcionalidades similares a un banco de datos ad hoc, se utilizan herramientas externas de acceso a estos mecanismos. Tales herramientas disponibilizan funcionalidades que incluyen: manutención (criar, alterar y remover) de tablas, de índices, consultas específicas (utilizando el SQL como lenguaje de consulta), relatos para impresión o visualización, y la posibilidad de construirse formularios para la automación del procesamiento de los datos almacenados en el banco de dados, como una tela amigable para inclusión de datos o un cuadro de los datos existentes para una navegación interactiva que facilite la elección de registros para alteración/exclusión.

Bancos de datos personales pueden ser basados en el MySQL o en un producto de groupware basado en la web, como phpGroupware. El Firebird, por poseer una forma de instalación simplificada, puede también ser considerado para esta función.

Conectividad de Bancos de Dados

La mayor parte de los productos SGBDs dan soporte directo al APIs con ligaciones de lenguaje C. Algunos también dan soporte naturalmente a C++. Acostumbran ofrecer normalmente conectividad ODBC o JDBC. Algunos también ofrecen conectividad.NET.

Hay un producto llamado Unix-ODBC16 que provee conectividad del tipo ODBC a los programas Unix y GNU/Linux, incluyendo soporte para KDE y GNOME.

10.3 Servidores

El sistema operacional en software libre sugerido es el GNU/Linux. Para máquinas altamente seguras como firewalls, los sistemas basados en BSD, como el OpenBSD, pueden ser una buena opción, por características de fuerte seguridad a ellos atribuidos.

Las principales funciones de los servidores son fornecidas por los servicios descriptos a seguir.

10.3.1 Servicio de Correo

��


El Correo es una área compleja, con muchos componentes lógicos, y tienen riqueza de aplicativos software libre, algunos de los cuales sobreponen funcionalidades. También es estrechamente ligado a otras cuestiones, incluyendo control de virus y de spam.

La elección de los aplicativos apropiados es compleja, y está inclusa en el Apéndice B una discusión detallada sobre esas cuestiones, junto con una definición de todos los términos usados aquí.

Opciones de MTA - Transferencia de Correo

Algunos de los principales MTAs del software libre son Sendmail, Postfix, Qmail, Courier-MTA y Exim. Hay muchos otros, pero estos son considerados los principales, por ser usados en larga escala.

Tradicionalmente, los sitios Unix-like usaban el Sendmail17 como su MTA. Infelizmente, él presentó un registro de seguridad pobre, y también es notoriamente difícil de configurar.

Todos los otros tienen buena reputación en nivel técnico y la opción puede ser difícil. Por lo tanto, hay una diferencia significativa en el padrón de la documentación disponible, en portugués.

1. Courier-MTA18 hace parte de una familia con un MTA, MDA (Mail Delivery Agent), MAA 1. y pacote webmail (SqWebMail) disponible. Cada parte puede ser usada por si sólo, o

integrada con el resto de la familia.

2. El Postfix19 es una alternativa compatible con el Sendmail, objetivando ser rápido, fácil de 3. administrar y seguro. Posee arquitectura modular, diversas opciones de configuración y

extensiones para atender enumeras demandas diferentes, tales como antivirus, anti-spam, almacenamiento de los usuarios en una base LDAP, etc.

4. Qmail20 Un MTA, rápido, moderno, que posee una grande base de usuarios, es un software abierto, que posee algunas restricciones cuanto a redistribución de alteraciones y binarios. exige un poco más de esfuerzo para la configuración de Servidores de e-mail complejos.

5. Exim21, porque es tan capaz cuanto el Sendmail y al mismo tiempo más fácil de configurar y,

probablemente, más seguro. Él también entiende las opciones del Sendmail y puede, por lo tanto, funcionar como sustituto compatible a este.

La opción no es evidente y los Administradores deben tomar sus decisiones con base en las necesidades locales, y los conocimientos técnicos de cada programa.

Opciones de MAA y MDA - Depósito y Entrega de Correo

Muchos Administradores prefieren que los clientes usen el almacenamiento central de correo, en vez de descargar los mensajes para almacenamiento local en la estación de trabajo del cliente. Para esta función, recomendamos el uso de IMAP.

Algunos de los servidores IMAP en software libre bien conocidos: UW-IMAP (a veces llamados sólo de IMAP), Courier-IMAP y Cyrus. (O UW-IMAP22 tiene una historia de seguridad pobre y no es muy recomendado. De los otros dos, el Courier-IMAP23 es largamente conocido por ser el más fácil de configurar. Él tiene un tamaño pequeño y trabaja bien con el

��


Postfix y con el Courier-MTA. Es la parte MAA de la familia Courier. Él necesita del maildir como formato de almacenamiento de correo.

El Cyrus24 usa su propio formato de almacenamiento de correo, que es similar al maildir y necesita de su propio MDA para completar el almacenamiento de correo.

Ambos, Courier-IMAP y Cyrus soportan el TLS (un protocolo padrón de autenticación y privacidad.

Hay varios MDAs, por ejemplo, el procmail25 , el maildrop, que es parte de la familia del Courier, y abastecimiento de la Cyrus. Los MDAs también poseen la habilidad de filtrar el correo de acuerdo con reglas sofisticadas, lo que es útil si el MUA usado no tenga dispositivos de filtro.

Una opción de referencia es el Courier-IMAP sin MDA. No es necesario un MDA, porque el Exim es capaz de escribir directamente para las estructuras maildir y el Evolution tiene sus propios filtros con mucha capacidad.

Otras herramientas de Correo

Existe un grande número de filtros de e-mail libres, herramientas Anti-Spam, que evitan que anexos ejecutables sean bajados juntamente con los e-mails, y diversos otros tipos de opciones. Actualmente existen muchos proyectos (cerca de 360) de este tipo cadastrados en el Sourceforge.net. Más informaciones en:

http://sourceforge.net/softwaremap/trove_list.php?form_cat=29.

El SpamAssassin26 es probablemente el más utilizado de todos los filtros anti-spam. Su principio

de funcionamiento es buscar por asignaturas heurísticas típicas de SPAMS en el encabezamiento y no

cuerpo de mensajes y atribuir a cada ocurrencia encontrada una puntuación. Después de eso la puntuación es verificada, si exceder un límite de lo que es considerado normal, el mensaje es declarado como SPAM. Él puede rodar directamente en MTA o en MUA. En el sitio oficial pueden ser encontradas diversas informaciones, como configurarlo y utilizar en diversos MTA’s diferentes y MUA’s.

El Anomy Sanitizer27 es un conjunto de filtros que permiten si procurar por virus en los mensajes

de e-mail, deshabilitar códigos HTML y Javascript potencialmente peligrosos, bloquear o remover anexos basado en sus nombres de archivo. De esta forma usted no precisa recibir, por ejemplo, visual basic scripts, entonces usted no necesita preocuparse con el riesgo que recibir este tipo de archivo implica.

El MailScanner28 es un e-mail virus scanner, protector de vulnerabilidades, y marcador de spam. Él utiliza el SpamAssassin para una detección de los spams, y es dibujado para tratar con ataques del tipo Denial Of Service. Él va a detectar archivos zip protegidos por señas y aplicar una verificación de nombres de archivos a sus contenidos. Es muy fácil de instalar, y suporta en una gran cantidad de servidores de e-mail, Postfix, Sendmail, Exim, Qmail, Zmailler y diversos antivirus: Sophos, MacAfee, F-Prot, F-Secure, DrWeb, ClamAV, BitDefender, RAV, Panda, y muchos otros antivirus. Él puede ser integrado en cualquier sistema de e-mail.

El Fetchmail29 es un completo, bien documentado y robusto aplicativo para hacer copia de

emails remotos y realizar encaminamiento entre servidores. Él soporta casi todos los protocolos de acceso remoto a e-mail en uso actualmente en la Internet, tales como: POP2, POP3, RPOP,

APOP, KPOP, todos los tipos de IMAP, ETRN, y ODMR. Él también permite IPv6 y IPSEC. Soporta diversos tipos de autenticación tales como NTLM, IMAP RFC1731 encrypted method. Como él lleva el correo para una máquina (la transferencia es iniciada por la máquina

��


receptora), él es útil donde, por razones de seguridad, los administradores no quieren abrir una puerta para la internet en su máquina, para permitir que el correo les sea impuesto (donde el remitente inicia la transferencia), como sucedería con el modelo SMTP normal.

Estos son algunos de las decenas de aplicativos filtros de e-mail LIBRES. Existen actualmente más de 2200 proyectos de softwares libres relacionados a e-mail, desde clientes, a servidores, aplicativos web, filtros anti-spam, webmail, antivirus, etc cadastrados en el sourceforge.net, eso proyectos pueden ser visualizados en http://sourceforge.net/softwaremap/trove_list.php?form_cat=28.

Dificultades posibles

Para almacenar dados en un servidor LDAP es necesario elegir un esquema. El esquema debe ser compatible con todos los clientes que poseen acceso a los datos. Felizmente, algunos paquetes vienen con un esquema que no sólo da soporte as sus necesidades, pero también a las necesidades de varios otros paquetes en general.

El Courier-IMAP viene con un esquema, pero el Exim no. Se descubrió que el esquema del Courier da soporte al Exim también pero es necesario verificar si este soporte abrange toda la capacidad del Exim. Fueron descubiertos algunos problemas con el archivo de configuración del LDAP para el Courier, que ya pueden estar resolvido.

Para usar el Courier con el Whoson30 son necesarias algunas correcciones en el Courier. Algunas de ellas fueron disponibilizadas en el sitio del Whoson, además estaban desactualizadas y necesitaban de actualizaciones significativas para trabajar con la versión seleccionada del Courier.

10.3.2 Servicio de Webmail Muchas veces puede venir a ser conveniente la utilización de una interface web para

acceso a los emails a envés de utilizarse de un cliente de email. Existen diversas herramientas libres para Servidor de Webmail Entre ellas podemos destacar:

• Horde31 Es un framework de aplicaciones en php que posee una suite de aplicaciones web, que abarcan Webmail (IMP32 ), Gerenciador de Contactos (TURBA33 ), Gerenciador de Calendarios (Kronolith34 ).

El IMP (Internet Messaging Program) Webmail Client es un cliente de e-mail escrito en PHP que permite acceso a las cuentas vía POP3 o IMAP. Requiere la instalación del PHP y del Horde en el servidor. En su versión 3.2 permite opciones avanzadas como la busca en múltiplas cajas de correo, identidades, y un navegador de caja de correo jerárquica, bien como una interface de usuario enxuta.

• OpenWebmail35 es un sistema de webmail basado en el Neomail, que posee las siguientes

características: – Para los Usuarios:Auto Login, Soporte a Múltiplas lenguajes y Charsets, Strong

MIME Message capability, Busca de contenido completa, Pasta de Rasguño, opción de confirmación de lectura, Verificación de escrita, Soporte a Pop3, Soporte a filtros de email, Soporte a AntiSpam a través de SpamAssassin36, Soporte a AntiVirus a través de ClamAV37, Calendario con soporte a anotaciones y notificaciones, Soporte a

��


WebDisk, Compresión HTTP.

– Para el Sistema: Acceso rápido a las pastas, Varios métodos de autenticación, soporte a PAM, soporte a utilización de un servidor smtp de relay remoto, soporte a Virtual Host, soporte a alias de usuarios, Configuración por usuario de capacidad, entre otros.

• SquirrelMail38 es un webmail basado en padrones abiertos escrito en PHP4. Incluye soporte para los protocolos IMAP y SMTP, todas las páginas son reenderezadas en HTML 4.0 puro (sin JavaScript) para un máximo de compatibilidad entre los diversos browsers. Posee pocos requerimientos y su instalación / configuración es simples. Características/funcionalidades: soporte a cuaderno de direcciones (privado y compartido); gerenciamento de pastas; pesquisa de contenido; filtros de mensajes; gerenciamento de seguridad sobre anexos; soporte a anti-spam; verificación ortográfica; agenda (privada y compartida); gerenciamento de tareas (personal o de grupo); colecta de mensajes de otras cuentas pop3; trabajo con cualquier MTA vía SMTP o sendmail wrappers; soporte a IMAP-SSL; criptografía de mensajes (soporte a S/MIME y GPG/OpenPGP), entre otras.

• Uebimiau39 es un servicio de webmail multiplataforma, totalmente desarrollado en PHP, con

distribución GPL. El producto fue desarrollado en Brasil y posee las siguientes características:

– Para Usuarios: Soporte a SMTP, POP3, MIME, Multi Temas, procura de términos en

el contenido de mensajes, recibimiento de archivos anexados, envío de anexos, soporte al gerenciamento de pastas (basurero, caja de entrada, ítenes enviados y pastas locales), catalogo de direcciones, soporte a Múltiplas Lenguajes, personalizar orden de mensajes, envío de e-mail en formato HTML y límite de cuotas.

– Para el Sistema:No utiliza banco de datos de almacenamiento pues los mensajes son almacenados en pasta la cual el Uebimiau es instalado, dependencias con JavaScript y PHP, puede ser implementado con Sendmail/Qmail para facilitar gerencia de mensajes.

10.3.3 Servicio de Antivirus

Si los sistemas de software libre estuvieren configurados correctamente, los virus tendrán efecto hasta cierto punto limitado. Por lo tanto, hay el problema de pasar virus para los locales que ejecutan otros sistemas operacionales. Así, el control de virus es necesario principalmente para evitar la transmisión de virus para otros locales que no sean basados en software libre. Aunque el

correo electrónico sea una de las principales formas de transmisión de virus, no es la única, por lo tanto es necesario hacer una barredura general de los archivos para evitar la transmisión por otros medios. En términos de correo electrónico, la mejor manera de ejecutar tales productos es como parte del MTA. O Postfix y el Exim, fornecen medios de incorporar tales filtros.

Un ejemplo de software libre que puede actuar como una solución de antivirus para servidores

de Correo Electrónico, es el Clamav Antivírus40 . Por lo tanto, es posible garantir que los archivos ejecutables puedan ser instalados apenas por el sistema administrador, a través de la configuración de los

��


sistemas de archivos, tanto en los servidores cuanto en las estaciones de trabajo. Por lo tanto, es importante que los administradores de sistemas tengan certeza de que los archivos que están instalando son confiables, por ejemplo, a través de la verificación de la firma del vendedor de la Distribución en los archivos.

Existen antivirus propietarios que circulan en ambiente GNU/Linux, que en casos especiales, pueden ser considerados.

10.3.4 Servicio de Calendario y Groupware

El servicio de calendario es una cuestión todavía no completamente definida. Esto ocurre debido a la ausencia de padrones abiertos para comunicación entre los clientes y el servidor central. Consecuentemente, los productos desarrollados hasta ahora, usan la distribución basada en la web, y eso puede no proporcionar a las personas la forma de trabajo exacta a las cuales están habituadas con el uso del software propietario.

Se puede asumir que los productos listados en la tabla a seguir usan distribución basada en la web, a no ser por afirmación en contrario. Todos ellos son parte de conjuntos de groupware que poseen una gran variedad de otros aspectos. Fueron hechas algunas integraciones interesantes de recursos en esos productos.

La mayor parte de los productos de groupware son escritos en PHP o Perl, y pueden, por lo tanto, ser customizados.

Detalles de Productos Groupware

El e-groupware41 abrange servicio de trabajo en grupo vía web contando con correo electrónico, agenda de contactos, agenda de compromisos, wiki, fóruns, y otras herramientas de trabajo colaborativo. Fue desarrollado en lenguaje PHP y usa banco de dados PostgreSQL o MySQL.

Posee extrema compatibilidad con otros clientes de email para importar lista de contactos, es altamente configurable y su grande diferencial es importar dados de la agenda del Exchange ® /Outlook ® .

El phpGroupware42 diponibiliza servicios de calendario, catálogo de direcciones, e-mail, servicios de noticias, entre otros.

Otra opción es el Horde43, que es una estructura para rodar otros aplicativos. Por ejemplo, el Imp, un cliente de correo electrónico vía web, el Turba, un gestor de contactos, y el Kronolith, un calendario.

El NullLogic parece sólo ofrecer interfaces con o idioma inglés, además el phProject, el Tutos, el Twiggi y Twiki, todos ellos dan soporte a una serie de idiomas.

Un producto muy reciente del software libre es el OpenGroupware44 . Él es el aplicativo SKY RiX, anteriormente propietario, que fue transformado por sus dueños en software libre. Todavía no hubo tiempo suficiente para investigarlo, además, todo indica que irá tornarse muy in uente.

Otro producto reciente es el Kolab45 . Ese producto tiene un cliente con base en el Kmail, y vale la pena investigarlo, particularmente si el KDE sea elegido como interface con el usuario o si el Kmail sea elegido como MUA para dar soporte a S/MIME.

Calendarios Personales y Agendas

��


Todos los productos pueden mantener calendarios personales y listas de tareas, a no ser por disposición en contrario.

Calendarios de Grupo

El Tutos, el Twiggi y el NullLogic, todos ello da soporte a calendarios.

El Tutos permite control en niveles de tiras, del individual al grupo de trabajo y del grupo de proyecto para todos.

En el NullLogic, no se puede mantener calendarios privados con relación a otros miembros del grupo, pero las tareas si.

Organización de Reuniones

Muchos de los productos incorporan ítenes de agendamiento de recursos, que pueden ser usados para planear reuniones.

El Tutos permite la alocación automática de personas, junto con notificación de correspondencia automática para aquellos que no constan del calendario compartido (como los que están en

otras organizaciones). Ellos mantienen una lista de aceptaciones y manda membretes vía correo, caso deseado. El phProject es similar, y trabaja con notificaciones de texto SMS.

El NullLogic da soporte a todos los recursos arriba, excepto para destinación de salas. Sincronización de PDA

El phProject tiene un recurso adicional que sincroniza con los PDAs basados en PalmOS. La sincronización del PDA también recibe soporte como parte del GNOME y del Evolution. La mayoría del PDAs populares puede ser sincronizada.

10.3.5 Servicios de Web Servidores Web El servidor de web más popular es el Apache, lo cual, de acuerdo con la investigación

Netcraft 46 , posee más de 60% del mercado y su porción está creciendo. Una combinación de productos cada vez más popular está bajo el nombre LAMP: Linux, Apache, MySQL y PHP. Ella proporciona una estructura para que los sitios accesen bancos de datos SQL a través del lenguaje PHP. Todos los componentes son software libre.

El Apache cuenta con una extensa gama de módulos e extensiones asociados. Otros servidores podrían ser utilizados para tareas específicas, como por ejemplo, el Zope (vea en el próximo ítem) podría ser usado para gestión de contenido.

El proyecto Apache contiene varios subproyectos, uno de los cuales es llamado de Jakarta y cubre el lado servidor de uso del Java. El Jakarta en si, consiste de subproyectos, dos de los cuales son el Tomcat y el Slide. El Tomcat ofrece un producto para servlets Java, en conformidad con los padrones JSP. Otra opción de servidor de aplicativo basada en Java es el JBoss47. El Slide es implementación basada en Java de la WebDAV, que permite gerenciamiento de contenido. Veaa http://www.apache.org/ para más detalles.

De todos esos, el Apache es, de lejos, el más popular. Él trabaja actualmente en cerca de 63% de los sitios públicos y está ganando más mercado de forma estable, por lo tanto hay mucha experiencia a considerar al planear una migración. El Apache es un servidor modular,

��


con un motor de protocolo nuclear y una grande selección de módulos para propósitos específicos.

Portal - Gestión de Contenido

1. Zope48 es dibujado para proveer soporte dinámico de contenido de la web y se basa en un modelo orientado para el objeto. Es un paquete interesante, pues combina un sistema de gerenciamiento de contenido con un servidor de web y un sistema de modelos en un paquete. El Zope también da soporte a add-ons (llamados productos) y se basa en el lenguaje Python orientado para objeto. Es común encontrar el Zope colocado “atrás” del Apache, en una configuración multiservidor, donde el Apache sirve contenido estático y actúa como acelerador basado en cache para las partes del sitio generadas por el Zope. Un proyecto interesante basado en el Zope es el Plone49 .

2. PHP-Nuke50 es un SGC (Sistema de Gerenciamento de Contenido), termino advenido del Inglés “Content Managment System”, reconocido fácilmente por la popular sigla, CMS. El sistema recibe este nombre porque integra, todas las herramientas necesarias para crear y gerenciar un portal, sea él comercial o institucional. Es caracterizado por la grande cantidad de funciones presentes en la instalación padrón y/o en los Módulos adicionales. Ya el nombre PHP-Nuke viene del inglés nuke, que posee varios significados, siendo el más común un dispositivo o arma nuclear. Por lo tanto, PHP-Nuke puede significar ”Poder en PHP”. PHP-Nuke es escrito 100% EM PHP, lo que significa portabilidad, pudiendo ser ejecutado en casi todos los Sistemas Operacionales existentes. De entre ellos los más utilizados: *NIX, Microsoft ® Windows ® y Apple ® Mac OS. Para tener un portal construido en PHP-Nuke es necesario:

• Un servidor de páginas (preferencialmente Apache); PHP;

• Un servidor de Banco de datos SQL (MySQL, mSQL, PostgreSQL, ODBC, ODBC_Adabas R, Sybase ® o Interbase ® ).

3. Xoops51 Es un sistema de portal que utiliza la tecnología PHP integrada al banco de datos MySQL. Su código permite la construcción de portales seguros y confiables tanto para uso personal cuanto profesional.

4. Drupal52 Es una plataforma dinámica de website que permite publicar, manipular y orga-nizar una gran variedad de contenido, el Drupal integra diversos recursos populares de CMS(content management systems), weblogs, herramientas colaborativas y de discusión en un único paquete, fácil de ser usado.

5. JetSpeed-153 Integrante de la sección de portales del proyecto Apache, es una implementación de un Portal de Información Empresarial utilizando Java y XML. actúa como un centro a través del cual informaciones de múltiplas fuentes pueden ser disponibilizadas

Hay actualmente muchos productos de gerenciamento de contenido de software libre, como muestra el sitio http://www.oscom.org/matrix/index.html.

10.3.6 Servicio de Gestión de Documento Registro y Recuperación

La Gestión del Documento puede, y talvez deba, ser pensada como una forma de gestión de contenido y de uso de trabajo. Se recomienda que sea adoptada una solución con base en las

��


soluciones de gestión de contenido y groupware disponible. En particular, los que usan la WebDAV pueden proveer las soluciones más útiles.

Algunos de los productos de groupware dan soporte para gestión de documento:

• El Tutos incluye un sistema de gestión de documento que también posee gestión de

versión.

• NullLogic tiene capacidad de almacenar, indexar y bajar archivos simplemente. No parece ofrecer un sistema de gestión de mudanza. Posee un mecanismo generalizado de query que puede ser instalado para ofrecer indexación.

Trabajo colaborativo

Esta función puede ser implementada ad-hoc por el simples cambio de documentos entre las personas. Para que haya colaboración, las partes necesitan entrar en acuerdo cuanto al formato del documento, y actualmente, muchas personas usan formatos propietarios como padrón. Ese procedimiento significa que las partes necesitan confiar unas en las otras, porque esos formatos pueden ser eficientes portadores de virus. Además, los formatos propietarios no son ideas como padrón, porque mudan constantemente. Esto significa que las partes también necesitan concordar cuanto a la versión del software propietario a ser usado.

Hay presión para que se adopte formatos de documentos basados en padrones, particularmente los basados en el XML. El OpenOffice.org, que provee un padrón de documento basado en el XML, podría ser usado como base para la colaboración.

Un abordaje más estructurado sería el de adoptar una solución de gestión de contenido/flujo del trabajo, como descrito anteriormente.

El producto de groupware del Tutos permite que los documentos sean sujetos al control de una única persona o por todos dentro de un grupo definido. El NullLogic y el Twiki también posee controles sofisticados.

10.3.7 Servicio de Bancos de Datos Para sistemas que necesitan de un banco de datos rápido como las aplicaciones con

interface WEB, el MySQL puede ser sugerido; para sistemas que necesitan de mayor robustez, el PostgreSQL y el Firebird son opciones.

Bancos de Datos Centrales – basados en aplicativos

Los sistemas de banco de datos del software libre disponible incluyen Misal, PostgreSQL y Firebird. Ellos tienen características y aplicabilidad significantemente diferentes. El MySQL es un banco de datos SQL leve, interesante especialmente para aplicaciones web y similares. Es adecuado a la utilización de las tablas tipo “MyISAM” en situaciones en que la lectura predomina sobre la escrita. La empresa mantenedora del MySQL, que posee representación en Brasil, ofrece otros productos para necesidades específicas como el MySQL Cluster y el MaxDB ® . Es utilizado el sistema de doble licenciamiento, donde la licencia elegida puede ser GNU/GPL el comercial, dependiendo de la necesidad de la Administración.

El PostgreSQL es otro SGBD bastante completo, comparable a los más robustos del mercado, con los recursos necesarios para trabajar con grandes volúmenes de datos. Se

��


presenta como una opción para sustituir los SGBDs más vueltos a las soluciones corporativas. Incluye recursos y características necesarios en aplicaciones corporativas de porte, como conformidad con SQL 92, integridad referencial, triggers, stored procedures, transaction commitment, row level locking, varios métodos alternativos de autenticación y derechos de usuarios y grupos, bien como load balancing y replicación de bancos de datos, entre otros. En las versiones a partir da 7.x , el desempeño fue muy aprimorado y soporta grandes cargas transacionales de forma rápida, linear y previsible.

El Firebird es una versión de banco de datos Interbase de la Borland, liberado bajo una licencia del software libre. Una grande parte del código es común con el Interbase y, como tal, puede ser considerado maduro. Juntamente con el PostgreSQL, el Firebird también se presenta como una solución para aplicaciones corporativas.

El OpenOffice.org 1.1 soporta directamente el MySQL o cualquier otro SGBD a través de las herramientas de conectividad ODBC y JDBC.

Desempeño

El desempeño del banco de datos depende mucho del tamaño de las tablas envueltas y de la complejidad de las queries, además de ajustes finos y configuración del equipo donde están siendo ejecutados. Algunos SGDBs del software libre ya se mostraron robustos lo bastante para las más diversas aplicaciones. De entre ellos podemos citar el PostgreSQL y el Firebird.

Diversos productos propietarios están disponibles para rodar en GNU/Linux y pueden ser considerados opciones para aplicativos de bancos de datos pesados.

Conectividad (ODBC, JDBC, etc...)

Vea el ítem 10.2.7

10.3.8 Servicios de Seguridad Todos los grupos funcionales deben ser configurados teniendo en cuenta la seguridad. La

seguridad, en nivel de software, sólo puede trabajar si también está presente en la estructura mayor de gestión de seguridad.

Criptografía

Datos en tránsito: Datos confidenciales en LANs internas deben ser criptografados siempre que sea posible. Datos sensibles enviados por la Internet u otras redes compartidas, deben estar siempre criptografados. Esto puede ser hecho a través de la canalización de conexiones en protocolos como: SSH, SSL/TLS y IPSEC, que pueden ser implementados productos como openssh, stunnel y FreeSWAN, respectivamente.

Datos almacenados: Datos confidenciales mantenidos en dispositivos móviles deben ser criptografados en disco. Lo ideal es que todos los datos sean criptografados, pero eso impondría ónus significativos en performance y administración que ni siempre serán deseables o aceptables. Hay varios sistemas de archivos que permiten esto, por ejemplo, en el sitio http://www.tldp.org/HOWTO/Disk- Encryption- HOWTO/ hay un procedimiento que permite criar un disco, partición o archivo criptografado con el algoritmo AES.

��


Autenticación:

Métodos seguros pueden identificar, de modo único, una persona o máquina que sean parte de una comunicación con otras personas o máquinas. Eso incluye firmas digitales e infra estructura de llaves públicas (ICP). Ninguna ICP fue evaluada en la etapa actual de este proyecto. Todas las autenticaciones fueron hechas en contraposición a la seña padrón de un banco de datos LDAP.

Autorización:

Determina lo que una persona o máquina, después de ser autenticada, puede hacer y en que circunstancias. Eso normalmente hace parte del sistema operacional (como en el caso del control de acceso a archivos y directorios) o del código del aplicativo (como en el caso de bancos de datos que controlan lo que un usuario puede hacer en una base de datos o tabla). El Role Based Access Control o RBAC, es una forma más sofisticada de realizar la autorización y el control de acceso, fue definido por el NIST en los Estados Unidos y está disponible para el Linux. (Veahttp://csrc.nist.gov/rbac/ ).

También es interesante investigar las funcionalidades del tipo ACL (Access Control List) disponibilizadas recientemente en la versión 2.6 del kernel del GNU/Linux.

Servidor Proxy

Hay disponibles diversos servidores proxy en software libre. De entre los servidores proxy para HTTP, el Squid54 es el más popular, posee elementos refinados para control de acceso, banda, jerarquías de caches, proxy reverso etc. Él posee un producto asociado (squidguard), que evita el acceso a sitios indeseados, clasificados por contenido.

Firewalls

Todos los sistemas operacionales actuales en software libre poseen firewalls del tipo filtro de paquetes, de los cuales la mayoría es stateful. Lis firewalls del tipo stateful son aquellas que mantienen la información sobre las conexiones en curso y sus flujos de datos en el firewall, y permiten pasaje de paquetes que son asociados a esas conexiones, mientras eliminan paquetes que no lo son.

Firewalls que no son stateful, examinan cada paquete, sin guardar cualquier registro de paquetes anteriores, siendo menos eficientes. Plugins especializados están disponibles para protocolos complejos como FTP y H.323 (Voz sobre IP).

El Iptables, actualmente incluido en el GNU/Linux, Ipfilter, incluso en el FreeBSD, y Packetfilter, incluso en el OpenBSD, son buenas soluciones de firewall. Esas tres soluciones son de forma general equivalentes. Una buena práctica para firewall externo (independiente del producto utilizado) es tener dos modelos diferentes entre la conexión de la red pública y los servidores internos (lo que puede incluir el roteador con filtro de paquete).

Redes Virtuales Privadas (VPN)

OpenVPN: Disponible para la mayoría de los sistemas del tipo Unix, esta es una herramienta madura y poderosa, a pesar de no seguir un padrón específico para VPNs. Los recursos incluyen autenticación con llave pública, compresión dinámica, gestión de anchura de banda y la capacidad de trabajar con NAT (Network Address Translation). Vea http://openvpn.sourceforge.net para más informaciones.

��


IPSEC: IPSEC es un conjunto de protocolos para la comunicación criptografada y/o autenticada entre dos computadoras. Existen algunas implementaciones libres como el FreeS/WAN 55 y sus derivados, y para versión de GNU/Linux 2.6 se puede usar el IPSEC nativo del kernel. Por seguir el padrón definido es posible hacer la comunicación entre productos, sistemas operacionales y dispositivos que sigan el mismo padrón. Para más informaciones de como implementar IPSEC vea en http://www.ipsec- howto.org/t1.html.

CIPE: Este es menos maduro de que los otros dos y el soporte de llave pública todavía es experimental. Por lo tanto, puede funcionar con NAT y es dibujado para ser leve. Está disponible también para ambiente propietario y es incluido con el Red Hat ® Linux (usted puede hasta configurarlo con la herramienta Control de Dispositivo de Red de ese sistema). Más informaciones están disponibles en http://sites.inka.de/~W1011/devel/cipe.html.

10.3.9 Servicios de Gestión A pesar de no ser apenas un servicio del tipo provido por un servidor, la Gestión puede ser

vista como una cuestión estructuradora, así como los demás servicios aquí citados. Por este motivo ella está siendo tratada aquí.

El sitio http://www.infrastructures.org provee considerable detallamiento en como administrar una red de máquinas, de servidores y estaciones de trabajo, y tiene varias herramientas de software libre para una serie de tareas de manutención

El sitio muestra que la gestión del Unix, y por extensión, GNU/Linux, tiende a ser hecha por herramientas a ser agrupadas a partir de unidades de función única menores. Ese abordaje modular es extremamente poderosa y es lo que permite a los administradores del sistema Unix e GNU/Linux ser muy eficientes y efectivos.

Gestión de Usuario

La manutención de los usuarios y de grupos de usuarios, incluyendo productos de gestión de señas como Directory Administrator y gq, permite que los bancos de datos LDAP sean mantenidos.

Gestión de Configuración

Aunque un cliente bien proyectado, gerido de forma central, deba tener un mínimo de instalación local, la actualización de su configuración sin reinstalación de lo cero es todavía deseable para grandes redes, de las cuales si espera que se queden activas durante algún tiempo. Por ejemplo, si un servicio esencial central es mudada, los clientes pueden necesitar ser re-configurados para usarlo.

Manutención de la Configuración Manual:

En redes pequeñas, los Administradores pueden mantener actualizaciones de configuración manualmente, ya que podrían programar actualizaciones. Mientras problemas similares de sincronización se aplican. La modificación manual de los archivos de configuración, generalmente almacenados en archivos plain text, es particularmente sujeta a presentar errores de digitación.

��


Cfengine: El GNU Configuration Engine56 automatiza la configuración remota de clientes de red.

Él da suporte a una gran variedad de preferencias UNIX y su poderoso concepto de clase permite que diferentes grupos de clientes sean administrados con un mínimo de configuración. Agentes autónomos en los clientes pueden mantener archivos de texto, interfaces de red, links de archivos y permisiones, almacenamiento temporáneo y sistemas de archivos montados.

Algunas de las primitivas que pueden ser automatizados usando el cfengine son:

• Conferir y configurar la interface de la rede. • Editar archivos de texto. • Hacer y mantener links simbólicos, incluso links múltiplos a partir de un único

comando. • Conferir y establecer permisiones de propiedad de los archivos. • Remover basura de archivos que confunden el sistema. • Montaje automatizada y sistematizada de sistemas de archivos (en Unix). • Conferir la presencia de archivos importantes y sistemas de archivos. • Ejecución controlada de scripts de usuarios y comandos de embalaje.

System Configurator: El System Configurator57 hace parte del System Installation Suite, siendo utilizado por el System Installer. Él puede configurar y mantener muchos componentes de una instalación GNU/Linux a través de muchas distribuciones tales como redes, almacenamiento, huso horario y booting.

Webmin: O webmin permite la administración de sistemas Unix y GNU/Linux vía browser con opciones para administración de diversos recursos de los servidores, usuarios, gerenciamento de paquetes, sistemas de archivos, cuotas, además de servidores FTP, SMTP, www, DHCP, DNS, etc.

Gestión de Software

Esa sección cubre la manutención de sistemas de clientes desde la configuración inicial del nuevo hardware hasta actualizaciones de software en andamiento y configuración, y algunas tecnologías para facilitar su gestión.

Instalación del Sistema

La instalación del sistema es la configuración inicial del software es la configuración necesaria para mantener una máquina. Máquinas construidas en fábricas pueden no poseer cualquier sistema operacional, o llegar pre-instaladas con software. Máquinas antiguas con software indeseado también pueden ser reutilizadas por la instalación de un sistema nuevo en su dirección.

La primera tarea de un instalador de sistema es cargar la máquina albo. El método más antiguo es el de cargar vía disquete. Los disquetes están siendo eliminados, pues son lentos, no confiables y ofrecen espacio muy pequeño para el software de instalación de sistema en padrones modernos. Muchas máquinas construidas desde 1997 soportan iniciación a partir de CD-ROM por la emulación del sector de boot del disquete. Esto es más rápido y ofrece mas espacio para el software de boot inicial y cualquier otro software requerido. La manera más sofisticada de cargar la máquina es a través de la red. Ni todos los firmware de BIOS o placas de red soportan ese nuevo recurso. El

��


Pré Execution Environment (PXE) es parte del padrón de la industria Wired for Management (WIM) y habilita la mayor parte de las máquinas compradas desde 1998 a ser cargadas por la red local.

El instalador debe adentrar los medios de instalación apropiados conteniendo software de más alto nivel para ser ejecutado después que la máquina esté cargada. Característicamente eso tendrá que ser almacenado en un CD-ROM local o un servidor de archivo de red. Un único disco compacto puede ser usado para almacenar una imagen de software, y la capacidad de un CD-ROM debe ser suficiente para una estación de trabajo de Administración básica, usando compresión de archivo regular. Esa imagen puede ser apropiada si fuera poco probable que el software cambie, o si sólo fuera necesaria una base de instalación estable para la adición de software adicional. Generalmente, una instalación de red es más flexible, puede ser más rápida, ofrece mayor capacidad, y escala mejor las instalaciones paralelas y múltiplas, de que compartir discos de instalación entre clientes.

El instalador de sistema transfiere el software de la mídia seleccionada para el disco rígido local de la máquina albo, y la prepara para la inicialización. Eso envuelve conocimiento de hardware, verificación de la capacidad del disco y configuración de detalles de red.

Algunos de los posibles métodos de instalación son discutidos a seguir:

1. Instalación Manual:La instalación más básica se da a través de un administrador de sistema. El software viene en discos compactos, incluso en un disco de instalación bootable. Algunas indicaciones automáticas pueden guiar el administrador, pero en última instancia, toda la customización es manual. Ya que la selección del paquete, la división del disco rígido, la configuración del hardware y los detalles de la red deben todos ser inseridos manualmente, este proceso es lento y tiende al error humano. La mayor parte de las distribuciones tienen su propio programa de instalación.

2. Clonaje de Imagen: Si la instalación de clones casi idénticos es adecuada, un origen puede ser manualmente instalada y después replicada. Distribuciones como Knoppix, el Kurumin y otros pueden ser usados para copiar las imágenes del sistema de archivos de origen para otras máquinas. Configuraciones y customizaciones pueden ser adicionadas por scripts ejecutados antes o después de la instalación. Una vez que sistemas de archivos enteros pueden ser copiados para el disco en vez de los archivos en ellos contenidos, esto puede ofrecer un menor tiempo de instalación. Mientras, configurar “clones” no idénticos; es menos eficiente y requiere habilidad mayor en el sistema.

3. Instalación Totalmente Automática: La FAI59 instala la distribución Debian automáticamente. Los paquetes de software son accesados de un sitio Debian, que puede ser espejado localmente para obtener velocidad o customización. El kernel de instalación disponibilizado puede ser cargado a partir de la red o de disquete, todavía la carga por CD-ROM aún está siendo perfeccionado actualmente. Aunque el FAI tenga sido dibujado para replicación idéntica de máquinas en cluster, el software cfengine, descrito anteriormente, es usado para configuración de sistema y permite extrema flexibilidad, si necesario.

4. System Imagen: El System Imager60 hace instalación de sistema, configuración y manutención para grandes redes de máquinas, de preferencia con hardware similar, a través de varias distribuciones. El puede cargar a partir del disquete, del CD-Rom o de servidores de red PXE. Ambas las instalaciones, tan Debian cuanto Red Hat ® fueron testadas, todavía el software System Configurator usado ayuda a dar soporte a todas las distribuciones GNU/Linux. Un origen es instalado y configurado manualmente. Entonces sus sistemas de archivos son espejados para un servidor de imagen, donde las máquinas albo son instaladas. Si la origen esté actualizado, esas mudanzas serán propagadas para clientes usando rsync. Aunque rsync envíe minimamente las diferencias de archivos por la red, el puede requerir memoria significativa para hacerlo. Como las modificaciones son relativas al origen, el System Imager es más apropiado para clientes albo con hardware idéntico o muy parecidos.

5. Kickstart de la Red Hat R: El Kickstart61 es el software de instalación automatizada de la

��


Red Hat ® . El instala distribuciones De la Red Hat ® de CD-ROM, disco rígido o red, y carga a partir de red, CD o disquete. EL instalador Anaconda ofrece texto o interfaces gráficas y puede ser interactivo o totalmente automatizado por un archivo de configuración. El software de detección de hardware Kudzu da una gama de dispositivos automáticamente. Opciones de instalación generalizadas pueden ser montadas en el archivo de configuración y extensiones adicionadas con scripts de instalación pre y pos. Con su software inteligente de configuración y detención, el kickstart puede ser utilizado para automatizar instalaciones similares entre una variedad de albos de hardware. La selección de paquetes del Red Hat ® distribución padrón es directa, pero las actualizaciones o extensiones también pueden ser incluidas por la customización del proceso kickstart.

Manutención del Software

Instalaciones de software no permanecen estáticas durante su tiempo de vida. Serán lanzadas actualizaciones de software como de seguridad o de arreglos de problemas, después de la instalación inicial. Además, será requerida la remoción o adición del paquete para gerenciar el software sin la reinstalación de un sistema entero.

Las actualizaciones deben, siempre que posible, ser efectuadas por un proceso controlado por el equipamiento que demanda la actualización, después de realizada comparaciones de los paquetes instalados con un servidor principal. Se debe evitar que los usuarios realicen las actualizaciones.

Manutención del Software Manual: Los administradores del sistema pueden mantener el software actualizado manualmente. Eso puede envolver adentrar el cliente albo de forma remota, copiar paquetes de actualización e instalarlos con el gerenciador de paquete original de la distribución. Mientras, eso ofrezca un rígido control al administrador, tiende a errores y dificulta la sincronización de grandes colectas de máquinas. Algunas distribuciones ofrecen herramientas de actualización para mantener sus paquetes padrón, pero todavía requieren intervención manual y pueden no disponibilizar extensiones a la distribución básica.

Debian APT El APT es un juego de herramientas padrón fornecido con la distribución Debian GNU/Linux, que permite actualizaciones automatizadas al software instalado en una máquina. Él puede verificar dependencias entre paquetes de software instalados en la máquina y disponible de los softwares depositarios, a los cuales fue configurado para verificar, y para recuperar y instalar actualizaciones relevantes disponibles de un depositario. Las organizaciones pueden montar sus propios servidores depositarios de software a ser instalado en sus clientes, bien como CDROMs conteniendo los programas y las actualizaciones (Debian incluye herramientas para criar y mantener tales depositarios), pueden usar depositarios disponibles por el Debian y otros, o usar cualquier combinación de esas fuentes de software actualizado. Los CDROMs pueden ser creados como reproducciones de los depositarios. La configuración de donde serán bajadas las actualizaciones (cdrom, internet, intranet) pueden ser determinadas y protegidas para acceso apenas al administrador de los sistemas. Así viabilizando control total de los programas y versiones que pueden ser instalados y actualizados. El APT fue transportado para trabajar en sistemas operacionales basados en RPM, tales como Conectiva, Red Hat ® Linux y Mandrake, donde provee funcionalidad similar, y de algunas formas perfeccionadas por comparación al Red Carpet.

Novell ® Ximian ® Red Carpet

Novell ® Ximian ® Red Carpet Daemon62

Es una herramienta de actualización de software disponibilizada gratuitamente por la Ximian ® . Comenzó como un gerenciador de paquete gráfico para el

��


Novell ® Ximian ® Desktop 2 (paquete de software e interface de Ximian ® ), pero ofrece ahora acceso seguro a la línea de comando remota y más canales de software incluso actualizaciones de distribución. Mandrake, SuSE ® y Red Hat ® son soportados actualmente. Él ofrece administración remota fácil y automación posibilitando que un numero bien grande de clientes pueda ser mantenido de forma central. Puede ser configurado para actualizar software a partir de canales customizados. Novell ® Ximian ® Red Carpet Enterprise R

ES un producto servidor propietario, utilizado para facilitar la gestión de grandes colectas de software. El Novell ® Ximian ® Red Carpet Enterprise ® ofrece la ventaja de control cen-tralizado de políticas de actualización de paquetes, permitiendo el agendamiento de tareas y man-teniendo el tráfico de red para busca de actualizaciones dentro de LAN. Sin el Novell ® Ximian ® Red Carpet Enterprise ® todas las estaciones de trabajo utilizan directamente el acceso la internet para buscar actualizaciones. En ambientes corporativos ese comportamiento no es deseado. El Novell ® Ximian ® Red Carpet Enterprise ® consolida en el servidor corporativo todas las actualizaciones necesarias, reduciendo el consumo del link de internet. La interface gráfica no debe ser usada, pues permite a los usuarios controlar las actualizaciones. La interface con la línea de comando debe ser incorporada a los scripts que actualizan las máquinas automáticamente.

Red Hat ® Enterprise Network

La Red Hat ® ofrece una gama de servicios de actualización de software como parte de su Enterprise Network63. El más poderoso es su Satellite Server, que permite costomización completa de actualizaciones y errata. Todos los servidores dan soporte a los clientes padrón, los Update Agent, para distribución. Los comentarios contra la permisión de uso de la interface gráfica pueden ser aplicados aquí de la misma forma que los do Red Carpet arriba

Gestión de hardware y monitoramiento de sistema

El hardware puede ser monitorado con relación a fallas y fallas potenciales, por ejemplo, uti-lizando el SMART – discos rígidos habilitados y hardware de verificación de salud del sistema. Sistemas de hardware y software también deberían ser monitorados con relación a las fallas, fallas potenciales, ausencia de servicio y falta de capacidad.

www.redhat.com/software/rhen/software_delivery.

MRTG y Snmpd: El MRTG64 es una herramienta de monitoramento de seña originalmente para rastrear y representar en gráfico el uso de la capacidad de los links de red. Además, se desarrolló como una herramienta capaz de rastrear virtualmente cualquier mudanza de cantidad, y puede ser usada para monitorar variables como procesador, memoria y uso de espacio del disco, uso de los servicios de la red incluyendo estadísticas sobre volúmenes de correspondencia procesada, páginas de la web servidas, etc, temperatura del sistema y velocidades de la ventilación, y otras variables. El Snmpd 65 es un servidor de gestión de sistema que puede operar en cualquier estación de trabajo de una organización. Disponibiliza información de gestión de sistema para clientes: típicamente para un cliente SNMP central, que agrega estadísticas a partir de algunas máquinas. El MRTG puede actuar como tal cliente y desempeñar esa función, forneciendo una visión general gráfica de un grande número de máquinas de clientes.

Nagios: El Nagios66 (anteriormente conocido como NetSaint) es un hospedero customizable, provee servicios y monitoramiento de red y sistema de gestión. Es capaz de monitorar servicios de red y desempeñar varios procedimientos de recuperación, caso descubra que un servicio no está

��


disponible o está presentando problemas, incluso invocando scripts de recuperación automática y alertando los administradores del sistema para el problema. El Nagios también puede fornecer relatos y visiones generales del status corriente y pasado de los servicios que monitora.

Smartd: El conjunto de herramientas SmartMon Tools67 incluye un daemon llamado smartd, que es dibujado para monitorar el SMART (Self-Monitoring, Analysis and Reporting Technology), función de los modernos drives de disco rígido. Como esos dispositivos son uno de los componentes que más fallan en una computadora moderna, el SMART pretende monitorar parámetros de drive y notificar un administrador de sistema sobre fallas potenciales antes que ellas pasen. El smartd es dibujado para recibir esas notificaciones y actuar, a través del alerta al administrador del sistema.

Servicio de Impresión

LPRng: LPRng 68 es una implementación desarrollada del antiguo sistema BSD padrón lpr/lpd. Contiene algunos aprimoramentos que lo hacen mucho más fuerte y fácil de manosear de que los productos originales. El autor es particularmente entusiasmado al garantir que el LPRng es seguro. Hasta poco tiempo atrás, esa era probablemente la elección para gestión de impresora, pero recientemente el CUPS progresó y la elección ahora es menos evidente.

Sistema de Impresión Unix Common: El Common Unix Printing System o CUPS69 es dibujado para ser un sistema de impresión Unix “pronto para la empresa”. Es basado en el pa-drón Internet Printing Protocol o IPP e incorpora una función navegación, que disponibiliza detalles de los nombres y características de impresoras, para que sean distribuidos automatica-mente por la red. El CUPS también incorpora una interface usuario basada en la web para administrar y configurar las impresoras. Los drivers son disponibles para las impresoras más comunes.

Kprint y GNOMEPrint: Tanto KDE cuanto GNOME incorporan sus propios subsistemas de impresión, que pueden tener interface con aplicativos del usuario y con la mayor parte de los sistemas de impresión utilizados, incluyendo LPRng y CUPS.

10.3.10 Servicio de Backup y Recuperación Supone que todos los datos del usuario y de la Administración estén en un o más servido-

res. Es necesario ser capaz de incluir archivos de forma incremental, encontrar itenes removidos con archivos específicos y restaurar archivos individuales o sistemas enteros de archivo. Hacer el backup de los datos del usuario y tiende a ser más fácil en sistemas de software libre que en ambiente propietario, porque los archivos de datos del usuario, incluyendo sus datos de configuración, están normalmente contenidos en un único directorio.

Remoción y Recuperación

Esos dos programas son disponibles como parte de la mayoría de las distribuciones y son utilizados algunas veces junto con tar y cpio en scripts customizados para backup y recuperación de máquinas individuales.

Amanda: Amanda70 es un producto cliente-servidor dibujado para backup de múltiplas máquinas enun dispositivo individual. También es capaz de hacer backup de ambientes propietarios a través del Samba.

��


Bacula: El Bacula71 permite backup gerenciado de varias máquinas de la red a través de la instalación de daemons disponibles en varias plataformas, incluso win32. Se torna una opción para backup con requisitos de complejidad para agendamiento, compactación de datos de varias máquinas en un servidor.

10.3.11 Sistema de Lista de Discusión Uno de los sistemas de lista de discusión en software libre más utilizado es el Mailman.

Mailman: El Mailman 72 es un software libre para controlar Listas de Discusiones electrónicas y Newsletters. El MailMan es integrado con la web, tornando fácil para los usuarios controlar sus cuentas y para los dueños de las listas gerenciaren sus listas. Él es un software bastante maduro y completo, posee diversas características entre ellas:

– A través de la web criar y remover listas de discusión. – Soporte a las Diversas Lenguas, – Soporte a la "Real Name"para los usuarios – Moderación de los mensajes, – Filtro de Tópico

basado en Expresiones Regulares, – Control de privacidad, – Autoresponse, – Usuarios pueden alterar algunas de sus opciones de entrega de mensajes globalmente

para todas las listas en el servidor, incluyendo su seña, status de entrega, real name, etc. – Procesamiento Automático del Bounce, – Filtro de Contenido, – Digest delivery, – Filtros de Spam,

10.3.12 Sistemas de Informaciones Georeferenciadas Sistemas de Informaciones Georeferenciadas son importantes herramientas de base digital

para el almacenamiento, manoseo y visualización de información vinculada a las coordenadas geográficas donde fue extracionada.Tales sistemas son un requisito esencial para actividades de gestión y planeamiento, para la tomada de decisión y para la democratización de información. Su utilidad es ampliada y su adopción tornada más atrayente por la posibilidad de, con bajos inversiones financieras, acoplar esa herramienta a la internet como medio de acceso remoto a la información.

��


Figura 10.13: Geolibre - Aplicación para el Programa GESAC del Ministerio de las Comunicaciones (2003)

Figura 10.14: Geolibre - Aplicación para el Estado Rio Grande do Sul (2000)

Opcionalmente, existen aplicativos disponibles para que sea ejecutada localmente en las estaciones de trabajo, como GRASS75, el GMT76, el OpenDX77 y el QGIS78.

10.3.13 Otros servicios Servicio de Tiempo: Es esencial, en un ambiente altamente ínter ligado por red, que todas

las máquinas, tanto servidores como estaciones de trabajo, tengan la misma noción del tiempo corriente. Uno o más servidores son designados como servidores masters y ellos obtienen su tiempo de un reloj anexo o de servidores de tiempo externos en la Internet. Todas las otras máquinas son esclavas, sincronizadas a esos mestres.

La sincronización del tiempo puede ser hecha ejecutando el ntp79 en las máquinas. Él puede mantener, fácilmente, una red de maquinas en intervalo de un segundo de una para otra.

��


Figura 10.15: Geolibre - Aplicación para la Municipalidad de Campinas y el Ministerio

de Salud (2002).

El Chrony80 es una alternativa al ntp. Posee algunos recursos que lo hacen más apropiado para cruzamientos NTP altamente estratificados del que el ntp, mientras el ntp es mejor para cruzamientos de estratificación baja, que pueden tener que hacer interface directamente con cosas tales como receptores GPS e relójes atómicos. Hay también productos de software libre para ambiente propietario, que son útiles en un ambiente mixto, como Automachron y nettime. El sitio http://go.to/chrony fornece detalles de ambos.

Servicios de Infra-estructura de Red: Estos son los servicios necesarios para operar una red basada en un TCP/IP.

Roteamiento : Roteadores posibilitan la división de una grande red y redes menores interconectadas. Los roteadores tienen la función de direccionar los paquetes de una sub-red para otra, para habilitarlas a llegar a un destino. La construcción de roteadores requiere un buen entendimiento de los protocolos básicos y muchas Administraciones probablemente desearían comprar roteadores propietarios.

Para los que desean construir su propio roteador, existen dos productos:

Bird81 e GNU Zebra82

80 http://go.to/chrony.

81 http://bird.network.cz.

82 http://www.zebra.org.

DNS : Ua red TCP/IP necesita de algunos medios para traducir direcciones IP para nombres significativos del dominio humano y viceversa. El DNS es un protocolo junto con algunos servidores de intercomunicación, cada un con datos. El DNS es básico para el funcionamiento de la Internet. Hay algunos programas para construcción de

��


servidores DNS, incluso el BIND83, el MyDNS84, y el MaraDNS85. O BIND es, largamente, el más utilizado.

DHCP: El DHCP (Dynamic Host Configuration Protocol) permite que máquinas clientes dentro de una determinada red efectúe automáticamente sus configuraciones, obteniendo de un servidor central informaciones sobre: direcciones y máscaras de red, direcciones de roteadores, servidores de nombres y proxy. La gran mayoría de las distribuciones GNU/Linux ya contienen los servidores y clientes DHCP.

Integración del DHCP con el DNS: Los servicios de DHCP y DNS pueden ser configurados para que trabajen en conjunto. En ese esquema, el servidor DHCP podrá realizar actualizaciones dinámicas en un Sistema de Nombre de Dominios (DDNS). La integración del DHCP con el DNS amplía la funcionalidad del servicio DHCP que, además de la distribución automática de Ips y de la configuración de los parámetros de redes, hará el gerenciamento de los nombres de dominios para los IPs dados por el propio DHCP.

La idea básica es habilitar el servidor DHCP para efectuar solicitaciones de inclusión o remoción de los FQDN (Full Qualified Domain Names) de clientes DHCP en la base de datos de un servidor DNS. Para evitar actualizaciones del DNS no autorizadas, el Administrador podrá utilizar una llave simétrica HMAC-MD5 compartida por los servicios DHCP y DNS. Esta llave podrá ser generada por el utilitario dnssec-keygen del propio BIND. Actualmente el servidor DHCP v3 de la ISC fornecer soporte a la DDNS y puede ser utilizado juntamente con el servidor de DNS BIND v8 o 9, que soporta la RFC 2136 Dynamic Updates in the Domain Name System (DNS UPDATE).

Servidores de Archivos: Servidores de archivos de red permiten a las máquinas anexas a la red entrar al almacenamiento de archivos en una máquina remota, como si la misma sea local.

NFS: Ese es el padrón de hecho y está en uso hace muchos años. El subconjunto implementado comúnmente no ofrece gran seguridad, aunque sea definida una variante de seguridad e implementada en algunas variantes comerciales Unix. El NFS consiste de un servicio que comparte archivos de un servidor para clientes conectados a la red. Hay una autenticación mínima de los usuarios anexos en la versión Linux. El NFS es parte padrón de muchas distribuciones

Samba: El Samba es un producto que implementa el protocolo SMB. Vea 14.5.1 para una descripción más detallada. Es importante para la integración del software libre y de los sistemas con base en ambiente propietario y vienen con la mayor parte de las distribuciones padrón. Su uso está descrito con detalle en Capítulo 12.

Netatalk: Para los que poseen máquinas Apple ® Macintosh ® , el netatalk ofrece la implementación del protocolo Apple ® Talk86

OpenAFS, CODA e Intermezzo: Esos productos implementan un sistema de archivo distribuído en varios grados. Con tal sistema, el acceso a los archivos puede continuar cuando la red falla, porque el caching local posibilita la apariencia de estar conectado. Ese no es un problema trivial y los productos ofrecen soluciones de diversas formas. Ese tipo de sistema de archivo es realmente necesario en laptops o máquinas anexas a una conexión transitória. La

��


otra forma de proveer la misma funcionalidad, es poseendo almacenamiento local sincronizado con un servidor central, periódicamente. Vea http://www.openafs.org, http://www.coda.cs.cmu.edu e http://www.intermezzo.org para detalles de cada producto.

El sitio http://www.inter-mezzo.org/docs/bottlenecks.pdf contiene una discusión detallada de las características de todos arriba.

Servicios de Directorio

Provisión de consulta rápida de nombres, direcciones y datos asociados. El padrón más popular de servicios de directorio es el LDAP. Ese es un protocolo abierto implementado en muchos productos, por ejemplo, Evolution y OpenOffice.org. O LDAP trabaja con definiciones de datos llamados esquemas y es posible a las Administraciones desarrollar sus propios esquemas customizados. Infelizmente los esquemas usados por los aplicativos no son siempre compatibles unos con los otros, lo que significa, por ejemplo, que es difícil para el OpenOffice.org leer los datos del Evolution y viceversa.

El servicio de directorio OpenLDAP se adapta al padrón LDAPv3 y a la versión 2.1 y más tarde podrá ser configurado con una gama de bancos datos (tales como at file, SQLs).

La mayor parte de los conjuntos de groupware suministra alguna forma de servicio de directorio,además pocos están actualmente compatibles de hecho con el LDAP. El Open LDAP todavía posee algunas peculiaridades, principalmente con relación a su uso en grandes redes que poseen millares de objetos en sus Directorios; y esas existen debido al hecho de este Directorio todavía no poseer algunas facilidades y funciones administrativas que actualmente se encuentran disponibles en Directorios propietarios. Además, ya están en andamiento proyectos objetivando la implementación de esas funcionalidades, de forma que su administración sea más amigable y facilitada para esos ambientes.

El OpenOffice.org, el Evolution y el Mozilla ofrecen funciones integrales de catálogos e direcciones Por lo tanto, los formatos de almacenamiento usados no son pasibles de cambios. Es necesaria alguna adaptación para posibilitar el trabajo interactivo.

Servicio de Fax

El Servicio de Fax es muy utilizado en diversas Administraciones para centralizar y facilitar el envío de fax por sus usuarios. Algunas herramientas en software libre pueden ser alternativas para sustitución de sus equivalente propietario.

Una de estas opciones es el Hylafax ® Server87 , que se integra a un cliente para plataforma pro-pietaria, llamado Hylafax Manager88, de modo a permitir el uso común del servidor por ambas plataformas – para GNU/Linux existen diversos clientes disponibles. Este sistema permite inclu-so juntar hojas de diferentes aplicativos.

Alternativa que va más allá del servicio apenas de Fax es el VOCP, un sistema que transforma um computador en una sistema completo para correo de voz, mensajes y fax. Cajas postales ilimitadas pueden ser creadas para correo de voz, pager y roteros (scripts), que permiten la navegación en un sistema de menús a través de las teclas de teléfono. Documentos de Fax pueden ser recibidos y enviados, se puede oír e-mails usando sintetización de voz, filtrar y redireccionar llamadas basadas en la identificación de llamada (se debe verificar como usar este recurso en el sistema de telefonía de Brasil). Para usar el VOCP es necesario una computadora con una placa del tipo “voice modem” y una máquina GNU/Linux, con módulos Perl y vgetty instalados. El VOCP incluye parte a la central del sistema de mensaje, el Call Center (para uso

��


stand-alone, y monitorar la llegada de nuevos mensajes), el VOCPhax para visualización de los faxes recibidos, y el VOCPweb, para acceso a las cajas postales por la web, entre otros paquetes.

Soporte a legados

Emulación terminal: El uso del xterm con un juego variable de ambiente TERM apropiado, puede emular la mayor parte de los tipos terminales basados en caracteres, por ejemplo VT220 y VT100. Hay un emulador 3270 específico llamado x3270. Se puede encontrar emulaciones basadas en páginas en productos propietarios.

Exhibición remota: Hay una discusión a respecto en la Sección 11.3.

Emulación: Hay una discusión a respecto en la Sección 11.4

��


CAPÍTULO 11

11. VISIÓN GENERAL DE LA MIGRACIÓN DE

APLICATIVO

Una vez redigida la lista de aplicativos, ella puede ser agrupada en las categorías a seguir:

11.1 Aplicativos propietarios que poseen un software libre equivalente

Algunos aplicativos, por ejemplo, el Microsoft Office ® , el Lotus ® SmartSuite ® , el WordPerfect ® ,el Framemaker ® , el QuarkXPress ® y el Photoshop ® , tienen equivalentes que operan originalmente en el software libre, incluso el OpenOffice.org, el Gnumeric, el Evolution ® y el GIMP. En ese caso, es necesario testar el producto software libre para garantir que conceda funcionalidad necesaria.

11.2 Aplicativos propietarios que operan en un ambiente software libre.

Algunos aplicativos, como el Acrobat ® Reader ® da Adobe ® , tiene una versión que funciona originalmente en el software libre. Si no haber alternativa en software libre para el aplicativo, todolo que es necesario es garantir que todos los recursos necesarios sean implementados en la versión propietaria. Si haber una alternativa software libre y sea aceptable una migración parcial, hay que hacer una opción basada en los recursos ofrecidos por el propietario y por los aplicativos software libre.

11.3 Software que puede ser accesado por exhibición remota.

Otro abordaje es hacer operar los aplicativos en un servidor y transportar la pantalla para la estación de trabajo; eso es el abordaje cliente leve. Productos como Windows Terminal Server, Citrix, Graphon y Tarantella permiten que los aplicativos funcionen en un servidor operando con software propietario en una plataforma multiusuario. Eso significa que un aplicativo hecho para operar en una estación de trabajo en el modo cliente individual, podrá tener que ser alterado para funcionar en esos productos. Eso no será posible sin el código fuente, y vendedores externos pueden no desear ayudar.

��


El más sofisticado de esos productos, el Citrix, tiene su propia línea de protocolo, ICA, que presenta buen desempeño en conexiones de banda estrecha. Él puede operar múltiplos servidores con carga balanceada y posee otros recursos. Existen clientes gratuitos del ICA que operan en GNU/Linux.

Todos esos productos cuentan con software propietario de fuente cerrada y el Citrix es parti-cularmente caro. Requiere una licencia de servidor Windows, una licencia de Citrix y una licencia de Servidor de Terminal Windows, caso sea usado un cliente no Windows. Adicionalmente, serán necesarias Licencias de Acceso al Cliente para cada estación de trabajo que use el software. La licencia del Citrix es basada en usuarios concurrentes, por lo tanto ese abordaje puede reducir costos si haber muchos usuarios que necesiten acceso a un aplicativo desde que el acceso del concurrente sea bajo.

Hay estudios de casos documentados en http://www.citrix.com/press/news/profiles, que muestran que la economía realizada utilizando estaciones de trabajo en cliente leve es suficiente para justificar la mudanza de los aplicativos para un servidor. El Citrix también posee productos que permiten el transporte de los aplicativos Unix de la misma forma usando el ICA y exhibidos en una pantalla de cliente leve.

El Windows Terminal Server ofrece funcionalidad similar al Citrix, excepto por usar su propio protocolo, RDP. El cliente GNU/Linux para RDP es bueno, pero todavía es considerado por algunos como código beta. El RDP acostumbra ser muy ineficiente en comparación al ICA, pero ahora la diferencia es pequeña, sino insignificante.

El Citrix tiene varios recursos como equilibrio de carga, lo que hace de él la mejor opción para instalaciones de larga escala, donde el costo extra puede ser justificado. Tanto el Citrix cuanto el Windows Terminal Server pueden introducir latencia en el aplicativo, si el tamaño de los servidores no esté dimensionado correctamente y la red no sea suficientemente rápida.

El Tarantella1 funciona en Linux y UNix(Solaris) sirviendo de portal seguro(Apache y Tomcat) para aplicaciones Windows, Linux, Unix, Mainframe y AS/400. Él usa su propia línea de protocolo propietario, AIP, capaz de disponibilizar aplicaciones Windows, Linux y UNIX nativamente, sin emuladores.

Conforme mencionado anteriormente, el CodeWeavers produce ahora una versión servidor de su producto CrossOver Office. Él trabaja con el cliente conectado con seguridad al servidor central y tiene una sección X exhibida de vuelta a él. Esto significa que la comunicación con el servidor central es codificada y comprimida, pero también requiere anchura de banda suficiente para suportarlo, ya que es basado en X. No fueron hechos testes en el requisito anchura de banda, pero es probable que sea mayor de lo que para el ICA (Citrix) el AIP (Tarantella).

El VNC es un producto software libre desarrollado por la AT&T, dibujado para exhibir uma sesión, funcionando en otra máquina. Consiste de un servidor y un cliente, los cuales son dis-ponibilizados para ambiente propietario, Unix y GNU/Linux. El VNC permite que los aplicativos funcionen en un ambiente y la exhibición sea hecha en otro. Usa su propio protocolo abierto, RFB, sobre el TCP/IP, lo que no es tan eficiente cuanto el ICA (Citrix) el AIP (Tarantella), y por lo tanto, necesita de una alta banda larga de red (como 100 Mb/s) para trabajar bien. Infelizmente el servidor VNC para ambiente propietario también no es tan eficiente cuanto a la

��


versión Unix y puede necesitar de más poder de procesamiento de lo que se podría esperar. El VNC puede ser muy útil para uso ocasional de administrador de sistemas, permitiendo que una persona central controle una estación de trabajo. En esas circunstancias, podría ser aceptada una alta latencia.

11.4 Software que funcionará bajo un emulador

Si ningún caso anterior ofrecer un medio de hacer operar el aplicativo o un sustituto, entonces puede ser posible hacerlo operar en la forma original, pero con su ambiente operacional normal emulado arriba de un sistema operacional software libre. Una buena discusión de los asuntos relativos a este abordaje puede ser encontrada en:

http://www.linuxmednews.com.

Todas esas técnicas tienen implicaciones de licencia porque pueden envolver la operación de múltiplas copias del aplicativo propietario y/o del sistema operacional.

Es probable que la mayor parte de esta sección sea aplicable Windows, pero como las técnicas pueden aplicarse a otros Escenarios, son discutidas aquí, al revés del Capítulo 12.

Hay dos tipos de emulación:

11.4.1 Emulación de hardware

Productos como Vmware y Win4lin hacen emulación de hardware. Ellos posibilitan que un sistema operacional de PC normal funcione como un aplicativo nivel usuario imitando el hardware Intel PC en interfaces de software y proveendo, por lo tanto, una máquina virtual. Eso permite que un sistema operacional legado y sus aplicativos operen arriba de una plataforma software libre.

El VMware no es rigurosamente un emulador. Él permite que la mayor parte de las instrucciones pasen a través del procesador, lo que significa que sólo funcionará en una máquina de arquitectura x86. Es la opción más completa además es propietario y puede consumir muchos recursos de la máquina.

El Win4lin es similar al Vmware, y también es un producto propietario, pero es más barato. Puede ser una buena solución en casos simple, por ejemplo, para operar aplicativos office solamente. Es un componente del producto Lindows, que está siendo vendido en hardware de bajo costo para usuarios domésticos. (Por el hecho de aparentemente no usar cuentas de usuarios no privilegiados para mantener la seguridad, el Lindows no debe ser recomendado para Administraciones, sin una consideración cuidadosa de las implicaciones de seguridad).

Por el hecho de que el abordaje de emulación de hardware requiere licencias completas para el sistema operacional y el aplicativo propietarios, junto con el costo del emulador, debería ser visto como una forma de operar un número pequeño de aplicativos legados que son difíciles de migrar.

��


Hay productos de servidores Vmware y Win4lin que pueden reducir costos de licencia si el software propietario permitir una licencia de usuario concurriente,en lugar de licencia del usuario potencial.

Hay aplicativos software libre que emulan completamente un ambiente Intel, por ejemplo, el Bochs. El Bochs es un emulador de PC x86 (puede emular un 386, 486 o Pentium), software libre, escrito en C++, multiplataforma, producido para ser utilizado en máquinas x86, PPC o Alpha. Puede tener como sistema operacional convidado, o sea, rodando sobre él, el MS-DOS, Windows 95, Windows NT 4 o GNU/Linux. Él posee una buena documentación y está en pleno desarrollo, como se puede ver en el sitio http://bochs.sourceforge.net/.

11.4.2 Emulación de software La emulación de software permite que programas escritos para un ambiente propietario

trabajen directamente en el sistema operacional software libre. Cualesquiera llamadas al sistema hechas por ellos son mapeadas en la interface del sistema del software libre equivalente. Eso significa que no es más necesaria una copia del sistema operacional propietario.

Wine

El Wine permite que aplicativos escritos para Windows funcionen en GNU/Linux a través de la emulación de software. El principal problema que el Wine necesita resolver es el gran número de llamadas al sistema (inclusp bugs) que necesita soportar. Su código está disponible em http://www.winehq.org o en CodeWeavers em http://www.codeweavers.com/technology/wine/download.php.

El Wine intercepta todas las llamadas a los sistemas Windows ® y DOS junto con las interrupciones BIOS, y intenta mapearlas en el ambiente GNU/Linux y X Window. Son ejecutadas instrucciones del procesador original como si esté en el ambiente Windows ® , por lo tanto, el Wine no es un emulador propiamente dicho, pues no son emuladas a las instrucciones de la arquitectura x86.

Ni todas las interfaces en el ambiente Windows ® pueden ser mapeadas en una interface en los

ambientes GNU/Linux y X Window: hay interfaces Windows ® que, simplesmente, no poseen una equivalente. Esto significa que, en algunos casos, es necesario escribir una cantidad significativa de códigos para dar soporte al mapeamiento. Hay problemas, por ejemplo, con los cursores mas complejos usados por algunos programas Windows ® : el X Window System no consigue trabajar con más de dos colores en un cursor, lo que significa que el Wine necesita definir el uso de los cuales colores usar, ocasionalmente con resultados inútiles.

El Wine es actualmente compuesto por dos productos, el Wine propiamente dicto, que permite operar programas Windows ® pré-compilados, y el Winelib, que puede ser usado para compilar un programa Windows ® escrito en los lenguajes "C"o "C++"para producir un programa GNU/Linux original (que es lo que el Corel usaba para producir la versión GNU/Linux del Wordperfect).

��


El Winelib puede ser usado para operar programas en otros hardwares además del x86, caso el código fuente esté disponible, pero todavía pueden permanecer algunos otros problemas específicos de arquitectura (por ejemplo, cuestiones de alineamiento de bits – edian).

Situaciones en que el Wine es adecuado

Hay soporte disponible para programas Windows ® 3.x/95/98/ME/NT (aunque el soporte Windows ® NT sea menos completo). Algunos programas dirigidos al Windows ® 2000 no van operar, a no se que usen nuevas interfaces especializadas introducidas con el Windows ® 2000. Además, el trabajo en el soporte específico a programas Windows ® XP todavía es incipiente,

El Wine da soporte a la mayoría de las interfaces Windows ® documentadas públicamente, el soporte no es siempre tan completo cuanto se gustaría. Accese la dirección http://www.winehq.com/?page=status para obtener mayores detalles sobre la situación actual del soporte en el Wine.

Programas que operan separadamente o que usan apenas interfaces de comunicación externa, funcionarán normalmente. Cada programa debe ser verificado individualmente porque las interfaces precisas y los parámetros usados pueden interactuar causando problemas. Hay relatos de personas que operaron compiladores y ambientes de desarrollo con mucho éxito.

Situaciones en que el Wine no es adecuado

El trabajo en algunas áreas específicas no está completo. Vea algunos ejemplos de casos específicos:

• La Dynamic Data Exchange (DDE) presenta algunos problemas, pero como muchos programas hacen llamadas DDE sin usarlas de hecho, él deberá funcionar bien.

• El DirectX y otras áreas gráficas especializadas de alta velocidad también presentan problemas.

• Existe, en parte, la implementación de Access Control Lists (como en el Windows ® NT), pero todavía no fueron integradas con ACLs en la base O/S.

• El dispositivo VxD de tecnología de driver, introducido con el Windows ® 98, es una área difícil. Él necesita de acceso a interior del hardware y del kernel de una forma que cualquier sistema multiuso serio no permitiría.

• El dibujo de algunas imágenes gráficas todavía no es satisfactorio, especialmente el retoque de la fuente True Type y exhibición de algunos objetos OLE. Sin embargo, se trabaja activamente con objetivo de mejorar eso y se puede utilizar las bibliotecas nativas del MS Windows ® en esos casos.

• Programas desarrollados por la propia Microsoft también constituyen una área problemática: tratase de productos que tienden a usar interfaces no documentadas. Aunque sea posible descubrir lo que pasa, los desarrolladores deben ser cautelosos, ya que las leyes relativas a la ingeniería reversa son muy severas en algunos países. En los EUA, por ejemplo, es prohibida la ingeniería reversa para cualquier propósito, y la mayor parte de los otros países occidentales permiten sólo para el establecimiento de compatibilidad. Por lo tanto, el trabajo en esa área será siempre un poco lento.

��


• La operación de instaladores de aplicativos ha sido particularmente problemática, pero trabajos recientes resolvieron grande parte de las dificultades y ese trabajo continua. Algunas de esas dificultades son causadas por desarrolladores que no utilizan las técnicas recomendadas. El acceso al registro es un ejemplo de eso. El formato del Wine es diferente del Windows ® , para facilitar la recuperación. Mientras las interfaces documentadas sean usadas para accesar el registro, no hay problema, pero, a veces, los desarrolladores accedan el registro directamente, bajo el riesgo de corromper un registro Windows ® verdadero, y eso resulta en programas que no pueden más trabajar en el Wine.

• El Wine es algunas veces criticado por presentar bajo desempeño, pero eso es frecuentemente debido a su extenso código de debugging. Es posible compilar el Wine sin eso, pero se debe hacerlo con cuidado, ya que significa que los problemas no pueden ser diag-nosticados sin recopilación adicional.

Wine – alternativas comerciales

Como mencionadas anteriormente, versiones prolongadas del Wine están disponibilizadas como productos comerciales para dar soporte a la corriente principal del Wine. Las dos compañías que están haciendo eso son la Transgaming y la CodeWeavers.

La Transgaming trabaja principalmente e el perfeccionamiento de gráficos e interfaces de sonido y su producto visa el mercado de juegos. Ya la CodeWeavers trabaja en aplicativos office de tendencia dominante, y tiene un producto, el CrossOffice, que da soporte, por ejemplo, al Office y al Lotus Notes.

Wine y Visual Basic R

Fue relatado que los compiladores MS Visual Basic ® (excluyendo el .NET), funcionan correctamente en el Wine con la utlización de algunos componentes nativos del MS Windows ® . Los aplicativos escritos en ese lenguaje exige la utilización de la versión nativa de la máquina virtual del Microsoft Visual Basic (vbvmrunxx.dll).

Migración de Aplicativo para el Wine

Esta es una lista de directrices generales para generar el proceso de migración de aplicativos para GNU/Linux en el Wine:

1. Verificar las condiciones de la licencia: Algunas compañías publicaron licencias

que prohíben la ejecución de su aplicativo, excede en el sistema operacional albo. Remueva cualquier programa en tales condiciones de la lista teste y haga una lista de ellos en separado.

2. Obtenga copias de todos los aplicativos para que sean migrados. Licencias de programas obtenidos de la Internet pueden no permitir copias para testes.

3. Configure una máquina con la última versión del Wine. 4. Teste cada uno de los programas de la lista teste. Anote todos los problemas

encontrados, anote también si ellos están en la fase de instalación, inicialización o ejecución. Además, evalue si ellos afectan lo que los usuarios necesitan hacer, a través de testes, con una selección representativa de usuarios finales. Anote también informaciones sobre el desempeño

��


de los programas. El producto de eso serán avisos indicando donde las llamadas del sistema todavía no fueron implementadas o están implementadas de forma incompleta.

5. Para cada programa de la lista de problemas, verifique primero si ya existe una implementación GNU/Linux. Si hay, no debe haber problemas, pero teste hasta donde pueda. Si no hay implementación GNU/Linux, será necesario contactar el proveedor y sugerir la creación de una a través del uso del Winelib. De nuevo, pueden estar faltando DLLs.

6. Cuando proveedores cooperen, tendrán que ser encontrados aplicativos alternativos, o el proyecto deberá ser abandonado.

7. Una vez disponibilizadas las listas de DLLs extras y de llamadas de biblioteca requeridas, será posible obtener un precio por la implementación.

8. Cada programa necesitará ser re-testado con nuevos instantáneos del Wine/Winelib hasta que los problemas desaparezcan. Remiendos a veces causan problemas con programas que anteriormente estaban operando correctamente, y eso necesita ser testado.

9. El Wine es normalmente compilado con rastreamiento debugging, y eso atinge el desempeño de mala forma, especialmente en interacciones de pantallas. Cualesquiera programas que operen correctamente, pero tengan problemas de desempeño, deben ser re-ejecutados en contraposición a una copia del Wine compilado sin las macros de debug. Si el desempeño todavía sea insatisfactorio, será necesario un trabajo de desarrollo.

CrossOver

La CodeWeavers produce dos productos propietarios, el CrossOver Office y el CrosOver Plu-gin, que son basados en el Wine y dibujados para dar soporte a aplicativos Windows específicos. Aunque los productos sean propietarios, periódicamente son enviadas modificaciones de código de vuelta a la versión software libre del Wine.

El CrossOver Office es dibujado para permitir que aplicativos como Office y Lotus Notes funcionen originalmente en GNU/Linux. Hay alguno asuntos que todavía están por resolver, pero el producto está en activo desarrollo. Por lo tanto, este abordaje puede ser apropiado para algunos usuarios dependiendo de sus necesidades. El CrossOver Office está disponible ahora como producto servidor, lo que significa que no precisa ser totalmente instalado en la estación de trabajo y que puede proveer funcionalidad similar al Citrix.

El CrossOver Plugin es dibujado para permitir que plugins de navegador que normalmente sólo trabajen en ambiente propietario, funcionen en Netscape, Mozilla y Galeon en GNU/Linux. Este producto está disponible hace más tiempo que el CrossOver Office y trabaja muy bien.

Cuidados

Usando esas técnicas, se remueve el costo de la licencia del sistema operacional propietario, pero no de la licencia del aplicativo. La licencia del aplicativo necesita ser examinada minuciosamente para tenerse la seguridad de que no prohíbe el funcionamiento del aplicativo sin el ambiente propietario. Esa restricción es usada en algunos aplicativos propietarios como una táctica para trancar, aunque la imposición legal sea cuestionable.

��


11.5 Software que puede ser recompilado en software libre

Para aplicativos escritos en casa o en nombre de la Administración, y para los cuales haya código fuente disponible, el software puede ser transferido para funcionar en una plataforma software libre. En general, el problema de transferir código fuente en cualquier lenguaje no es la compilación, pero el uso por el código de bibliotecas del sistema, incluyendo el ambiente gráfico y el sistema operacional. Eso puede significar mucha intervención manual para migrar el código. Adicionalmente, cualquier suposición sobre el ambiente base, tal como nombramiento del archivo, hará necesaria la mudanza del código fuente o la replicación del ambiente, independientemente del lenguaje usado.

1. Java. Si el software Java fue escrito de acuerdo con la especificación Java, el programa debe funcionar sin cualesquier problemas. Por lo tanto, caso cualquier extensión propietariahaya sido utilizadas, el código tendrá que ser mudado y deberán ser usados módulos padrones.

2. Visual Basic. Un producto propietario llamado DeLux2 puede ser usado para convertir el código Visual Basic para Kylix (vea ítem 4 abajo) y puede trabajar en GNU/Linux originalmente. Las herramientas de desarrollo de la Microsoft ® pueden convertir el código Visual Basic para.NET y producir código CIL. El proyecto software libre Mono permite que ese código funcione en GNU/Linux. El Mono está siendo desarrollado muy rápidamente en el momento y cualquier aplicativo podrá o no funcionar, dependiendo de la forma como va interactuar con las bibliotecas, como el exhibidor de pantalla.

3. C#. Está recibiendo soporte creciente GNU/Linux, y la Ximian ® produjo un compilador como parte del proyecto Mono, acreciendo las ligaciones C# a componentes cruciales de la estación de trabajo GNOME. El proyecto Mono incluye un intérprete que permite que el código CIL producido por herramientas de desarrollo propietarias trabajen en GNU/Linux sin alteraciones. El proyecto Mono y el uso de la estructura de desarrollo .NET es una área muy viva del software libre actualmente y la posición muda rápidamente.

4. Pascal y Delphi. El Pascal, como lenguaje libre, es menos usado actualmente, además es el componente de codificación esencial de la herramienta de desarrollo rápido Borland Delphi. Borland tiene un equivalente nativo GNU/Linux de la Delphi llamado Kylix. El Kylix 2 y el Delphi 6 son hechos para usar sintaxis de código compatible y poseer ambientes de soporte idénticos.

5. C y C++. Programas escritos para padrones ANSI deben ser recopilados y funcionar mientras las bibliotecas del sistema base usadas sean compatibles. Por ejemplo, sistemas escritos especialmente para ambiente propietario, en general, no irán recompilar y funcionar correctamente en GNU/Linux, por cuenta de juegos de llamadas muy diferentes del sistema operacional y de las bibliotecas runtime, como el sistema de janelas. Se puede resolver esa falta de combinación, frecuentemente, con la compilación del código con Winelib, parte del proyecto Wine.

��


PARTE IV - PLANEANDO LA MIGRACIÓN

��


CAPÍTULO 12

12. ESCENARIO 1 – WINDOWS ®

Situación en la cual la Administración tiene un o más dominios interconectados

de Grupos de Trabajo Windows ® , Windows NT ® PDC/BDC o Windows 2000 ® Active Directory ® . Todos los usuarios poseen estaciones de trabajo Windows ® . Todos los aplicativos centrales funcionan en servidores Windows ® .

A lo largo de este capítulo, la palabra Windows ® significará una versión delo Microsoft ® Windows ® . donde la versión precisa sea importante, será expresa. Los ejemplos de códigos son basados en un sistema RedHat Linux; otras distribuciones pueden contener diferencias sutiles.

El contenido de este escenario debe ser leído en conjunción con los comentarios generales hechos en los Capítulos anteriores.

12.1 Como Planear la Migración

Recapitulando lo que fue dicho en el Capítulo 5, el planeamiento para la fase de transición es muy importante, el suceso de un proyecto software libre será juzgado tanto por la forma que fue ejecutada la transición, bien como por la calidad final del servicio. Es probable que cualquier transición práctica de un sistema para otro dure un período de meses o mismo años. Durante ese tiempo, datos necesitan ser movidos, personas entrenadas, software instalado, y el negocio de la Administración necesita continuar sin interrupciones.

Será necesario un planeamiento cuidadoso, y grandes administraciones deben pasar por una fase piloto para testar el plano antes de colocarlo en funcionamiento en larga escala.

12.2 Dominios

Este Escenario puede ser dividido en la siguiente forma:

12.2.1 Modelo de “grupo de trabajo” del Windows ®

��


Un grupo de computadoras Windows ® co-operando de forma dispersa en la red, declarándose

parte del mismo “grupo de trabajo”. No hay aspectos de seguridad para grupos de trabajo – ellos sirven sólo para organizar máquinas en grupo, convenientemente en listas de navegadores.

Usuarios que desean compartir archivos con otros, pueden permitir el compartimiento, de partes o total de la jerarquía de su directorio, para acceso generalizado o con requisición de seña.

No hay coordinación de nombres de usuario y señas en este modelo. En verdad, en algunas versiones del Windows ® , no hay el concepto de propiedad del archivo.

La migración de un esquema de grupo de trabajo para otro envuelve la colecta de archivos importantes a mano, una máquina de cada vez.

12.2.2 Dominio Windows NT ®

En este modelo, uno o más computadoras actúan con controladores de dominio para coordinar nombres de usuario y señas. Una de esas máquinas servidoras es designada Primary Domain Controller o PDC (Controladora de Dominio Primario), y todas las mudanzas son conducidas por esa máquina. También puede haber uno o más Backup Domain Controllers o BDCs (Controladores de Dominio Backup), para proveer redundancia y compartillamiento de carga.

Los dominios Windows NT ® usualmente incluyen uno o más servidores de archivos (que pueden ser las mismas máquinas que están operando funciones PDC o BDC). Los servidores de archivo proveen almacenamiento para perfiles itinerantes (estaciones de trabajo de usuarios, documentos y ambientes) y pueden proveer también espacio para directorio personal, almacenamiento de archivos compartidos y servicios de fila de impresión.

En un dominio bien administrado, los usuarios normalmente reciben instrucciones para mantener todos sus archivos de trabajo en el servidor de archivos, de forma que ninguna información importante sea guardada en PCs individuales. La migración de dados a partir de ambientes bien administrados para nuevos sistemas, es relativamente simple, ya que los administradores del sistema saben donde encontrar todos los archivos importantes.

12.2.3 Domínio del Active Directory ® del Windows 2000 ®

El modelo del domínio Windows NT ® se torna muy difícil de ser administrado efectivamente para grandes números de usuários, por eso el Windows 2000 ® introdujo un modelo de domínio jerárquico. Es llamado de Active Directory ® o AD (Active Directory ® ) y usa ideas del Internet Domain Name System o DNS y del Lightweight Directory Access Protocol o LDAP.

De la misma forma que en el Dominio Windows NT ® , el AD normalmente proveen servidores de archivos para guardar perfiles itinerantes y directorios domésticos, de forma que sea fácil encontrar archivos importantes al planear el proceso de migración.

��


Por el hecho de AD permitir acceso a LDAP, hay más opciones de migración disponible para un local que usa AD. Por ejemplo, debería ser posible usar servidores AD para guardar datos de nombres y señas para software libre y clientes; eso puede ser conveniente donde una pequeña parte de toda la base del usuario sea mudar para software libre, ya que el proceso de gerenciamiento del usuario puede permanecer casi sin alteraciones.

1.2..3 Visión general de posibles rotas de migración

Las dos principales rotas consideradas aquí son:

1. Agregue máquinas software libre a dominios Windows ® existentes y mueva los dados y usuariosgradualmente para el otro lado, y en seguida remueva los servidores propietarios antiguos. Es posible migrar clientes y servidores independientemente. Agregar servidores al dominio Windows ® es uno de los medios más rápidos de beneficiarse del software libre. Por ejemplo, la combinación del Sistema Operacional GNU/Linux con Samba da un servidor archivo/impresión poderoso y de bajo costo, que puede ser usado en el lugar de un sistema Windows ® sin cualesquiera mudanzas en el ambiente cliente existente. Hacer operar clientes software libre en un dominio Windows ® es una forma de coexistencia de bajo riesgo, ya que no son necesarias mudanzas en los servidores. Se puede hacerlo donde un pequeño número de personas usa estaciones de trabajo software libre en un ambiente, al contrario, sólo Windows R

2. Construir una infraestructura basada en software libre paralela y migrar usuarios y susdados en grupos, con mínima interacción entre los antiguos y nuevos sistemas. Eso es más simple de lo que operar un sistema mixto Windows ® /software libre, pero la cooperación entre las personas que usan Windows ® y las que usan sistemas software libre queda más difícil. Ambas rutas están resumidas en diagramas abajo. La primera ruta promueve una integración más estrecha entre los sistemas antiguos y nuevos durante la transición, pero requiere un esfuerzo significativamente mayor de planeamiento e implementación.

Una dificultad en la elección de la ruta será la forma en que la Administración está organizada y como eso influye en la estructura lógica y física de la instalación de la computadora.

Las primeras etapas de la mayoría de las rutas de migración incluyen una fase de coexistencia, donde ambos, Windows ® y sistemas software libre están en uso, frecuentemente accesando los mismos datos. Estos pueden ser modelos particularmente útiles donde está planeada una migración parcial, con algunos grupos mudando para software libre y otros permaneciendo en el sistema antiguo.

Los detalles técnicos de la operacionalización de estas mudanzas están en la Sección 12.6 en frente. Además discutimos primeramente el background técnico y las herramientas necesarias.

12.4 Cuestiones Generales

Hay muchas similitudes entre los sistemas propietarios actuales y los sistemas de Fuente Abierta que pueden ser elegidos para sustituirlos. Particularmente, las interfaces gráficas del

��


usuario vienen tendiendo a convergir para un padrón razonablemente “cara y modo”, que reduce problemas para los usuarios finales que están mudando de un sistema para otro. Todavía será necesario entrenamiento del usuario final, para ayudar a las personas a trabajar con lo que es diferente y sacar el mejor provecho del nuevo sistema.

Atrás de la apariencia similar de los GUIs, hay varias diferencias importantes entre el Windows ® y los sistemas software libre. Ellas son particularmente aparentes en el nivel de la administración del sistema. aquí es donde será necesaria la mayor parte de entrenamiento y planeamiento. Los sistemas software libre, como GNU/Linux, poseen GUIs de gerenciamiento, pero grandes instalaciones son gerenciadas más comumente a través das herramientas da linha de comando, já que lhes fornecem scripting, automacáo de processo, gerenciamento remoto y control avanzado. La habilidad de automatizar tareas es lo que hace del Unix y del sistema software libre herramientas tan productivas. Además de las diferencias en procesos de gestión, también hay algunas importantes diferencias en el servicio prestado. Esto debe ser planeado, bien como se debe trabajar con eso durante la transición.

Figura 12.1: Rota de Migración 1

��


Figura 12.2: Rota de Migración 2

��


12.4.1 Nombres de usuarios y señas

Usuarios de computadoras se identifican usando nombres de usuario y señas. En algunas Administraciones, también pueden usar tarjetas inteligentes u otros dispositivos criptográficos para obtener una prueba mayor de identificación.

Cuestiones de nombres de usuario

Algunas administraciones pueden tener nombres de usuario “estructurados”, que codifican informaciones sobre el usuario. Por ejemplo, el nombre de usuario cf27 puede pertenecer a la 27a persona a ser registrada en el Control Financiero. Otras permiten a las personas elijan su propio nombre de usuario, o simplemente usen su nombre real. Esquemas estructurados de nombres de usuario pueden ser normalmente usados en sistemas software libre en alteraciones. Nombres de usuario en software libre no pueden comenzar con unos caracteres numéricos, lo que puede causar dificultades con nombres de usuario estructurados, donde la estructura inicial puede bien ser numérica.

Hay algunas cuestiones que pueden afectar los sistemas ad-hoc. Nombres de usuario en los sistemas Windows ® en general no son sensibles a la caja de la fuente. Significa que, si alguien recibir el nombre “Maria”, ella puede digitar “maria”, “MARIA” o hasta “mArIa” en la hora del login, sin problemas. También significa que, siempre que el sistema exhibe un nombre de usuario (como el dueño de un archivo), él va usar la forma digitada originalmente por el administrador, cuando el nombre de usuario fue criado – en este caso, “Maria”.

Por otro lado, nombres de usuario en Unix y software libre no son indiferentes a la caja de la fuente. El usuario precisa digitar su nombre de usuario exactamente en el formato en que fue originalmente registrado. Convencionalmente, nombres de usuario son hechos enteramente en caixa baixa y números, sin cualquier otro caracter, y con una largura máxima de ocho caracteres.

Esas restricciones fueron bien amenizadas recientemente, y los sistemas modernos permitirán nombres de usuario más largos, con un conjuntos de caracteres más amplio.

Algunos esquemas de autenticación y autorización implementan ahora nombres de usuario indiferentes a la caja de la fuente: el esquema basado en LDAP propuesto en este documento, é tal que, nombres de usuario como “Maria” y “Control Financiero” son posibles. Se debe tomar cuidado, por lo tanto, porque puede haber otros pacotes en uso, que se basan en presupuestos de las antiguas reglas. No es indicado permitir espacios o otros tipos de caracteres de puntuación en los nombres de usuario; además, puntos (.), rayas (-) y “subrayados” (_) en general no traen problemas.

Sería una buena práctica limitar los nombres de usuario a los caracteres permitidos en los nombres de correo, de forma que nombres de usuario puedan ser usados como nombres de correo también.

��


Cuestiones de Señas

Sistemas software libre modernos permiten señas de casi todos los tamaños, con um gran conjunto de caracteres. Es una buena práctica incentivar el uso de señas largas (10 o más caracteres) con una buena variedad de letras, números, puntuación, caixa baixa e caixa alta. Los utilitarios para establecimiento de señas generalmente se recusan a aceptar señas muy fácil, a no ser que forzados por un administrador, y muchos locales pueden hasta decidir reforzar reglas más rígidas.

Algunas variantes comerciales Unix todavía “truncan” las señas para hasta ocho caracteres, de forma que si es planeado un ambiente mixto, eso debe ser llevado en cuenta.

La migración de señas de sistemas propietarios existentes, para nuevos sistemas software libre ni siempre es posible, ya que las señas son normalmente mantenidas de forma criptografada y mezclada El plan de transición podrá tener que incluir la reemisión de señas para todos los usuarios, o posiblemente una fase de colecta y sincronización de señas.

12.4.2 Servicios de autenticación

Cualquier red, mismo con un número pequeño de computadoras, necesita de un servicio de autenticación y nombramiento de red. En el Windows NT ® eso es conocido como Domain Controller. En sistemas Windows ® posteriores se llama Active Directory ® . El Novell NDS ® también es largamente instalado, y otros sistemas propietarios poseen sus propios sistemas de autenticación y nominación.

La mayor parte de los sistemas Unix y software libre pueden interactuar con casi todos los servicios comunes de autenticación y nombramiento. El GNU/Linux es particularmente fuerte con respecto a eso. El servicio propuesto en este documento es basado en LDAP, pero además es posible usar múltiplos sistemas de autenticación y nombramiento al mismo tiempo, lo que puede ser útil durante la fase de transición.

12.4.3 Archivos

Una parte muy importante de cualquier plan de transición, concierne a la migración de datos del sistema antiguo para el nuevo. Si es planeada una migración “big bang”, entonces será una operación exclusiva, además, si en el momento más probable, sea conjeturado un funcionamiento paralelo, entonces será necesario acceso a un archivo de plataforma cruzada. Se debe tomar mucho cuidado para evitar pierda de dados, y para evitar la confusión que puede resultar de la separación de copias modificables de un archivo en los ambientes “antiguo” y “nuevo”.

��


Contenido y Formato

Este es el asunto más obvio de migración, y es tratado en detalles en la Sección 12.7 abajo. El abordaje normal es usar aplicativos software libre que puedan leer los archivos escritos por el aplicativo propietario que están sustituyendo, aunque en algunos casos sea apropiado planear una conversión masiva como parte del proceso de migración.

Es probable que datos especiales como macros y scripts necesiten de la atención de programadores experientes durante la migración.

Nombres de Archivos

Como los nombres de usuario, los nombres de archivos Windows ® son insensibles a la mudanza de caja de fuente y en alguna extensión preservan la caja es la fuente. Algunos aplicativos tienden a transformar en mayúscula la primera letra de los nombres de los archivos, bien como hacer otras alteraciones de las cuales el usuario puede estar enterado o no. El ambiente Windows ® también carga la herencia del formato de archivo DOS 8.3, que todavía aparece en algunos utilitarios. Nombres de archivos Windows ® comúnmente contiene espacios, y normalmente usan el conjunto de caracteres Unicode. El Windows ® usa \ como separador de directorio.

Aunque sea menos obvio para usuarios GUI, la totalidad de los nombres de los archivos Windows ® debe incluir una letra.directorio, indicando el dispositivo físico que contiene el archivo o ellos deben tener el nombre verdadero del servidor, caso el archivo esté en un “directorio red”. Esas restricciones pueden ser un problema para gerentes de grandes sistemas Windows R, que intentan ofrecer un servicio sin remiendos al enfrentar mudanzas de hardware.

Otros sistemas propietarios tratan nombres de archivos de formas diferentes. El VMS, por ejemplo, hay nombres de archivos insensibles a la mudanza de caja de fuente que usualmente incluyen un punto, y pueden incluir un número de versión después un punto y coma.

Nombres de archivos en Unix y software libre tienen reglas diferentes. Aquí, los archivos son totalmente sensibles a la mudanza de caja de fuente y el sistema no hace cualesquiera alteraciones en los nombres fornecidos por el usuario. Los nombres usan un conjunto de caracteres 8-bit, determinado por el uso corriente de localidad. Los únicos caracteres que el GNU/Linux no permite en nombres de archivos son el separador de directorio (./.) y el caracter nulo. Mientras, en la práctica, no es inteligente incluir caracteres no-imprimibles, por ejemplo, el sistema de archivos Windows ® FAT32 no puede almacenar los 32 primeros códigos ASCII o cualquier uno de los siguientes ", *, :, <, >, ?, \ or |. Son permitidos espacios en los nombres de los archivos, aunque su presencia requiera que los usuarios de línea de comando sea más cuidadosos con aspas.

Sistemas Unix y software libre no usan letras de directorio y no requieren que el nombre real del servidor de archivo haga parte del nombre absoluto del archivo, donde el acceso al archivo de red es usado. Además, el sistema presenta todos los archivos como parte de una jerarquía sin remiendos. Junto con el uso de links simbólicos en el sistema de archivo y data-driven automounters, eso da a los administradores del sistema grande flexibilidad en la separación de nombre absoluto de un archivo de su dirección de almacenamiento físico.

��


Casi todos los nombres de archivos Windows ® pueden ser migrados directamente para los ser-vidores software libre sin alteraciones. Es posible que si encuentre en la práctica la única excepción en los nombres de archivos que contienen el caracter ./., que tendrá que ser modificado durante la transición. Usuarios de herramientas GUI probablemente nunca percibirán que los nombres de los archivos si tornaran sensibles a la mudanza de caja de fuente, ya que solo digitan tales nombres cuando crean el archivo.

Acceso dual

Muchos planes de migración probablemente incluirán un periodo de funcionamiento paralelo donde algunas personas usan sistemas software libre y otras aún usan sistemas propietarios, en paralelo. Donde los archivos fueron accesados por miembros de dos grupos, se puede precisar tomar algunas providencias.

El compartimiento de archivos en sistemas Windows ® usa el protocolo SMB (Server Mes-sage Block), que es una tecnología muy compleja con muchos niveles de compatibilidad trae.

Es usado por servidores de archivos consagrados y también en el modo “peer-to-peer”, donde PCs individuales disponibilizan partes de sus sistemas en la red. Ambientes bien gerenciados de la Administración se basarán más probablemente en servidores consagrados de los que en compartimiento ad-hoc. Archivos de usuarios no compartidos en un ambiente Windows ® pueden ser mantenidos en varias direcciones diferentes:

1. En un disco local del PC, estación de trabajo el laptop del usuario, por ejemplo, el

referido como directório C. 2. En el perfil roving/roaming del usuario. Esto incluye la mayor parte de los

conjuntos de preferencia y también el contenido de la estación de trabajo Windows ® y (normalmente) la pasta “Mis Documentos”. El perfil roving es mantenido localmente en cualquier PC que el usuario esté utilizando, y es sincronizado de vuelta para un deposito de perfiles en la hora del logout. Eso ofrece la facilidad de backup accesible, pero puede tener serias implicaciones de desempeño, con usuarios relatando logouts muy lentos.

3. En un directorio de un servidor de archivo central. Esa es una opción común en grandes redes de sistemas de estaciones de trabajo, por la facilidad de implementación de rutinas de backup.

El principal mecanismo de acceso al archivo de red del Unix y de los sistemas software libre es el Network File System (NFS). Este es un protocolo más simple del que el SMB, y su especificación siempre estuvo disponible.

Las opciones para implementación del acceso dual pertenecen a la dos amplias categorías: adicionar soporte de protocolo dual a servidores, o adicionar soporte de protocolo dual a clientes. Además de todo que es igual, es normalmente más fácil cambiar servidores que clientes, casi siempre mas fácil ajustar sistemas software libre de que sistemas propietarios. Las opciones están resumidas en la Tabla 12.1.

��


12.5 Herramientas

Esta sección discute algunos de los componientes-llave del software libre, los cuales serán usados en la migración de sistemas propietarios.

12.5.1 Samba

Samba es un conjunto de programas integrados desarrollados para autenticación de usuarios y compartimiento de archivos e impresoras en redes mixtas. Es distribuído sob licencia GPL, caracterizándose, Software Libre.

Tabla 12.1: Opciones de implementación del acceso dual.

Servidores Windows ® Servidores de Software Libre y Unix o a Archivos SMB es padrón Servidores so Clientes CGNU/Linux piden accesar cotas SMB. Esto se queda bastante fácil cuando las máquinas cliente solo tienen un usuario por vez, mas si torna más envolvente con máquinas compartilladas. Variantes Unix no tiene normalmente capacidad de cliente SMB. Es posible adicionar servicio NFS a servidores Windows ® , pero eso puede si tornar dispendioso.

El Samba implementa el protocolo SMB1 , equivalente al protocolo NetBEUI2 de la Microsoft R, capaz de interligar plataformas GNU/Linux, Unix y variantes, Windows R, Macintosh ® , Amiga R, Novell ® y Netware ® . Pode actuar como un Windows NT ® Domain Controller y es capaz de almacenar datos de gerencia de dominio en un directorio accesado a través de LDAP.

Son dadas herramientas en el paquete cliente útiles para diagnosticar problemas con redes SMB, e implementar criptografía.

��


En función de su capacidad de interoperar con diversos sistemas operacionales el Samba Se torna una solución capaz de auxiliar los proyectos de migración. El Samba es mantenido por un grupo central de más o menos 30 voluntarios muy activos por todo el mundo. Más informaciones pueden ser encontradas en http://www.samba.org

12.5.2 OpenLDAP

El OpenLDAP es una implementación del Lightweight Directory Access Protocol (LDAP). Incluye un servidor de directorio, un conjunto de acceso a dados y herramientas de gerenciamiento, y un conjunto de bibliotecas para dar soporte al LDAP en otros aplicativos.

El OpenLDAP es mantenido por un pequeño grupo central más un grande número de contri-buyentes. Una personas del grupo central trabaja en el proyecto todo el tiempo. www.openldap.org

12.5.3 NSS e PAM

NSS:

El NSS es el Name Service Switch: una tecnología usada por el GNU/Linux y por algunas variantes del Unix para permitir que diferentes servicios de investigación de nombres sean usados en la procura de hostnames, nombres de usuario, nombres de grupo etc. Existen diversos módulos disponibles, de los cuales, los más relevantes son:

Archivos : es posible permitir consultas simples de hostnames, usuarios, grupos de usuarios basadas en archivos de texto locales.

DNS: Consultas de hostname basadas en Domain Name System (DNS).

3. LDAP: Consultas basadas en LDAP – en su mayor parte nombres de usuario y grupos de usuarios, pero también útil para muchos otros propósitos.

4. SMB: Consultas usando protoloco Windows ® SMB (veja 12.5.5 – Winbind)

5. NIS: Consultas de usuarios y grupos de usuarios en bases de dados Network Information System (NIS), mucho utilizadas en ambientes Unix. El archivo de configuración del NSS normalmente es hecha a través del archivo “/etc/nsswitch.conf ”.

PAM

PAM (Pluggable Authentication Module) es un sistema libre de autenticación modular utilizado Por el GNU/Linux y por diversos otros sistemas Unix-Like. Por ser un sistema modular de autenticación él permite grande flexibilidad en la configuración del proceso de autenticación y autorización de los usuarios. Algunos módulos interesantes:

��


1. LDAP: Usa operaciones LDAP para verificar las credenciales del usuario. (O Active Directory ® es un protocolo basado en el LDAP, luego es posible autenticar usuarios en dominios Active Directory ® ).

2. SMB: Permite verificar las credenciales de un usuario en un dominio WinNT. 3. Access: Acceso restricto a los servicios de la red.

4. Cracklib: torna obligatoria a verificación de calidad de las señas de los usuarios. (inhibe señas “débiles” del tipo lala123, 123456 etc..)

5. Smartcard: permite hacer la autenticación de un usuario con un smartcard.

Un howto inicial puede ser encontrado en:// http://www.faqs.org/docs/Linux-HOWTO/User- Authentication- HOWTO.html Documentación online puede ser encontrada en:

http://www.kernel.org/pub/linux/libs/pam/Linux-PAM- html Algunos módulos pueden ser encontrados en:

http://www.kernel.org/pub/linux/libs/pam/modules.html

12.5.4 Acceso a archivo GNU/Linux SMBFS

El Samba permite que un sistema software libre suministre servicio de archivo a clientes Windows ® .

El SMBFS trabaja al revés: permite que un sistema software libre accese archivos mantenidos en servidores Windows ® . El SMBFS se disponibiliza con las mas recientes distribuciones GNU/Linux, pero no es encontrado normalmente en sistemas Unix comerciales.

El modelo acceso-controle usado por los sistemas de archivos Windows ® es diferente del que es usado por GNU/Linux y otros sistemas software libre, por lo tanto, hay algunas limitaciones con relación a lo que se puede conseguir con el SMBFS.

12.5.5 Winbind

Otro producto del time Samba, el Winbind permite que maquinas GNU/Linux individuales sean anexadas al domínio Windows NT ® . Mantiene un mapeamiento entre autenticadores Windows NT ® (SIDs) y UIDs y GIDs Unix-style. El Windbind puede hacer muchas otras cosas que reducen la carga en los administradores de sistemas, como montar ambientes Unix-style para las personas que estén conectándose (login) por la primera vez.

La desventaja del Windbind en grandes redes es que cada cliente de computadora construye se propio mapeamiento entre los autenticadores Windows ® y los Unix. Eso puede causar problemas en etapas posteriores de migración, cuando los servidores de archivos software libre fueron introducidos.

��


Al usar el Winbind, nombres de usuario y nombres de grupo usados por GNU/Linux son formados concatenando el nombre del dominio Windows NT ® con el nombre de usuario Windows NT ® , para formar una única serie. Eso puede llevar a una cierta confusión, ya que muchos utilitarios Unix-style solo fornecen espacio en su producción para nombres de usuario de ocho caracteres. El mayor nombre generado por el Winbind aparece truncado en la pantalla.

12.6 Migrando el ambiente del sistema operacional

12.6.1 Acrecentar servidores GNU/Linux individuales a um dominio Windows NT ® existente la configuración es extremamente simple:

1. Instale un servidor GNU/Linux, dándole una dirección IP fijo. 2. Asegúrese de que los paquetes Samba estén instalados. Serán necesarios el samba

original, el common-samba y el client-samba. Ellos están normalmente incluidos en una instalación “servidor”.

3. Edite /etc/samba/smb.conf, configure el parámetro “security=domain”, definiendo el nombre del dominio (grupo de trabalho). Liste el PDC y cualquier BDCs como servidores de seña. Defina las partes a sean servidas por la máquina.

4. Críe cualesquiera directorios que deban ser compartidos, y configure las propiedades y permisiones asociadas.

5. Junte la máquina al dominio Windows NT ® existente, usando la seña del administrador del dominio (o cualquier otro nombre de usuario y seña que tenga el privilegio de hacer eso): smbpasswd -j NOMEDODOMINIO -r NOMEDOPDC -U ContaDoAdministrador

6. Empiece el samba y configure para que él reinicie cuando la computadora sea prendida. /etc/init.d/smb start 7. chkconfig smb on

El servidor ahora aparecerá en la lista de máquinas del dominio y podrá ser usado como un servidor Windows NT ® .

12.6.2 Ejecutar estaciones de trabajo GNU/Linux en dominios Windows NT R

Configuración simple para pequeño número de máquinas

En las primeras etapas del teste de las herramientas software libre, es muy útil operar máquinas individuales GNU/Linux con configuraciones bien simples. Ellas pueden accesar archivos en servidores Windows ® para compatibilidad y testes de migración usando el comando smbmount.

Montar es el termo Unix/software libre para tornar un disco o sistema de archivo remoto parte de la jerarquía de archivo de la máquina local. El proceso es normalmente hecho de forma automática En la hora del boot, bajo el control del archivo /etc/fstab, pero también puede ser hecho de forma interactiva. Por ejemplo, el comando para traer un CD-ROM ISO-standard para dentro del sistema de archivo, bajo el control del sistema de archivo /mnt/cdrom podría ser:

mount /dev/cdrom /mnt/cdrom

��


El comando mount tiene su uso normalmente restricto al usuario root por razones de seguridad. Éste no es un problema donde la máquina esté siendo usada por un administrador del sistema, pero puede ser problemático cuando está envuelto un usuario no-técnico. El GNU/Linux ofrece algunas salidas para este problema:

1. Use una entrada especial en /etc/fstab que permita a usuarios comunes montar ciertos objetos pré-definidos. Esa es la manera usual para posibilitar que cdrom y disquetes sean montados cuando solicitados. Los archivos montados normalmente aparecen como propiedad de quien montó el dispositivo.

2. Use un programa setuid-root para la operación privilegiada, verificando antes si es segura. Es la forma más fácil de trabajar con el montaje de partes remotas de Windows ® .

3. Existen Gerenciadores de Archivos gráficos como por ejemplo, nautilus y konqueror que permiten el acceso a los dispositivos de forma transparente para el usuario.

4. Use un automounter para montar sistemas de archivos cuando fueron accesados por la primera vez y para desmontarlos cuando no estén más en uso. El automounter opera como un daemon y es normalmente dirigido por datos de configuración de red. Eso demanda un esfuerzo mayor de configuración de que los otros métodos, pero es extremamente útil en grandes redes. En este esquema, usaremos los comandos smbmount y smbumount para hacer una parte de umnWindows ® existente parecer parte del sistema de archivo GNU/Linux. En los sistemas Red Hat Linux ellos son parte del paquete samba-client, por lo tanto, asegúrese de que fue instalado ambos los paquetes, samba-common y samba-client. Esos programas son dibujados de tal forma que las partes críticas pueden recibir algunos privilegios de root, aunque no sean instalados de esa forma por default, entonces algunos pocos comandos deben ser operados por root antes que sean usados por la primera vez: chmod u+s /usr/bin/smbmnt /usr/bin/smbumount

Note que el comando cambia smbmnt al envés de smbmount. Eso es importante porque smbmnt encapsula sólo las funciones de smbmount que requieren privilegios de root. Este hecho, cualquier usuario pode usar el smbmount y el smbumount y ellos funcionarán con los privilegios de root.

Ahora cualquier usuario puede disponibilizar el Windows ® SMB como parte del sistema de archivo GNU/Linux, montándolo en un directorio que ya posee. Cualquiera de los archivos que ya estén en el directorio serán invisibles mientras el SMB esté montado arriba.

Como ejemplo, suponga que el usuario del GNU/Linux Fred desea accesar archivos en unservidor Windows NT ® llamado NT4 SERVER en domínio THESTATE, que son partillados sob el nombre FREDERICK y propiedad del usuario de Windows ® FREDERICK. fred comienza haciendo un nuevo directorio para montar a parte Windows ® en:

mkdir ~/ntfiles – A notación “~” significa “en mí directorio personal”.

Eso solo necesita hacer una vez. Ahora, para montar la parte remota:

smbmount //nt4server/frederick ~/ntfiles \ -o username=frederick,workgroup=thestate

El comando debe ser digitado en una línea, o partido con caracteres de continuación de línea “\” como mostrado aquí. Él estará pronto para la seña de FREDERICK en el servidor, y entonces monte la parte del Windows ® en el alto del directorio ntfiles en el directorio personal

��


de fred. Para evitar todo eso de nuevo a cada login, puede ser colocado en un archivo script o mismo hacer parte del proceso de login de fred.

Ahora la parte montada se comporta como si fuera parte del disco local. Si puede criar, apagar y editar archivos. Pero, hay algunos riesgos. Particularmente, no hay tentativas de organizar el control de acceso al estilo Unix y los comandos Windows NT ® ACL para cambiar la propiedad, o modos de archivos y directorios en la parte montada no producirán efecto.

Antes de salir, es interesante desmontar la partición:

smbumount ~/ntfiles

Nuevamente, esto puede volverse parte automática del proceso de logout, caso deseado.

El proceso descrito en esta sección no crea cualquier ligación permanente entre cuentas en el GNU/Linux y cuentas en los servidores Windows NT ® existentes, por lo tanto usuarios y señas deben ser mantenidos separadamente en cada máquina. El esfuerzo de gerenciamiento envuelto puede rápidamente tornarse excesivo a medida en que el número de máquinas aumente, por lo tanto ese esquema solo es realmente apropiado para pequeños ambientes.

Configuración más eficiente para ambientes más complejos

Donde fuera necesaria una distribución piloto más amplia de los sistemas de estación de trabajo software libre, puede ser conveniente mantener aún servicios de archivos y autenticación nos servidores Windows NT ® existentes. El daemon del Winbind del Samba fornece un modo fácil de ligar los dos ambientes. Tanto el Samba como el Windbind son partes padrón de la distribución Red Hat Linux, pero pueden no estar instalados por default en configuraciones de estaciones de trabajo. Para usar el Winbind, deben ser instalados los siguientes pacotes: samba, samba-common y samba-client.

El archivo /etc/samba/smb.conf debe ser editado para mostrar el nombre correcto del dominio Windows NT ® en la línea del workgroup, y para colocar el sistema en el modo de seguridad domain. Los dados de seguridad del Winbind también están en la sección global de este archivo, por ejemplo:

# separate domain and username with ’+’, like DOMAIN+username winbind separator = +

# use uids from 10000 to 20000 for domain users winbind uid = 10000-20000

# use gids from 10000 to 20000 for domain groups winbind gid = 10000-20000 # allow enumeration of winbind users and groups winbind enum users = yes winbind enum groups = yes # give winbind users a home directory location template homedir = /home/winnt/%D/%U # and a shell

template shell = /bin/bash

��


Para que el Winbind trabaje, ciertos servicios deben estar funcionando. Para iniciarlos y para garantizar que empiece a cada reboot, los comandos son:

chkconfig smb on chkconfig winbind on /etc/init.d/smb start /etc/init.d/winbind start

Junte la máquina al dominio Windows NT ® existente, usando la seña del administrador del dominio (o cualquier otro usuario y seña que tenga el poder para hacer eso): smbpasswd -j NOMEDODOMINIO -r NOMEDOPDC -U ContaDoAdministrador

Ahora deberá ser posible conseguir listas de usuarios Windows ® y grupo con el comando wbinfo:

wbinfo -u wbinfo -g

Para que los dados del Winbind estén disponibilizados en el sistema, es necesario editar archivos de configuración PAM y NSS. Eso debe ser hecho con mucho cuidado, porque usted puede quedarse bloqueado fuera del sistema si esos archivos son perjudicados.

En /etc/nsswitch.conf acreciente la palabra winbind a la passwd y a las líneas de group.

En /etc/pam.d/system-auth acreciente una línea de fórmula:

auth sufficient /lib/security/pam_winbind.so use_first_pass

Después ala línea auth equivalente que usa pam_unix, y una de forma: password sufficient /lib/security/pam_winbind.so use_first_pass Después la línea password equivalente que usa pam_unix.

Será necesario reiniciar el Name Service Cache Daemon en esta pasantía: /etc/init.d/nscd restart

La traducción de usuarios y grupos Windows ® para formato de archivo de seña Unix-style, puede ser vista ahora con:

getent passwd getent group

Para automatizar la creación de directorios personales de usuario en primero login, adicione esto a la parte sesión de /etc/pam.d/system-auth:

sesión required /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0022

(Garantice que sea inserido como una única línea al envés de dos líneas, como lo que está presentado aquí). Note que esto irá criar un directorio personal Unix separado para el usuario en cada estación de trabajo que usaren. También puede ser útil para inserir un script en el

��


directorio /etc/skel para que cada usuario tenga que montar sus archivos Windows NT ® en un local padrón en la hora del login.

12.6.3 Ejecutar estaciones de trabajo GNU/Linux en dominios Active Directory ®

En principio, maquinas estaciones de trabajo GNU/Linux pueden se juntar al dominio AD (Active Directory ® ) casi que de misma forma que si juntan al dominio Windows NT ® . En la verdad, si el dominio AD esté funcionando en modo compatibilidad -NT, entonces exactamente el mismo proceso puede ser usado.

El dominio AD también ofrece la posibilidad de usar el LDAP para autenticación y consulta de datos. Este es el mismo esquema propuesto para redes mayores de sistemas software libre puro, y vale bien la pena considerar. Al extender el esquema AD para incluir dados Unix, será posible gerenciar los usuarios y servidores de estaciones de trabajo software libre, con herramientas de administración AD. Para el esquema Winbind usado con el Windows NT ® , es preferible almacenar los dados de forma centralizada, ya que él mantiene la organización entre las IDs Windows NT ® y las Ids Unix consistentes entre todas las máquinas.

12.6.4 Sustituir el Windows NT ® PDC/BDC por Samba+LDAP

El Samba puede cumplir el papel de Primary Domain Controller, permitiendo así, que todos los servidores Windows ® sean eliminados, hasta mismo si aún fueron necesarios clientes Windows ® . Observe que no es posible sustituir solamente el PDC o solamente un BDC en un dominio: todos los controladores de dominios deben estar operando el mismo sistema, sea el Windows ® o Samba. Eso es porque, en parte, el protocolo de replica del PDC no fue sometido a una ingeniería reversa.

Instalar un Samba+LDAP Domain Controller es un trabajo muy grande para ser descrito aquí, pero puede ser hecho en un día más o menos, por una persona experiente. La tarea mayores planear la migración de los nombres de usuario ye nombres de grupo de un dominio existente. Una parte del trabajo es cubierta por el Samba-LDAP-HOWTO del IDEALX (vea referencias en la Sección 12.12 abajo). La misma fuente suministra un conjunto de estructuras de herramientas de migración, que pueden ser una buena base para construirse.

En resumen, el proceso es:

1. Instale el(los) servidor(es) software libre con Samba y OpenLDAP. Puede ser

necesario construir el Samba a partir da fuente, por ejemplo, el Red Hat Linux 7.3 no incluya la versión con LDAP disponibilizada.

2. Adicione las definiciones del esquema Samba al servidor LDAP. 3. Instale el servidor LDAP con una base apropiada Distinguished Name (DN) y una

estructura de árbol de directorio (posiblemente usando las herramientas del IDEALX para popular árbol con entradas boilerplate).

��


4. Empiece el Samba y teste la función Domain Controller. 5. Use el pwdump en el PDC para listar todas las entradas de usuarios en el SAM.

Transfiera el resultado como archivo texto para el servidor software libre. 6. Configure la herramienta IDEALX smbldap-migrate-accounts.pl para igualar con el

ambiente en construcción. Eso no es una cosa simple, pues hay varias opciones a considerar. 7. Haga operar el smbldap-migrate-accounts.pl en los datos transferidos del PDC. Eso

creará entradas en el LDAP para todos los usuarios del dominio. También instalará sus señas SMB para igualarse en las señas usadas en el Windows NT ® (pero eso no permitirá logins Unix o GNU/Linux, ya que las señas del Windows NT ® son embarajadas y el esquema de los sistemas software libre es diferente). La herramienta puede crear directorios personales al mismo tiempo, caso deseado.

8. Copie archivos de usuarios y perfiles roving de los servidores Windows ® para los servidores

software libre, o religue los servidores Windows ® existentes a los dominios ahora servidos por Samba Domain Controllers.

Grandes redes probablemente necesitarán múltiplos servidores LDAP con replica de

datos para flexibilidad. Si un Samba Domain Controller está asociado a casa servidor LDAP, puede ser realizado un esquema muy parecido con la instalación del Windows PDC/BDC.

Hay muchas otras cuestiones a ser consideradas, tales como:

1. Elección de las herramientas para gerenciamento del usuario. 2. Como los grupos Windows NT ® e ACL serán organizados en los grupos Unix-

style y ACL. 3. Usar o no un nuevo nombre de dominio para el servicio basado en software libre. 4. Como crear misturas de señas utilizables por los sistemas software libre (o continuar a

usar las misturas Windows NT ® o las LANMAN, hasta en un ambiente puramente software libre).

12.6.5 Sustituir el Active Directory ® Windows 2000 ® por LDAP

El volumen de datos mantenido en un Active Directory ® queda en un deposito accesible LDAP.

A la primera vista, eso debería facilitar la sustitución de los servidores AD por equivalentes software libre. Infelizmente este no es el caso: los sistemas Windows 2000 ® no usan LDAP puro para todos los accesos a datos, y sin una variante no padronizada del Kerberos para autenticación.

Muchas equipes de trabajo software libre están trabajando para reparar ese problema.

��


Además, hasta el momento en que este trabajo fue escrito, la única forma posible de dar soporte a los clientes Windows 2000 ® y Windows XP ® , es hacerlos operar en el dominio Windows NT ® , como descripto anteriormente.

12.6.6 Ejecutar una infraestructura GNU/Linux paralela y migrar usuarios en grupos

Sustituyendo todos los clientes Windows ® por GNU/Linux

Este es el más simple de todos los esquemas de migración posibles. La interacción entre los sistemas Windows ® y software libre es limitada a la transferencia exclusiva de archivos de usuarios. En líneas generales, el proceso es:

1. Construya el núcleo del ambiente software libre. Esto incluye servidores LDAP para mantener la configuración y los datos del nombre de usuario, servidores de instalación master, uno o más servidores de archivo y de impresión, y estaciones de trabajo suficientes para el personal de gerenciamento de sistemas.

2. Construya una instalación para desarrollo y entrenamiento, con estación de trabajo

suficientes para permitir el entrenamiento de grupos de personas de tamaños apropiados. La tarea inicial de esa instalación es validar y sintonizar la configuración antes de la primera presentación del trabajo.

En esa etapa, el proceso de construcción de la estación de trabajo debe terminar de forma que las máquinas estén configuradas con mínimo esfuerzo humano. Es muy importante que todas las máquinas estén configuradas exactamente de la misma forma durante la primera fase de presentación del trabajo, por lo tanto, eso debe ser testado cuidadosamente.

3. Use la instalación de desarrollo y entrenamiento consultando los representantes de

la base de usuarios para generar entusiasmo por el proyecto y para reunir feedback sobre la interface del usuario. Haga mudanzas de acuerdo con las necesidades, de forma a llegar a la imagen difundida. Llegue a un acuerdo sobre los requisitos para el entrenamiento y la agenda.

4. Construya un conjunto de nuevas estaciones de trabajo suficiente para sustituir el

equipo que está siendo usado por el primero grupo a migrar para sistemas software libre. 5. Registre el primero grupo de usuarios en el sistema nuevo. 6. Entrene el primer grupo de usuarios en el sistema nuevo. 7. Caso necesario, reconfigure cualquiera de las configuraciones alteradas durante el

entrenamiento de forma que todos empiecen con un ambiente nuevo. 8. Sustituya el primer grupo de estaciones de trabajo PC por los sistemas software libre

préconstruídos. Al mismo tiempo, copie los archivos de los grupos para los nuevos servidores dearchivos y configure la copia original para “sólo para lectura”.

9. Ofrezca soporte activo al primer grupo mientras ellos se acostumbran a usar el

sistema software libre. 10. Haga la actualización de los PCs removidos del primer grupo de acuerdo con la

necesidad, y instale la imagen de estación de trabajo padrón. 11. Repita el procedimiento a partir del ítem 5 con el próximo grupo de usuarios.

��


12. Cuando todos los usuarios tuvieron migrado para los sistemas software libre, haga

copias de todos los archivos de los viejos servidores y quítelos de circulación.

Manteniendo algunos clientes Windows ®

Donde sea necesario mantener algunos clientes Windows ® (por ejemplo, para dar soporte a algunas de las funciones cuya migración no es económicamente indicada debido al softwares no transferibles), hay dos opciones principales:

1. Retenga un pequeño dominio Windows ® usando uno o más servidores Windows ® . 2. Dé soporte a los clientes Windows ® de servidores basados en software libre

usando el Samba.

El camino elegido dependerá del motivo por el cual los clientes están siendo retenidos, y de su distribución geográfica.

En cualquier caso, es probable que el Samba sea necesario en uno o más de los nuevos servidores, para suministrar compartimiento de archivos entre clientes Windows ® y clientes con base software libre.

12.7 Migrando aplicativos tipo servidor

12.7.1 Servidores de la Web: cambiando del IIS para el Apache

El servidor de la web usual del Windows ® es el IIS (Internet Information Services), que suministra servicios HTTP, FTP, y Gopher en un pacote. El IIS es conocido por presentar problemas com seguridad y estabilidad, lo que hizo muchas organizaciones lo sustituye- por un servidor alternativo.

En verdad, después de la explosión en 2001 de varios defectos particularmente serios, analistas de Gartner publicaron un estudio con fuertes recomendaciones a sus clientes sugiriendo que el IIS no fuese utilizado para funciones criticas, hasta que fueran completamente reescrito por la Microsoft ® .

Hay varios servidores de red para elegir que sustituye el IIS. Muchos son softwares libres o poseen condiciones de licencia muy liberales. Algunos de los servidores usados más ampliamente están comentados en la Sección 10.3.5.

Al migrar sitios del IIS, la opción usual es el Apache, frecuentemente con PHP o módulos Perl para criptografar. El Apache trabaja en GNU/Linux, FreeBSD, casi todas las otras variantes Unix, y también en el Windows ® . Eso ofrece una amplia gama de opciones de migración.

��


Cuestiones de Migración

1. Nombres de Archivos y URLs

Al cambiar un simple sitio del IIS en el Windows ® para el Apache en GNU/Linux o Unix, la principal cuestión a la cual se debe estar atento es que el sistema de archivo del Windows ® ignora “caja alta/caja baja” en nombres de archivos, pero la mayor parte de los sistemas de archivos GNU/Linux o Unix son sensibles a las “caja alta/caja baja”. Como la jerarquía de las páginas de la web es normalmente representada directamente en el sistema de archivo, significa que URLs se vuelven sensibles en el ambiente Unix o GNU/Linux. (Eso no sería una cuestión si el Apache fuese usado en un servidor Windows ® ).

Ninguna cuestión afecta un sitio escrito correctamente y consistente. Infelizmente, sitios escritos con software Windows ® frecuentemente tiene uso inconsistente de caja alta y caja baja, y algunas veces, tiene el carácter “\” en URLs donde la estructura de archivo del sitio contiene un subdirectorio. En verdad, el sitio ejemplo distribuido con las versiones más recientes del IIS presenta ambas cuestiones. Hay soluciones paliativas fáciles para los dos problemas en el Apache, las cuales son demostradas en ejemplo en el decorrer del capítulo. Además, como regla general, es mejor corregir tales problemas en los datos del sitio.

2. Mapas de imagen tipo servidor

Algunos sitios más antiguos usaban un mapeamiento tipo servidor de coordenadas x, y en una imagen destinada a URLs. Eso ahora es condenado porque es ineficiente y no trabaja bien con navegadors no-GUI, pero algunos sitios todavía pueden usarlo. Los mapas tipo servidor en el IIS toman la forma de archivos con extensión “map”,y su formato no es compatible con los archivos Apache equivalentes.

El mejor abordaje es convertir cualquier mapa tipo servidor en mapas tipo cliente, ya que eso da una experiencia de browsing mejor para el usuario. Si eso no es posible, se puede usar un script Perl simple para editar archivos para una forma usable por el Apache.

3. Scripts y conexiones de bancos de datos

Sitios más complejos tienden a tener páginas dinámicas basadas en scripting y acceso a banco de datos. La mayor parte de los sitios IIS usan ASP (Active Server Pages) como estructura de scripting y pueden usar el Access ® o el SQL Sirven para banco de datos, dependiendo del tamaño del aplicativo.

Hay muchas formas de trabajar con la migración de scripts ASP. Algunos de los más populares son:

(a) Paquete Chili!Soft ASP para Unix (ahora llamado Sun ONE Active Server Pages)

(b) ASP2PHP

(c) Apache::ASP

(d) Conversión manual para una nueva lenguaje

��


El Chili!Soft ASP es un producto propietario, pero en algunos casos, puede ofrecer una ruta de migración muy económica.

El ASP2PHP es un conversor de script independiente que convierte archivos de texto escritos en ASP y VBScript en archivos de texto escritos en PHP. Está siendo desarrollado un soporte para archivos ASP usando JScript. El PHP es una estructura de web-scripting muy popular con características similares al ASP, y puede ser, por lo tanto, una forma de transición bien fácil para los desarrolladores. Para proyectos mayores, es siempre bueno hacer una separación mayor entre dibujo de página y lógica del script que los modelos ASP o PHP permiten. En esos casos, una conversión manual usando un sistema basado en modelo puede ser una opción mejor. El Apache::ASP da características ASP directamente a través da estructura Apache, junto con scripting en Perl. El VBScript y el JScript no tienen soporte.

En algunos casos, puede ser mejor considerar una conversión manual de ASP para una nueva estructura. Eso garante mayor flexibilidad y sitios complejos pueden beneficiarse bastante en la mudanza para un sistema basado en modelo como el Template Toolkit 3. Todos los sistemas de scripting Apache poseen facilidades de acceso a bancos de datos para una amplia tira de tipos de bancos de datos (SQL, at file, indexed, LDAP, NIS etc), por lo tanto, pueden ser construidos sitios dinámicos de cualquier complejidad, dirigidos para bancos de datos.

4. Extensiones FrontPage

El paquete de web-design del FrontPage introdujo un conjunto de extensiones que permiten gerenciamiento remoto de contenido de la web. Ha sido usado desde entonces por otros paquetes de web-design.

Las extensiones FrontPage son disponibles para sistemas Unix, pero no universalmente populares con administradores Apache por varias razones, incluyendo cuestiones de seguridad y el grande número de mudanzas introducidas en el área de almacenamiento de la página web padrón. Hay disponible ahora una substitución basada en padrones en formato protocolo WebDAV (RFC2518). Recibe soporte de la mayor parte de los servidores de web (incluso Apache, usando el módulo mod_dav) y es el protocolo de gerenciamento de sitio preferido actualmente. Algunos proveedores de software proprietarios dan soporte al WebDAV. Por lo tanto, un servidor Linux/Unix/Apache puede dar soporte tanto a clientes software libre cuanto a clientes propietarios usando el mismo mecanismo.

Migrando un sitio Internet estático

Este ejemplo muestra un proceso completo para migrar un sitio simple y estático del IIS en el Windows NT ® para el Apache en el GNU/Linux.

1. Prepare el servidor GNU/Linux, conéctelo a la red y teste el Apache. La mayor parte de las

distribuciones GNU/Linux suministran paquetes Apache pré-configurados, por lo tanto, eso es normalmente automático. Un servidor visible en la Internet necesitará, sin duda, de fortalecer su seguridad antes de conectarse.

2. Localice los datos del sitio en el servidor IIS (usualmente en C:\ InetPub) y haga una copia

pronta para transferencia, por ejemplo, usando un paquete de archivo Zip.

��


3. Copie el archivo Zip para la máquina GNU/Linux (usando por ejemplo, FTP) y desempaquételo en el local elegido para los datos del sitio. Esto es configurado como DocumentRoot en archivo httpd.conf Apache, y normalmente está en algún lugar como /var/www/html.

4. Edite httpd.conf y acreciente default.htm a la cláusula DirectoryIndex. (Por convención, el Apache es configurado para procurar por default/homepages llamadas index.html, mientras que el IIS usa default.htm . Esto permite el uso de los dos nombres).

5.En esa etapa, el sitio debe comenzar a funcionar, aunque deba ser accesado por el

nombre del nuevo servidor en vez del propio URL. También pueden aparecer problemas donde los datos del sitio hacen uso inconsistente de cajas alta y baja en los nombres de archivos y URLs, y donde "`haya sido usado en URLs.

6. Si posible, teste el sitio en esta etapa y corrija cualesquiera de los problemas a través de la edición de los datos del sitio. Esto posibilitará mejor desempeño. Hay herramientas de verifacación automática disponibles, los cuales recorrerán el sitio y dirán si algunos puntos de ligación apuntan para locales no disponibles. Usted también puede hacer en esa etapa una lista de las páginas no alcanzables, y pasar todas por un testador HTML.

7. Caso no sea posible reparar los datos del sitio, agregue estas líneas de configuración al

archivo httpd.conf:

LoadModule speling_module modules/mod_speling.so AddModule mod_speling.c

CheckSpelling on

Note que eso produce una limpieza en el directorio y un redireccionamiento del HTTP para cada parte mal deletreada/con errores de cajas alta y baja de un URL, por lo tanto, ponga atención en las cuestiones de desempeño.

8. Páginas que usan “\” incorrectamente en URLs pueden ser manejadas usando mod_rewrite, a través da edición de las líneas abajo al httpd.conf:

RewriteEngine on

RewriteRule (.*)\ \(.*)$ $1/$2 [N] Esto sustituye la primera \ por / no URL y después repite, caso haya más de una \.

9. Verifique los mapas de imagen tipo servidor usando un comando de modo: find /var/www/html -name ’*.map’ -print

Edite a mano, si hay sólo uno o dos, o use un script para arreglarlos, si hay muchos.

10. En esa etapa, todo el sitio debe estar trabajando correctamente. Usted puede configurar FTP, Samba o WebDAV para proveer acceso para la actualización de las páginas.

11. Para que el sitio entre en funcionamiento, desconecte el viejo servidor y cambie la dirección IP de la nueva máquina para sustituirlo, o cambiar la entrada DNS del sitio para que esté apuntada para el nuevo servidor.

Una configuración WebDAV simple

El WebDAV puede ser usado para gerenciar el contenido de algunos o todos los sus sitios. En este ejemplo, él es usado para todo el sitio, por lo tanto no debe ser permitido cualquier

��


otro acceso. (Otros sistemas de gerenciamento como FTP o acceso directo al archivo confundirán a los clientes WebDAV pues ellos no usan el mismo esquema de traba).

1. Haga un directorio para las trabas WebDAV. Debe pertenecer al mismo usuario y

grupo en el cual el Apache funciona (vea opciones de configuración de User e Group en httpd.conf). Una buena elección sería /var/httpd/webdavlocks.

2. Agregue estas líneas a la parte principal de httpd.conf: Loadmodule dav_module libexec/libdav.so

Addmodule mod_dav.c DAVLockDB /var/httpd/webdavlocks

3. Encuentre el Directory o Location asociados al sitio default, y agregue estas líneas: DAV On AllowOverride None Options Indexes AuthType Basic AuthName “sitio Managers Only” AuthUserFile /var/httpd/htpasswd <LimitExcept GET HEAD OPTIONS> require valid-user </LimitExcept>

4. Asegurese de que los archivos y directorios asociados sean propiedad del mismo usuario y grupo donde el Apache funciona, usando un comando del modo: chown -R apache:apache /var/www/html

5. Críe el archivo seña: touch /var/httpd/htpasswd chown root:apache /var/httpd/htpasswd

chmod 640 /var/httpd/htpasswd 6. Críe una seña para un usuario llamado webadmin (o cualquier otro nombre que usted

elija): htpasswd -m /var/httpd/htpasswd webadmin 7. Reinicie el Apache o haga con que relea sus archivos de configuración, por ejemplo:

/etc/init.d/httpd reload

8. Usted puede gerenciar todo el sitio usando el protocolo WebDAV. El Windows 2000 ® y clientes posteriores pueden accesarlo como un “Network Place” en el Windows Explorer, y los aplicativos del Office pueden salvar los datos directamente en el sitio. El GNU/Linux suministra funciones similares vía davfs.

9. Note que el esquema aquí descripto da apenas seguridad limitada. Usted debe leer el

manual del Apache para mayores detalles sobre autenticación del usuario y escoger un esquema apropiado para sus necesidades. Puede ser necesario usar el SSL para proteger las transaciones; esto puede ser hecho con el mod_ssl del Apache.

12.7.2 Bancos de Datos: mudando del Access ® y del Servidor SQL para el MySQL o PostgreSQL

Muchos pequeños proyectos de bancos de datos usan el Access ® . Este es un producto atrayente para muchas personas porque es muy simple para iniciar, y tiene una interface familiar con el usuario. Además, el Access ® tiene severas limitaciones; no fue diseñado para trabajo multiusuario pesado, y no consigue trabajar con grandes conjuntos de datos. Bancos de datos mayores usan SQL Server, Oracle, Sybase, DB2, etc.

��


En el caso de esos sistemas mayores, la solución libre sería el PostgreSQL o el Firebird, migrando también los aplicativos del cliente para plataformas software libre. En algunos casos, particularmente donde la Administración tenga profunda habilidad con el banco de datos existente y esté utilizando muchos recursos propietarios, puede ser hecha inicialmente apenas la migración de los aplicativos del cliente, dejando la migración del banco de datos para una otra etapa. Hay formas padrón de conectarse a bancos de datos relacionados por la red, por lo tanto la elección de la plataforma puede ser diferente para el banco de datos y los aplicativos del cliente.

Además, la mayoría de los bancos de datos propietarios son disponibles en plataformas GNU/Linux y Unix, por lo tanto, es posible mudar el sistema operacional sin tener que aprender un banco de datos completamente nuevo. Por otro lado, bancos de datos propietarios pueden ser itenes muy caros, por lo tanto es importante considerar la migración del banco de datos para Software libre, mismo que en una segunda etapa.

Los tres más conocidos bancos de datos software libre son MySQL, el Firebird y PostgreSQL. Son productos maduros con grandes bases instaladas y equipos de desenvolvimiento activas. Ambos poseen buen soporte para el SQL padrón, y son capaces de desempeño muy bueno. También vale la pena recordar que bancos de datos no tienen que ser relacionales. Algunas tareas se adaptan mejor con otros modelos, y el uso directo de un producto software libre como Sleepycat´s Berkeley DB puede ser extremamente eficiente. De forma similar, el modelo LDAP de bancos de datos en red de forma jerárquica es bastante apropiado para algunos tipos de aplicativos distribuídos.

Migrando Bancos de Datos Access ®

El Access ® sólo se disponibiliza en plataformas propietarias, por lo tanto, caso esté planeado un ambiente completamente libre,sería interesante la migración de la base de datos para MySQL y utilizar PHP en un ambiente intranet, en sustitución de los formularios y relato, además demandaría un tiempo mayor para el desenvolvimiento de la interface del usuario. Otro escenario sería la utilización de algunas herramientas libres que pueden sustituir completamente el Access ® , como Knoda4 ,el Haccess5 , el pgaccess6 y/o el mdbtools7 , estando el Haccess todavía en desenvolvimiento.

1. Exportación/importación a mano

Hay varias formas de migrar datos del Access ® para otros bancos de datos. Para conjuntos

de datos simple, talvez la forma más fácil sea la de exportar las tablas del Access ® como archivos CSV (Comma Separated Values), y después importarlas para el nuevo servidor. Este método requiere que las tablas sean creadas a mano en el nuevo servidor primeramente, pero no necesita de cualquier software especial.

Como ejemplo, aquí están los comandos para criar un banco de datos con una simples tabla y para importar un archivo CSV para el MySQL. Primero entre un Shell prompt:

mysql -user=myusername –p

��


Después entre con el siguiente: create database mydb; use mydb;

create table mytable

(firstname char(30), surname char(30), postcode char(10) );

load fecha local infile ’exportfile.csv’ into table mytable

fields terminated by ’,’ enclosed by ’"’ lines terminated by ’\ r\ n’;

2. Exportación/importación scripted

Existen varios scripts y programas que exportan un banco de datos Access ® completo con toda la información necesaria para recrear las tablas en un otro SGDB. Algunos de ellos producen archivos para seren copiados para la nueva plataforma, mientras otros se conectan directamente a través de la red y hacen las alteraciones immediatamente. Un ejemplo de los scripts escritores de archivos es el exportsql2.txt disponibilizado en: http://www.cynergi.net/exportsql.

Él produce archivos con instrucciones DROP TABLE, CREATE TABLE, y INSERT, que van replicar el banco de datos Access ® en MySQL.

Varias otras herramientas de migración son descriptos en el documento de Paul Dubois “Migrating from Microsoft ® Access ® to MySQL”

Una vez migrados los datos, es posible continuar usando el Access ® como interface del usuario, deletándose las tablas localmente y ligándose a las recien creadas tablas en el servidor MySQL.

4 http://knoda.sourceforge.net 5 http://haccess.sourceforge.net 6 http://www.pgaccess.org 7 http://mdbtools.sourceforge.net 8 http://www.kitebird.com/articles/access-migrate.html

Migrando bancos de datos del Servidor SQL

El proceso aquí es muy parecido con el descrito arriba; para bancos de datos simples es normalmente suficiente exportar los datos para un formato común (usualmente CSV) y después importarlos para el nuevo banco de datos. Bancos de datos más completos, que incluyen procedimientos de almacenaje y triggers, necesitarán de más esfuerzo, y en esos casos, vale la pena buscar entre la gama de herramientas disponibles para auxiliar en el proceso de migración. Algunos de ellos son softwares libres, otros son comerciales. Algunos ejemplos:

1. El PGAdmin es un software libre para administración de bancos de datos PostgreSQL.

Hay utilidades plugin que conducen la migración de datos de otras máquinas de bancos de datos. Más informaciones disponibilizada en http://www.pgadmin.org.

��


2. O SQLPorter de la Realsoftstudio – un producto comercial disponibilizado en muchas

variantes, dependiendo de la fuente y de la máquina de banco de datos albo. Para mayores informaciones, vea http://www.realsoftstudio.com/overview.php.

3. El SQLWays da Ispirer – es un producto comercial que da soporte a una gama de

máquinas de bancos de datos. Vea http://www.ispirer.com/products. 4. El SQLyog es una otra herramienta comercial. Gerencia el MySQL y también conduce la

migración de datos de otros bancos de datos submetidos a la ODBC: para detalles, vea http://www.webyog.com/sqlyog.

5. El sitio del MySQL lista una vasta gama de otras herramientas de migración: vea la lista disponibilizada en: http://www.mysql.com/portal/software/convertors/index.html.

Cuestiones de migración de bancos de datos

Es más probable que los problemas comiencen a aparecer a partir de los utilitarios auxiliares y de los lenguajes scripting que cercan cualquier banco de datos práctico. El SQL es padronizado, además, los fabricantes de bancos de datos crian particularidades no condicientes al padrón, encorajan las personas a que usen sus extensiones no padronizadas. Además, hay varias formas diferentes para alcanzar un dato resultado en SQL, y la elección del más eficiente puede variar de un banco de datos para otro.

Muchos aplicativos de bancos de datos son construídos con generadores de aplicativos o constructores de formatos. Ellos pueden no funcionar con cualquier otro banco de datos que no aquellos con los cuales fueron generados.

Tanto el MySQL como el PostgreSQL se desarrollaron mucho en los ultimos años, por eso es importante que usted lea revisiones recientes al considerar cual producto usará y si iniciará la migración.

12.7.3 Groupware: mudando del Exchange

El Exchange ofrece servicios de correo, calendario y libros de direcciones. Es normalmente utilizado con el cliente Outlook ® en el Windows ® , aunque algunas instalaciones también usen el Outlook ® Web Access ® (OWA) para dar funciones básicas a través de una interface web.

Todas las funciones del Exchange pueden ser sustituídas por paquetes software libre, frecuentemente de forma muy eficiente. Los problemas aparecen cuando se intenta ofrecerlos sin alteraciones para los clientes Outlook ® , ya que el mecanismo de comunicación entre el Exchange ® y el Outlook ® es propietario.

El Outlook ® es capaz de accesar algunos servicios basados en padrones abiertos, aunque en algunos casos la experiencia del usuario sea diferente del que la encontrada al usar el protocolo propietario. Como resultado, vale la pena decidir al início proceder a la migración para un paquete cliente software libre al mismo tiempo en que la migración del servidor está siendo hecha, ya que la población de

��


usuarios verá algunas diferencias, mismo que tengan adherido al Outlook ® . El cliente para sustitución más óbvio es el eVOLUtion de la Ximian.

Cuestiones Generales

Todos los usuarios del Exchange tendrán nombres de usuario y señas almacenados en el sistema. Las versiones recientes del Exchange usan el Active Directory ® para eso, por lo tanto las notas sobre migración de datos de registro del usuario que estén en cualquier lugar del documento, también se aplican al Exchange.

Resumiendo, servidores con base en software libre pueden accesar datos de registro vía LDAP, de forma que los nuevos servidores puedan usar el Active Directory ® existente o los datos pueden ser migrados para un almacém de datos con base en software libre, como el OpenLDAP.

Cuestiones de Correo

Usuarios pueden tener un volumen considerable de correspondencia almacenada, tanto personal cuanto partida con miembros de otros grupos. Debe haber un requisito legal o de procedimiento para mantener un registro de toda la correspondencia enviada y recibida, y en ese caso, el almacenamiento y el acceso a esos datos debe ser considerado. Las personas con computadoras portátiles pueden transferir toda su correspondencia para el laptop, o optar por mantener una copia sincronizada con el documento principal en el depósito central.

Al planear una migración para los servicios de correo basados en el software libre, es importante localizar todos los datos almacenados y asegurarse de que todavía estará accesible después de la transición.

El Exchange puede usar grupos Windows ® como listas de distribución – son los mismos grupos que el própio Windows ® utiliza para controlar el acceso. Esta no es la manera usual de mantener listas de distribución en un ambiente software libre, además puede contar con soporte, caso deseado.

Caso el Outlook ® sea retido como cliente correo, debe ser reconfigurado para usar IMAP en vez del acceso “original” a las cajas de correo.

El Exchange no posee recurso de exportación, por lo tanto la migración de los datos debe ser hecha a través de una conexión de cliente.

Para mayores detalles sobre sistemas de correo software libre, verifique la Sección 10.3.1 y el Apéndice B.

Cuestiones de Catálogo de Direcciones

��


Usuarios del Outlook ® constuyen un catálogo de direcciones personal automáticamente, al enviar y recibir mensajes. También posee acceso a uno o más libros de direcciones compartidos, caso usen el servidor Exchange. El contenido de esos catálogos de direcciones debe ser migrado para un formulario legíble por el software libre. Libros de direcciones personales pueden ser exportados en formulario vCard, el cual es entendido por muchos clientes correo y puede ser subdividido por scripts para conversión en otros formatos, caso necesario.

De forma similar, libros de direcciones compartidos pueden ser exportados y después cargados en un almacén LDAP. Es probable que los principales problemas vengan del hecho de que el Outlook ® y el Exchange tienden a no usar direcciones de correo padrón RFC822 internamente, y por lo tanto los datos de libros de direcciones pueden no incluir direcciones usables cuando exportados. En ese caso, será necesario algun procesamiento de correo, usando un script con acceso al depósito del Active Directory ® para traducir las direcciones del “formato interno” para las direcciones RFC822 padrón. Esta traducción será probablemente necesaria mismo que el Outlook ® esté retenido como cliente correo, ya que no podrá usar las direcciones “formulario interno” al enviar correo en protocolos basados en padrones como el SMTP.

Cuestiones de Calendarios

Algunas Administraciones hacen uso considerable de los recursos del calendario del Outlook ® para agendar reuniones y gerenciar reservas de salas. Esos recursos pueden ser usados sin el Exchange, pero hay algunas limitaciones.

Si hay una migración para clientes software libre planeada concomitantemente, los calen-darios deberán ser exportados en formato vCal y movidos para la nueva plataforma de gerenciamiento de calendario.

12.8 Migrando aplicativos estación de trabajo para software libre

12.8.1 Office ®

Conversión de documento

El OpenOffice.org es capaz de leer y escribir formatos propietarios extraordinariamente bien, Por lo tanto no es necesario convertir documentos durante el proceso de migración. Caso sea deseada la conversión del documento, eso puede ser automatizado con el recurso Autopilot seleccionado en el menu File del OpenOffice.org. Este recurso da una forma de convertir documentos en masa. La decisión de convertir depende del uso futuro del documento. El Capítulo 5 habla sobre formatos de documentos y conversiones en líneas generales. Caso los documentos sean editados repetidamente, el formato deberá ser el utilizado por la mayoría de los editores.

Conversión de modelo

��


El OpenOffice.org puede usar modelos directamente en formato Word ® 97, pero en la práctica, es mejor convertirlos para modelos originales y almacenarlos en una área modelo compartida apropiada. Ese procedimiento ofrece la oportunidad de testar cada modelo y corregir cada error de conversión. El OpenOffice.org hace, por si sólo, la mayor parte del trabajo de conversión, y el proceso puede ser automatizado para grandes colecciones de modelos, usando la función Autopilot Document Conversion, que se encuentra en el menu File. Modelos de otros procesadores de texto probablemente precisarán de recreación a mano.

Conversión de Macro

El OpenOffice.org usa una macro lenguaje del tipo BASIC. Es muy similar, estructuralmente, Los lenguajes usados por el Word ® y por las versiones posteriores del WordPerfect ® . Además, los nombres de los objetos sobre los cuales trabaja son diferentes, por lo tanto todas las macros necesitarán de algun esfuerzo de conversión manual. Las macros son un grave riesgo de seguridad en documentos y no son necesarias para la mayoría de las tareas del día-a-día; así vale mucho la pena verificar si pueden ser dispensadas. La mayoría de las tareas de formatación son más bien manuseadas con el uso de modelos y estilos, y la manipulación de datos simples puede ser hecha usándose formularios.

Las versiones OpenOffice.org a partir de la 1.1 incluyen un grabador de macro, tornando más fácil la creación de macros simples, caso se juzguen esenciales. No hay, actualmente, cualquier medio automático de conversión de macros, aunque algún trabajo sobre eso esté siendo hecho.

Procesamiento de texto

Hay muchos paquetes de procesadores de texto en uso en los sistemas Windows ® . Organizaciones bien gerenciadas tienden a tenerlos padronizados en un paquete, o talvez en transición de uno para otro. Los paquetes más comunes son:

Microsoft ® Word ® y Microsoft ® Works ®

WordPerfect ®

Lotus ® AmiPro ® , Lotus ® WordPro ®

IBM ® Display Write ®

Archivos en formatos propietarios no son legibles directamente por el OpenOffice.org, por lo tanto, necesitarán de conversión. Es frecuentemente posible exportar los archivos del respectivo aplicativo en algún formato comun aceptáble; la conversión puede, además, requerir una tercera herramienta.

Archivos WordPerfect ® todavía no son directamente legíbles, pero hay un proyecto en andamiento para incluir ese formato en el OpenOffice.org. Hay un programa de conversión baseado en script disponible que puede ser usado para conversión formato bulk.

��


El sitio http://www.raycomm.com/techwhirl/magazine/technical/openofficewriter.html Contiene una comparación extremamente útil de las funciones disponibles en el Word ® y en el OpenOffice.org. La interface usuario es suficientemente similar al del Word ® , para que las personas puedan cambiar de uno para el otro con poca dificultad (aunque fuera mejor promover entrenamiento para introducir el nuevo paquete de forma efectiva).

Publishing

La producción de documentos además de la capacidad de los procesadores del texto es normalmente hecha con Paquetes Desktop Publishing (DTP). Los comunes incluyen:

Framemaker ®

Pagemaker ®

QuarkXPress ®

El producto software libre Scribus encontrado en http://www.scribus.net pretende sustituir esos paquetes y debe ser evaluado.

El OpenOffice.org tiene una capacidad mucho mayor que los procesadores de texto comunmente tenían cuando los paquetes DTP fueron producidos por la primera vez. Recursos avanzados como los del Master Documents posibilitan que se trabaje con grandes proyectos como producciones de libros, y recursos de layout son muy flexibles ahora.

Abordajes alternativas incluyen el uso de paquetes de post-processing, donde el texto es marcado en una lenguaje similar al HTML y después convertido para su layout imprimible final a través de la aplicación de hojas de estilo. Esos sistemas no-GUI pueden ser muy útiles para la producción de documentos que mudan rápidamente y para impresión on-demand de material basado en banco de datos.

Planillas

Planillas comunes basadas en ambiente propietário incluyen:

Microsoft ® Excel ®

Lotus ® 123 y derivativos

En la mayoría de los casos, una migración del Excel ® o del Lótus 123 para el OpenOffice.org o Gnumeric presenta pocos problemas, a no ser que la planilla contenga controles u otros mecanismos que requieran macros. En este caso, esos controles y macros deben ser reescritos.

otras herramientas avanzadas familiares a los usuarios del Photoshop . El Gimp es amplia-mente utilizado en la generación y en el aprimoramiento de imágenes para la web y para publicación. El único recurso importante en el cual es fallo es en el proceso completo de

��


gerenciamento del color, y por lo tanto puede no ser apropiado para trabajos de pré-impresión de alta calidad.

Geración de PDF

Generar un archivo PDF en software libre es más fácil del que en el Windows, donde algo como el Adobe ® Acrobat precisa ser comprado. Hay varias herramientas Postscript y PDF disponibilizados en distribuciones padrón para esto. Adicionalmente, el OpenOffice.org ofrece una forma de producir directamente el producto del PDF.

La producción de un PDF puede ser configurada como un servicio de impresión (vista como una impresora PDF disponible en la red), dando, de ese modo, un método transparente de impresión en archivo PDF para todos los programas, tanto los propietarios, mismo rodando en sistemas propietarios en la red, cuanto los en código libre conectados a la red. El utilitario Scribus es capaz hasta mismo de generar formularios PDF.

12.8.2 Correo Hay una enorme gama de interfaces usuario para correo electronico, tanto para ambientes pro-

pietarios cuanto software libre. Por eso, este documento puede sólo delinear una visión general del proceso de migración y sus cuestiones. El Correo también está discutido en la Sección 11.2 y en el Apéndice B.

Las principales cuestiones del tipo cliente son:

• Elección del nuevo Mail User Agent (MUA), y consecuentemente de su interface usuario.

• Migración de la correspondencia personal almacenada.

• Migración de los registros en el catálogo de direcciones.

Independientemente del MUA elegido, será necesario migrar la correspondencia almacenada y los registros del catálogo de direcciones.

Caso el MUA antiguo tenga sido configurado para almacenar todas las pastas de correo en un servidor IMAP, será preciso muy poco trabalho y el nuevo MUA puede ser implesmente confi-gurado para accesárla en su local. Donde los archivos locales tengan sido usados como pastas, será necesario rastrearlos y convertirlos. Por default, el Outlook ® almacena correspondencia en archivos con extensión .pst” en C: \ Documents and Settings \ <username> \ Local Settings \ Application Fecha \ Microsoft ® \ Outlook ® .

Herramientas de migración útiles incluyen:

• http://outport.sourceforge.net – exporta contactos, tareas y agenda, pero no mensajes, del Outlook ® para Evolution, etc.

• La própia herramienta de exportación del Outlook, probablemente escribiendo en formato CSV o

Excel. También presenta el problema de incapacidad de exportar anexos a esos formatos.

• http://sourceforge.net/projects/ol2mbox – Herramienta del software libre para convertir archivos

��


Outlook ® *.pst para un formato usáble en correos software libre. Da soporte a los anexos.

• Kmailcvt – Herramienta software libre para convertir algunos formatos propietarios para uso con Kmail.

12.8.3 Calendarios y Groupware Los calendarios, junto con el gerenciamiento de contactos y el correo, son usualmente

agrupados en un título general Personal Information Management (PIM). Algunos paquetes integrados, como el Outlook ® de la Microsoft ® , ofrecen las tres funciones en una interface, además otros como el ACTI, se concentran en gerenciamiento de contactos y poderían ser considerados próximos a los sistemas CRM (Customer Relationship Management).

Una opción interesante es el Evolution, que integra funciones de una forma muy próxima a la que el Outlook ® hace. El Mozilla también podría ser considerado así; él incluye un cliente correo electrónico eficiente y existe ahora un módulo calendario disponibilizado en: http://www.mozilla.org/projects/calendar. Él es basado en el padrón iCalendar abierto y los usuarios pueden publicar y partillar calendarios usando el protocolo WebDAV.

Calendarios

Algunos de los más bien desarrollados recursos de calendarios software libre están en conjuntos groupware basados en la Web, y vale la pena examinarlos como posibles servicios amplios de organización.

Los padrones iCalendar (previamente vCalendar) definen un formato de troca para los registros de calendario. Detales pueden ser encontrados en http://www.imc.org/pdi e em RFC2445, RFC2446, y RFC2447. La mayoría de los juegos de calendarios software libre pueden trabajar con datos en ese formato, por lo tanto, es la ruta de migración preferida, bien como los medios normales de gerenciamiento diario.

Algunas de las herramientas de migración mencionados en la Sección 12.8.2 arriba también son capaces de extrair informaciones sobre calendarios de los archivos de datos del Outlook ® , para el formato iCalendar.

Gestión de contactos

Casi todos los paquetes de correo electrónico que ya existieron definirán sus própios formatos para el almacenamiento de datos de libros de direcciones. Algunos se restringen a almacenar sólo direcciones de correo electrónico, además formatos más recientes tienden a incluir todos los tipos de nformaciones de contactos. Esa diversidad de formatos vuelve la migración más difícil, al contrário de lo que podría ser.

Felizmente, la mayoría de los aplicativos de correo electrónico, tanto en el mundo propietario cuanto en el mundo de software libre, tendieron a implementar los formatos de permuta iCard (anteriormente vCard) en los últimos años. La especificación de ese formato es abierta, y puede ser obtenida en http://www.imc.org/pdi y también en RFC2425 y RFC2426. Si los detalles de contacto deben ser transferidos de un aplicativo propietario para un aplicativo software libre, este es el formato preferido.

Una otra forma de trabajar con informaciones sobre contactos, es consolidarla en un directorio que abrange toda la organización y después accesarla vía LDAP.

��


Certamente eso debe ser hecho con dados ampliamente utilizados, tales como el libro de teléfonos internos y la lista de correo electrónica mantenidos por muchas organizaciones. Además, no es una sustitución completa por libros de direcciones personales: un catálogo de direcciones debe ser pequeño y focado en las necesidades de la persona que lo usa, mientras un directorio debe ser abrangente (probablemente) y muy grande para follear efectivamente.

Algunas de las herramientas mencionados en la Sección 12.8.2 acima también son capaces de extrair información de los archivos de datos del Outlook ® para el formato iCard.

12.8.4 Navegación Internet Usuarios de sistemas propietarios pueden usar alguna versión del Microsoft ® Internet

Explorer ® para navegación. También es posible que algunos usen Netscape ® , Mozilla o Opera ® .

Migrar de un navegador web para otro es bastante fácil para los usuarios, ya que todos poseen recursos equivalentes e interface gráfica semejantes (a la parte de navegadors modo texto como el Lynx, por razones óbvias). La cuestión, para usuarios individuales, estará centrada en la conversión de la lista de favoritos: la mayoría de los navegadors en software libre puede importar favoritos del Internet Explorer ® y del Netscape ® , si instalados en la misma plataforma.

Además si el Sistema Operacional también esté siendo migrado, entonces puede ser necesario exportar primero favoritos en el formato de un archivo HTML. Cualqueir organización que use páginas de la web intranet debe verificar si el HTML está en conformidad con los padrones W3C, de forma que se presente apropiadamente en todos los navegadors. Hay herramientas para ayudar en este asunto en http://www.w3c.org .

Cualquiera de las páginas que dependan de JavaScript, necesitarán ser testadas con particular cuidado, ya que el dialecto varía de un navegador para otro y el uso de extensiones no padronizadas causará problemas.

Cualquiera de las páginas que dependan de los controles ActiveX ® , deberán ser redibujadas para trabajar de alguna otra forma, ya que los navegadores software libre no dan soporte a esa tecnología propietária. El ActiveX ® tiene un modelo de seguridad muy pobre, así, desabilitarlo es un paso valoroo, en cualquier caso.

Formatos de extensión de la web comunes, como Java ® , PDF, Flash ® y RealPlayer ® reciben un buen soporte de los navegadors en software libre (aunque usen frecuentemente plugins propietarios,).

Otros formatos como Shockwave Director, precisarán usar el plugin CodeWeavers CrossOver.

12.8.5 Bancos de Datos Personales Soluciones con volumen de datos muy grande o complejo para una planilla, pero no

grande lo suficiente que justifique un banco de datos comercial completo, frecuentemente usan el Microsoft ® Access ® . Este paquete ofrece un depósito de datos relacionales simples, junto con scripting y herramientas para construcción de formulario.

��


La migración de datos para bancos de datos software libre está cubierta en la Sección 12.7.2 Hay ventajas en almacenar bancos de datos en servidores bien gerenciados, mismo si la gerencia de TI esté gerenciando los datos o dando soporte a los aplicativos. Una migración software libre da la oportunidad de ofrecer tal servicio de almacenamiento de datos, a través de la configuración de un servidor donde individuos puedan construir sus propios aplicativos de banco de datos. Hay varios paquetes basados en la web que podrían ser elegidos como base para eso, tal como el PHPmyAdmin: el sítio http://www.phpmyadmin.net/documentation ofrece los detalles.

Herramientas con GUIs más convencionales incluyen:

• Kexi123 – un banco de datos con la interface usuario del proyecto KDE, voltado para

un mercado similar al del Access ® . • DBDesigner24 – una herramienta para usuarios más avanzados, que se integra tanto al

GNOME cuanto al KDE. • Knoda25 – otro con interface usuario simples para el KDE.

Ninguna de esas herramientas intenta leer archivos Access ® .

12.9 Migrando servicios de impresión para software libre

En ambientes de pequeñas oficinas, es comun que las impresoras estén directamente ligadas a la estación de trabajo. Oficinas mayores, y los que requieren un alto volumen de impresión, tienden a usar impresoras ligadas a la red - ellas pueden estar directamente ligadas a la red o gerenciadas por un servidor de impresión.

En sistemas basados en soluciones de software libre hay el soporte a ambos los modelos, aunque sea más comun encontrar servidores de impresión y un pequeño número de impresoras de grande capacidad.

12.9.1 El modelo de impresión en el ambiente propietario La impresión en un sistema operacional propietario es casi siempre hecha a partir de un

ítem en el menú de un aplicativo. Es muy raro que la línea de comando sea utilizada. Los aplicativos generan productos impresos usando un proceso muy similar al que usan para disponibilizar información en la pantalla. Un conjunto de drivers (software de gerenciamento de hardware) específicos para impresión es usado por el sistema operacional, para generar el flujo de datos corrientes para la impresora. Esos drivers son normalmente suministrados por el fabricante de la impresora, y deben ser instalados en el local o en el servidor de impresión antes de cualquier impresión. En un ambiente de red, es mejor instalar y configurar los drivers en el servidor de impresión, de forma que los clientes no necesiten ser configurados a mano.

23 http://www.koffice.org/kexi/ 24 http://www.fabforce.net/dbdesigner4/ 25 http://www.knoda.org/

��


12.9.2 El modelo de impresión Unix y GNU/Linux El GNU/Linux heredó su modelo de impresión del BSD Unix. Los aplicativos generan

archivos o flujos de datos para impresión que son repasados para un programa de impresión en segundo plan, que se responsabiliza por el trabajo de impresión. Los trabajos pueden ser colocados en una fila y pasados transparentemente para otras máquinas en la red. Los primeros sistemas Unix no poseían una interface independiente de impresión para generar datos de impresión, de esa forma, cada aplicativo tenía que incluir un código para cada tipo de impresora que condujera. En el tiempo en que la impresión era hecha con un único tipo de carácter, eso no era problema, Además, cuando los fabricantes comenzaron a adiccionar recursos gráficos, cada uno creó un nuevo y diferente lenguaje de impresión.

Los sistemas de impresión BSD siempre tuvieron capacidad de alimentar trabajos de impressión a través de un conjunto de filtros, entonces las personas comenzaron a diseñar filtros que convirtieran de un lenguaje de impresión para otro, para aumentar la variedad de soporte a las impresoras. Muchas de las mejores impresoras usadas en laboratorios de investigación poseían intérpretes PostScript, por lo tanto, el PostScript pasó a ser usado como el lenguaje de impresión independiente comun.

La mayoría de los distribuidores GNU/Linux están sustituyendo ahora el sistema de impresión BSD por un nuevo paquete llamado CUPS (Common Unix Printing System), que da soporte al Internet Printing Protocol (IPP) además del tradicional protocolo lpr. Eso completa la transición para el nuevo modelo de impresión:

Los aplicativos generan trabajos de impresión en el Postscript. Cuando los trabajos pasan para el sistema de impresión, el aplicativo puede requisitar cualquier recurso especial que la impresora soporte (impresión dupla, doblada, cosida, perforada, ligada etc). Las requisiciones tienen un formato padrón, pero obviamente sólo serán bien sucedidas si la impresora posee el hardware necesario. Hay una forma de acceso padrón para que los aplicativos puedan saber cuales son los recursos soportados por una dada impresora.

Los trabajos pueden ser colocados en fila local en la estación de trabajo o pasados imediatamente para un servidor de impresión. El usuario no necesita saber que método está siendo utilizado.

El sistema de impresión puede distribuir los trabajos entre un conjunto de varias impresoras similares.

El servidor de impresión dirige el trabajo a través de un canal de filtros, que lo convierte en fases, para cualquier formato necesario a la impresora corriente, y para controlar la comunicación con la impresora.

Hay, en el momento, más de 600 modelos de impresoras conocidas por que trabajan con esos

modelos (i.e. aplicativos GNU/Linux pueden accesar todas las funciones disponibilizadas usando los drivers Windows ® fornecidos por ellos, fabricantes y con resultados equivalentes o mejores).

Aunque el PostScript sea el formato intermediario más usado, el CUPS puede ser configurado para dar soporte a casi todos los formatos de archivos con los cuales los filtros pueden trabajar. Particularmente, es comum que se permita que PDF, JPEG y algunos otros formatos sean impresos directamente, y algunos sites disponibilizam filtros que hacen

��


impresión bonita y automática de correo electrónico etc. El CUPS fornece interfaces compatibles con el conjunto lpr BSD y también con el lp do System V. Por lo tanto, es posibles sustituir por entero los sistemas antíguos por máquinas existentes (FreeBSD, OpenBSD, y la mayoría de las variantes Unix). Existen drivers disponibles que conectan clientes del sistema operacional propietario Windows ® a un servidor CUPS, disponbilizando los servicios para una mayor variedad de usuarios. Entonces es posible utilizar un sistema GNU/Linux como un óptimo servidor de impresión.

El CUPS da una vasta gama de características y recursos, incluyendo identificación auto

mática de servidores de impresión, contabilidad de páginas, cuotas etc. Para mayores detalles vea el sitio http://www.cups.org.

12.9.3 Configurando un servicio de impresión basado en software libre Para distribuciones muy pequeñas, es simple configurar impresoras directamente ligadas a

cada estación de trabajo de cada cliente. Ellas pueden ser compartidas a través de la red, si deseado, y el CUPS ofrece soporte muy facilmente.

El uso de servidores de impresión es recomendado para todos los casos donde hay más de lo que un puñado de clientes, o cuando haya un volumen substancial de impresión. Deben ser insta-ladas una o más máquinas servidoras de impresión, y ellas deben reciber nombres lógicos en el DNS además de sus hostnames. Eso permite configuraciones para nombres de referencia como print-server.example.org en vez de pc35.example.org, tornando entonces más fácil reorganizar el servicio más tarde. Todas las máquinas de clientes deben ser configuradas para que se dirijan a uno de los servidores de impresión para todas las necesidades de impresión: eso evita tener que reconfigurar cualquiera de los clientes cuando las impresoras sean adiccionadas o removidas.

12.9.4 Imprimiendo a partir de clientes propietarios para impresoras GNU/Linux anexas

Hay muchas formas de configurar servidores de impresión basados en GNU/Linux para dar soporte a máquinas estación de trabajo. Eso varía de acuerdo con el volumen de esfuerzo inicial y con el volumen de esfuerzo requerido por cliente.

Usando el protocolo lpr

Ese método es apropiado donde un número muy pequeño de clientes propietarios necesita recibir soporte.

El lpr es un protocolo muy comun, para pasar trabajos de impresión entre máquinas Unix.. Como mencionado anteriormente, él está siendo sustituído gradualmente por el IPP, pero es largamente implementado y puede ser utilizado a partir de muchas versiones de ambiente propietario.

1. Asegúrese que la máquina GNU/Linux esté configurada para aceptar trabajos usando el lpr.

2. Obtenga un juego apropiado de drivers de ambiente propietario para la impressora. En términos ideales, debería ser el driver CUPS genérico, que genera PostScript portátil, además es posible usar drivers específicos para impresión, caso el CUPS esté configurado para permitir impresiones simple.

��


3. Conéctese a la máquina Windows ® como Administrador.

4. Abra el programa utilitario de la Red en el Painel de Control, seleccione la tecla Servicios y asegúrese de que la “impresión Microsoft ® TCP/IP de la Microsoft ® ” esté listada. Adiccione, si necesrio (eso requiere el CD de distribución y la reiniciación de la computadora).

5. Configure la impresora en el cliente Windows ® como si fuera una impresora local (no conectada a la red). Al seleccionar una puerta para la impresora, críe una nueva “puerta LPR” y configúrela para enviar los trabajos para el servidor GNU/Linux.

Ahora el cliente Windows ® podrá enviar trabajos de impresión para la máquina GNU/Linux,Sin embargo las herramientas Windows ® pueden no conseguir ver y manipular trabajos en fila. El CUPS da soporte al gerenciamento basado en la web, por lo tanto los usuarios deben ser avisados para usar ese recurso, cuando necesario.

Usando cuotas de impresoras

Ese método también es apropiado para un pequeño número de clientes propietarios. Él trabaja con Windows 95/98/ME ® , bien como con Windows NT/2000 ® .

1. Instale y configure el Samba en el servidor GNU/Linux. Siga las instruciones para crear

cuotas de impresoras: es fácil hacer el Samba crear automaticamente una cuota para cada impresora que el servidor reconozca.

2. En cada cliente Windows ® , use el Add Printer Wizard para acrescntar una impresora conectada a la red. Usted debe ser capaz de hojear una lista de servidores para encontrar o servidor que usted quer usar. Voce vai precisar instalar drivers de impresoras localmente, en la máquina del cliente.

Como recurso para refinar el esquema, el Administrador puede usar el Add Printer Wizard para cargar drivers de impresoras en el servidor Samba, de forma que no sea necesario instalarlos individualmente en los clientes.

Usando configuración Point and Print

Este metodo es apropiado para instalaciones mayores y para aquellas en que máquinas de clientes nuevos deben ser configuradas por equipes menos calificadas. Requiere un poco más de esfuezo para configurar en um primer momento, pero es más fácil de usar depués de pronto. El proceso es bastante complicado, por lo tanto, consulte el HOWTO del Samba para mayores detalles.

1. Instale y configure el Samba en el servidor GNU/Linux. Para soporte Point and Print debe ser la versión 3.0 o arriba, aunque muchas funciones tengan soporte en 2.2.4. Asegúrese de que el Samba esté construído con soporte CUPS.

2. Configure el CUPS para dar soporte a las impresoras Windows ® , agregando el paquete de driver CUPS.

3. Use cupsaddsmb para instalar los drivers Windows ® del CUPS para el Samba.

4. Conéctese a partir de un cliente Windows ® usando una identidad que permita modificar configuraciones de impresión en el servidor, y configure las características de la impresora

��


default apropiadamente (tamaño del papel etc). Eso es más complicado de lo que parece, pues el Windows ® da dos ventanas idénticas en partes diferentes de la configuración GUI y sólo una de ellas afecta las configuraciones default. (Vea el HOWTO del Samba para detalles).

5. En cada cliente Windows ® , hojee los vecinos de la red para encontrar el servidor. Clique en la impresora que usted desea y “Conéctela”. La impresora ahora está en la lista de impresoras locales y puede ser utilizada facilmente.

Grandes instalaciones tendrán a usar un script de conexión para el íten 5, en vez de hacerlo a mano.

12.9.5 Imprimindo esquemas de migración Para organizaciones pequeñas, con algunas estaciones de trabajo y impresoras, es simple

configurar un servidor de impresión basado en GNU/Linux y simplesmente reconfigurar cada estación de trabajo cliente a mano. Caso haya diversas impresoras compartidas ligadas a las máquinas estación de trabajo, puede valer la pena aprovechar la oportunidad para consolidarlas en un servidor de impresión. Eso puede volverse más fácil ajustando placas ethernet a las impresoras, donde ellas soportem el recurso (eso también puede ofrecer una mejoría subtancial del desempeño sobre interfaces seriales o paralelas). Impresoras paralelas sólo pueden ser ligadas a la red usando cajas de impresión de red.

Locales mayores ciertamente irán beneficiarse del uso de uno o más servidores de impresión. Esas máquinas pueden desempeñar otras tareas también, pero, si hay un volumen sustancial de impresión, se debe recordar que convertir el PostScript para otros formatos genera un trabajo intensivo para la CPU y la capacidad de las máquinas debe ser evaluada apropiadamente. Vale la pena hacer la configuración Point and Print completa caso tenga que ser suministrado soporte a los clientes propietarios, ya que la migración de máquinas clientes de los servidores de impresión del ambiente propietario para la plataforma libre puede ser hecha con un simple script de conexión.

12.9.6 Problemas Potenciales Hay algunos problemas comunes que pueden ser evitados a través de un planeamiento

cuidadoso:

1. Asegúrese que cada impresora sea controlada apenas por un servidor. Haga con que todas

las otras estaciones de trabajo y servidores envien trabajos para la impresora a través del servidor que los controla. Esto es particularmente importante con impresoras ligadas a la red. Caso eso no sea hecho, la impresora podrá recibir dos o más trabajos al mismo tiempo, con posible corrupción del producto.

2. Si posible, intente hacer con que sólo un juego de drivers formate la producción de una impresora. Sería probablemente mejor hacerlo en el servidor controlador, pero no ne-cesariamente – dependerá, hasta cierto punto, del servidor que posea el mejor driver para la impresora. Otras máquinas procesando la impresión del producto, deben tratarlo como datos brutos. Caso no sea hecho, un driver podrá intentar formatar un flujo de productos ya formatado, corrompiendo la producción. Eso sólo lleva a transformarse en un problema cuando el producto formatado contiene datos binarios.

��


12.9.7 Informaciones adicionales sobre impresión Una buena parte de la información está disponibilizada en la Web. Estos sitios son puntos

de partida útiles:

http://www.cups.org – CUPS, o Common Unix Printing System.

http://www.linuxprinting.org – el sitio Linux Printing, con una vasta gama de informaciones útiles.

http://www.linuxprinting.org/kpfeifle/SambaPrintHOWTO – el HOWTO del Samba Printing. Note que este es el sitio de distribución del autor y que el documento es un trabajo en curso. Busque por la última minuta.

12.10 Aplicativos legados Los aplicativos que no poseen sus correspondientes en software libre y que no puedan ser

recompilados para trabajar como software libre, tendrán que trabajar en una máquina girando el sistema operacional que pueda soportar este aplicativo legado, o en un emulador de hardware o software. Las técnicas discutidas en el capítulo son aplicables.

12.11 Protección antivírus Un paquete antivirus actualizado es esencial en cualquier ambiente. Hasta mismo

organizaciones con poco interés en seguridad ignoran esta protección a su propio riesgo.

En contraste, hay pocos virus viables que afectan los sistemas software libre. Como consecuencia, la proteción contra virus, en los ambientes de software libre,se limita normalmente a la limpieza de correos electrónicos para evitar pasaje de virus para usuarios de ambiente propietario.

Hubo ataques automatizados a sistemas de software libre en el pasado. Un fuerte foco en seguridad en los años posteriores al evento redujo los riesgos considerablemente, pero todavía es posible que un virus efectivo pueda un día ser liberado. Buenas prácticas de gerenciamiento de sistemas y educación continua del usuario es actualmente una defensa mayor que un software antivirus.

Hay actualmente dos proyectos antivirus software libre conocidos, el Open Anti Virus26 y el ClamAV27.

El sitio del ClamAV incluye documentación enseñando como crear nuevas formas de virus que todavía no están detectados, ya que el formato del programa y archivos es abierto. Y como incluirlas al lado de las firmas oficiales (sin interferir en ellas), bien como contribuir de vuelta a la comunidad esta nueva firma. Eso es muy importante en redes de mucho tráfico, donde el administrador puede crear una nueva firmar para un nuevo y destruidor virus en pocos minutos desde la constatación y evitar la propagación vertiginosa. Sin tener que esperar la próxima actualización oficial, que mismo en el caso del ClamAV en incidentes graves puede tardar 1 hora. En una hora de exposición, una gran red puede ser contaminada.

26 http://www.openantivirus.org/ 27 http://www.clamav.net/

��


No depender de terceros para la creación de firmas y bloqueo de los virus es una buena ventaja administrativa. El ClamAV también puede ser configurado para barrer archivos en el servidor de archivos Samba (que simula un servidor de archivos e impresión NT), para los clientes Windows ® . Así protegiendo el almacenamiento y el cambio de archivos en el servidor

Muchos de los productos antivirus comerciales poseen versiones que funcionan en plataformas software libre. Esas versiones no son por entero equivalentes a sus contrapartes en ambiente propietario – en el momento están direccionadas para funciones como barrido de correspondencia en vez de detención inmediata en código ejecutable de virus, como es común en los sistemas propietarios. Como ya mencionada, detección inmediata es, en la mayor parte, desnecesaria en sistemas software libre; el barrido de la correspondencia es en general suficiente.

12.12 Referencias http://www.samba.org – The Samba SMB file/print/domain server http://www.openldap.org – The OpenLDAP directory server http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html – The LinuxPAM system administrator’s guide http://us4.samba.org/samba/docs/man/Samba-HOWTO- Collection.html – The main Samba HOWTO collection http://www.csn.ul.ie/~airlied/pam_smb – pam_smb PAM module to authenticate GNU/Linux users with SMB

http://samba.idealx.org/index.en.html – IDEALX tools and HOWTOs relating to Samba.

��


CAPÍTULO 13

13. ESCENARIO 2 – UNIX

La Administración posee servidores Unix (“big Unix” – Solaris ® , HP/UX ® ,AIX ® , OSF/1 ® , etc). Usa PCs con aplicativos cliente-servidor. Algunas estaciones de trabajo Unix y Terminals X.

La migración de las estaciones de trabajos PC será similar a del Escenario 1 arriba. Es probable que las estaciones de trabajo y los Terminales X estén funcionando con aplicativos basados en X, los cuales deben funcionar sin cualquier problema en las nuevas estaciones de trabajos software libre. El principal problema aquí es migrar los servidores.

Migrar de Unix para el GNU/Linux es similar a la transferencia de una versión de Unix para otra.

Teniendo en mente que el término Unix incluye AT&T ® , BSD ® y los códigos base OSF/1 ® , que son implementaciones diferentes del padrón POSIX – como es el GNU/Linux. Las diferencias aparecen cuando un programa usa recursos que están fuera del POSIX, cosas típicas como administración de sistema y recursos para mejorar el desempeño. Programas escritos fuera del padrón POSIX, también presentaron problemas – escribir programas portátiles es un arte, “programas cultivados en casa” tienen a demandar algún trabajo (eliminación de todos los avisos de compilador producidos en más alto nivel de advertencia es un buen comienzo). Pero, es probable que los problemas sean detalles y no arquitecturales, fundamentales. Los Unixes usan protocolos abiertos, tales como TCP/IP y servicios comunes como DNS and DHCP.

Es probable que también la configuración sea diferente. Pero, no es probable que los datos del sistema sean mantenidos en un formato propietario, consecuentemente, manipularlos para que estén en conformidad con los requisitos GNU/Linux debe ser bastante fácil. Eso incluye nombres de usuario y señas, aunque diferencias sutiles puedan significar que la simple transferencia no es posible.

Si el código de fuente esté disponible, la recompilación debe permitir que el código sea transferido. Pero hay algunas cuestiones que necesitan ser comentadas:

1. No hay padrón para la ubicación de los archivos y ellos pueden estar bien criptografados en los

programas (como /usr/bin, /usr/local/bin o /opt/bin). 2. Puede haber valores diferentes para las constantes de sistema, por ejemplo, el número máximo

de archivos que pueden estar abiertos al mismo tiempo.

3. Diferencias sutiles en el lenguaje de programación, por ejemplo ksh e pdksh. Compiladores C diferentes son más o menos exacto en la verificación de sintaxis, por lo tanto, el código puede ser permitido en una máquina y presentar error en otra. El código puede no ser portátil por algunos motivos, por ejemplo:

• Uso no portátil de las constantes, como usar número en vez de SIGPIPE (algo definido en un archivo encabezamiento C). Eso es un ejemplo de un programador

��


programando para el sistema operacional en vez del padrón POSIX. • Suposiciones sobre el cumplimiento de la palabra o la ordenación de byte. El

gcc, compilador en GNU/Linux, tiene opciones bastante flexibles en esas circunstancias.

4. Cada Unix puede tener archivos encabezamientos y bibliotecas diferentes. También pueden estar en ubicaciones diferentes. Los locales y nombres pueden ser alterados automáticamente, una vez encontrados. Pero, si la biblioteca o el archivo encabezamiento presentan comportamientos diferentes, será necesario intervención manual. Por ejemplo:

• La semántica de algunas llamadas de bibliotecas difiere: • Como threads; • Exec (ignorado o bit setuid en scripts); • Asynchronous I/O; • Ioctl para controle tty. • Valores diferentes para errno.

El código original puede usar aplicativos propietarios o bibliotecas no disponibles en GNU/Linux. Puede necesitar ser reescrito para usar lo que esté disponible en GNU/Linux. Puede ser el caso si son solocitadas interfaces de hardware especiales, por ejemplo, una placa de fax. Hay muchos trabajos para hacer en esas circunstancias.

5. Los Makefiles que ayudan en la construcción de aplicativos pueden necesitar de

actualización para reflejar sobre las diferencias mencionadas arriba. 6. Los aplicativos pueden hacer suposiciones sobre subsistemas específicos como los de

impresión y bancos de datos. Eso significa, por ejemplo, que el código SQL puede tener que ser reescrito.

7. Transferir cualquier código para un nuevo hardware, compilador o sistema operacional

puede presentar errores en el programa, los cuales están siempre ahí, pero nunca aparecieron, por ejemplo, por estar la memoria dispuesta de forma diferente, números enteros tienen tamaños diferentes o los bytes son ordenados de forma diferente.

Las siguientes referencias son más detalles: http://www.linuxhq.com/guides/LPG/node136.html http://www.ibm.com/servers/esdd/articles/porting_linux/index.html?t=gr,l=335,p=PortSolaris2Linu

x http://www.ibm.com/developerworks/linux/library/l-solar/?open\&t=grl,l=921,p=Sol-Lx http://www.ibm.com/servers/eserver/zseries/library/techpapers/pdf/gm130115.pdf http://www.unixporting.com/porting-guides.html

��


CAPÍTULO 14

14. ESCENARIO 3 – MAINFRAME

La Administración es basada en una mainframe (puede funcionar con MVS ® , VM/CMS ® , AS/400 ® , o hasta Unix). La mayoría de los usuarios posee Acceso a la pantalla verde. Hay pocos PCs, la mayor parte siendo usados como emuladores de terminales, pero con uno o dos aplicativos.

Este escenario es similar al del Cliente Leve en lo que dice respecto a la estación de trabajo, particularmente si la arquitectura es mantenida.

No fueron reunidos datos de migración de servidores. El capítulo 20 presenta un proceso de migración todavía no concluido.

��


CAPÍTULO 15

15. ESCENARIO 4 – CLIENTE LEVE

La Administración usa estaciones de trabajo tipo Cliente Leve (Thin Client con acceso vía Citrix ® o similar a una mezcla de Windows ® y aplicativos Unix.

El uso de la ABR no es asumido aquí porque las razones originales de utilizar un modelo cliente leve puedan todavía ser consideradas consistentes. Pero, si es contemplada una mudanza para el ABR, muchos de los mismos problemas del Escenario 1 van aparecer. La migración en este Escenario, bajo esta presuposición es, por lo tanto, muy simple, ya que la arquitectura no va mudar.

Por el hecho del cliente ser bastante leve, todo lo necesario es un software lector de fuente abierta para cada protocolo requerido. El sistema de ventanas no necesita de mucha funcionalidad, por lo tanto será suficiente un gerenciador de peso leve como el tvwm.

Los siguientes protocolos pueden obtener soporte (entre otros):

1. HTTP. Cualquier navegador software libre será suficiente. La capacidad de funcionar con

Javascript y Java ® tendrá que ser investigada. Adicionalmente, cualquier extensión requisitada tendrá que recibir soporte directamente, a través de un sustituto usando el paquete plugger.

2. ICA. Este es el protocolo Citrix propietario. El Citrix da un lector ICA “precio cero”, pero no

software libre, que trabaja en el GNU/Linux. 3. RDP. Este es el protocolo utilizado por lo Servidor de Terminal Windows ® . Hay disponible un lector

software libre para RDP en estación de trabajo. 4. VT220, VT100 etc. Estos protocolos DEC reciben soporte de xterm usando el conjunto de

variables ambientales TERM apropiadas. La conexión con el host es hecha vía telnet.

El xterm puede emular muchos tipos de terminales diferentes a través de la mudanza del valor de la variable TERM. Por ejemplo, la configuración de TERM=prism9 va emulara el protocolo usado por las máquinas PRIME. Todas las emulaciones asumen la conectividad telnet o si-milar y un protocolo basado en caracteres en vez de basado en página.

5. AIP. Este es el protocolo propietario utilizado por la Tarantella, capaz de dejar disponible

aplicaciones GNU/Linux, Windows, Mainframe y AS/400 en la internet/intranet. 6. 3270. El programa x3270 da soporte apropiado. La conexión con el host es hecha vía

telnet. 7. X. Este es el protocolo de exhibición original GNU/Linux y, por lo tanto, no debe presentar

problemas.

Hay productos propietarios para algunos de los protocolos más herméticos.

��


El Linux Terminal Server Project (LTSP) http://www.ltsp.org suministra un número de kits

para construir dispositivos cliente leve basados en GNU/Linux. Este es un proyecto extremamente activo y la calidad del software parece ser muy buena. Las mudanzas solicitadas en los servidores son similares a las consideraciones discutidas en los otros Escenarios.

��


PARTE V - ESTUDIOS DE CASOS

��


CAPÍTULO 16

16. ESTUDIOS DE CASOS

Esta parte presenta la compilación de referencial de casos prácticos de migración de Administración Pública Federal, con objetivo de posibilitar una demostración práctica de la metodología de migración sugerida en la Sección 5, además de las directrices y recomendaciones presentadas en las partes II, III y IV.

Los estudios de caso disponibles hasta esta versión son los siguientes, listados en las próximas páginas:

• Ministerio de Desarrollo Agrario

• Ministerio de Comunicaciones

• RADIOBRÁS

• Marina del Brasil

• DATAPREV

• Embrapa

• SERPRO

• Instituto Nacional de Tecnología de Información

��


CAPÍTULO 17

17. MINISTERIO DE DESARROLLO AGRARIO

17.1 Migración de servidores Institución: Ministerio de Desarrollo Agrario Sitio: www.mda.gov.br

Caso: Plan de Migración para Software Libre

Responsable: Paulo Ricardo Carvalho de Oliveira [email protected]

Palabras-llave: Servidores de Red, Correo electrónico, Customización, Economía.

��


17.1.1 Los Motivos 1. La oportunidad de realizar la autonomía de la REDE MDA, concebiendo una gestión completa de los recursos de red, de los sistemas de control y de comunicación entre las unidades de MDA.

2. La posibilidad de realización de una customización de los sistemas y servicios, a través de una completa integración de los procesos que son los principales desafíos de Administración Pública:

• Desburocratización; • Aplicación de los principios de calidad total; • Comunicación multimidia; • Prestación de servicios; • Transparencia total; • Reingeniería tecnológica;

17.1.2 Plan de Acción El proyecto de migración previó la contratación de una consultoría especializada, creación de

sala de REDE MDA, adquisición de nuevas computadoras servidores con Software libre, adquisición de nuevas estaciones de trabajo con la suite Openoffice.org instalada, curso de introducción al Openoffice.org, desarrollo de sistemas de control interno, desarrollo de la Intranet y Desarrollo del portal de MDA.

Definimos como foco de actuación la migración de 95% de los servidores de red y también la migración de los aplicativos de automación de oficina de 30% de los usuarios en periodo de corto plazo. Esta estrategia fue elegida por ser considerada la menos impactante para los usuarios de la RED MDA.

17.1.3 Aspectos Culturales La utilización del Software libre debe ser considerada como una conquista participativa,

pues envuelve cada profesional, individualmente, en todas las etapas y depende de su interés en aceptar el desafío de mudanza.

Los factores culturales son los más complejos para trabajar con las mudanzas en las organizaciones. Existe la necesidad de motivación constante en los equipos para ampliar la flexibilidad, dotándolas de capacidad para enfrentar los desafíos que la modernidad impone a las organizaciones.

Las tomadas de decisión exigen el apoyo de administración superior, que debe conocer las potencialidades y dificultades de utilización de SL en la conducción de todos los profesionales, para la construcción de esa nueva cultura organizacional. El apoyo político es imprescindible para que haya posibilidad de implementaciones que alteren las rutinas de las instituciones.

��


En MDA, el Ministro Miguel Rosseto siempre fue entusiasta de SL e incentivó las primeras ediciones del Forum Internacional de Software libre (FISL) en Porto Alegre/RS, a cargo de vicegobernador del estado, durante el gobierno Olívio Dutra.

17.1.4 Capacitación de los Usuarios y Equipo Técnico El Software libre es un sistema en desarrollo y posee canales que proporcionan a los usuarios

que participen de este desarrollo, bastando que estos estén capacitados para interagir con los sistemas y comprender su funcionamiento, desde el nivel más básico, como utilización de softwares clientes de correo, editores de texto o acceso a la internet, hasta el nivel avanzado, como desarrollo de sistemas integrados online.

La migración impone la necesidad de capacitación de todos los usuarios y principalmente de los profesionales de área de desarrollo y de red. La capacitación debe ser realizada constante-mente y poseer canales de comunicación ágiles. Es necesario un monitoramiento de la evolución de este conocimiento en todas las áreas.

Para enfrentar nuestro desafío, fue realizada una investigación para identificar el perfil del usuario de la RED MDA, donde fue constatado un alto índice (85%) de los profesionales cursando el 3 grado o con 3 grado completo, factor considerado como positivo para implementación de las mudanzas previstas. Había un proceso de adquisición de 100 estaciones de trabajo, donde fue definido que los aplicativos de automación de oficina serían todos de la suite Openoffice.org. Para estos usuarios fue contratada una empresa que realizó el curso de Introdución, divididas en grupos de 8 horas de clase, distribuyendo apostilla y CD con softwares libres y gratuitos. Un total de 90 profesionales fueron entrenados. En una investigación de satisfacción, respondida por 50% de los alumnos, 85% consideraron el curso como bueno u óptimo.

Para los profesionales de red y de soporte, serán realizados cursos de Linux en empresas tercerizadas.

17.1.5 Los Servicios de RED y Correo electrónico En el área de red, 90% de los servicios funcionan actualmente en la plataforma de SL y

existen herramientas de monitoramiento de hardware y de los servicios a través de gráficos on-line. Contamos con 7 servidores espejados, a través del servicio de Alta Disponibilidad, garantiendo la estabilidad de los servicios. En el servicio de correo electrónico, poseemos barrera de virus y de spam. Están siendo desarrollado sistemas de gestión y de integración de los servicios, en el cual se destaca un Sistema online de Gerenciamento de Postfix (Servidor de Correo), a través de una interface grafica, con herramientas de importación y exportación de usuarios, gerenciamiento de análisis, gerenciamiento de informaciones de los usuarios y otras funcionalidades. Está previsto también un Sistema online de Gerenciamento del Samba (Servidor de Red), integrado con el Postfix y semejante en las funcionalidades. La Tabla 17.1.5 presenta los servicios y los Softwares Libres utilizados:

Tabla 17.1: Servicios y Software Libre utilizados.

Tipo de Servicio Software Livre Utilizado Sistema Operacional RedHat 9.0 Servidor SMTP Postfix

��


Servidor POP3 Ipop3d Webmail

Squirrelmail

Servidor Backup

Amanda

Servidor Base de Dados

PostgreSQL y MySQL

Servidor Grafcos Monitores

LRRD

Servidor de Archivos Samba

Servidor de Logon Samba

Servidor DNS Bind

Servidor Firewall

Ipchains

Servidor http Apache Antivírus Clamav

17.1.6 Customización de los Sistemas En el área de desarrollo de sistemas fue posible la alteración inmediata del Portal estático

de MDA para un sistema de gerenciamiento de contenido, el NAWEB, que posibilita gerenciamiento on-line, mecanismo de busca, edición de noticias y otras funcionalidades. El NAWEB posibilitó la creación del proyecto "SACI LIVRE", SACI es una sigla de Sistema de Administración de Contenido Institucional en la Internet, desarrollado en software libre que posibilitará la administración de varios portales institucionales. A través de herramientas desarrolladas en módulos, el sistema permitirá la colaboración de la comunidad de Software libre y proporcionará una nueva concepción de administración de portales institucionales corporativos.

Utilizando el lenguaje PHP y el Banco de Datos PostgreSQL, herramientas bastante populares y robustas, padronizamos los Sistemas Online y comenzamos a desarrollar una serie de sistemas de control interno, totalmente integrados con los sistemas de control de red, correo electrónico y con la Intranet.

El equipo de desarrolladores es el pilar de migración del MDA, pues es de ella la tarea de construir las herramientas que sustituirán las aplicaciones propietarias para aplicaciones en SL. Otra tarea del equipo de desarrollo es la de definir y sustentar los padrones que orientarán el desarrollo de los nuevos sistemas en las unidades de MDA.

Cuando los sistemas son customizados, las tareas diarias se vulven procesos digitales que son aprimorados con la herramienta on-line. Las aplicaciones más modernas posibilitan una serie de funcionalidades:

• Control total del flujo de informaciones;

• Unicidad de información;

• Comunicación digital y multimídia;

��


• Investigación e cateaje de datos;

• Documentación y registros;

• Interacción en tiempo real;

• Interface

• Universalidad de Acceso

Todos los proyectos están concebidos para que sean integrados en módulos, eso torna más simple la construcción de los primeros pilares y posibilita desarrollar más de un sistema por vez. Ya están prontos los módulos de control de acceso y seguridad - CONTRA y el módulo de Gerenciamento de usuarios de correo - POSTMAN. Inauguramos recientemente nuestra nueva Intranet y lanzamos el nuevo Sistema de Atendimiento al Usuario - SISAU, que posibilita un gerenciamento total de las solicitaciones de servicios y de tareas.

17.1.7 Los Desafios Enfrentados En el servidor de correo electrónico, conseguimos una gran reducción de paradas de los

servicios y una ampliación de la utilización de los servicios. Actualmente estamos enviando en media 3500 mensajes y recibimos en media 38.000 mensajes en días útiles. La Figura 17.1 representa esa evolución:

Figura 17.1: Gráfico Anual

Otros servicios relevantes son las herramientas de bloqueo de virus y de spam, que posibilitaron mayor seguridad y estabilidad para la REDE MDA. La Figura 17.2 ilustra la evolución de ese mecanismo de contról:

Gráfico Anual at Cnors

��


Figura 17.2: Gráfico Anual de errores

Para la migración del servicio de RED, la mayor parte de los servicios fueron implementados con amplio éxito y total transparencia para los usuarios de la red.

En la implementación del Openoffice.org el desafío mayor fue la adaptación de los usuarios, que presentaron una pequeña dificultad en la formatación de los documentos migrados de los aplicativos propietarios. Los usuarios avanzados tuvieron problemas en el soporte, pues el curso realizado contemplaba apenas informaciones básicas de comparación de los aplicativos. Las operaciones avanzadas necesitaron de soporte y nuestro equipo no estaba plenamente capacitada para solucionar todos los problemas.

17.1.8 Economía Alcanzada A pesar de una evaluación rigurosa exigir un escenario de largo plazo, podemos estimar la

economía en la reducción de costos de adquisición de hardware y también en la reducción de los costos de adquisición de software.

La economía en la adquisición de hardware se debe al hecho de que el Software Libre posibilita la utilización de computadoras servidores con especificaciones más simple de lo que el Software Propietario.

Para la implementación del sistema de alta disponibilidad, que permite la utilización de dos computadoras para sustentar cada servicio, fueron adquiridas más 7 computadoras, con las especificaciones técnicas aproximadas a los ya utilizados en nuestra red.

Ciertamente la calidad de las computadoras indicados por los fabricantes de software propietario es mayor y su depreciación es ciertamente más larga que las computadoras sustitutas, además todas las adquisiciones proveen garantía on-site (cambio de las piezas con defecto) para todos los ítenes por el período de 36 meses.

Otra consideración importante es que las especificaciones de los componentes ( memoria RAM, procesador, placa-madre, grabador de cintas DAT, Disco Rígido SCSI de alta performance) fueron adquiridas idénticas a los servidores principales.

La Figura 17.3 presenta una comparación entre los equipos indicados por los fabricantes de software propietario y los equipos adquiridos.

��


Figura 17.3: Comparativo de adquisición de hardware en abril de 2004 – valores de mercado.

La Figura 17.4 presenta un comparativo entre las soluciones propietarias y los substitutos en Software Libre.

��


17.1.9 Experiencia Adquirida Procuramos pontuar los itenes que consideramos relevantes para volver nuestro proceso de

migración más confiable y sustentable:

Figura 17.4: Comparativo de adquisición de software en abril de 2004 – valores de mercado.

Válvula de Escape - Siempre desarrolle el plan con alternativas de retorno a la situación anterior, caso la implementación de un servicio no obtenga suceso. Eso evita el desgaste de parada de los servicios, que puede ser albo de críticas, generar trastornos y trabajo doblado.

Comunicación - Comunicar siempre las paradas de servicios y las actividades, con la debida antecedencia para que todos acompañen la evolución del proceso de migración.

Investigación Continua - Crear canales de comunicación en la Intranet y en la Internet, con los documentos paso a paso de cada nuevo software disponible. Ampliar el acervo de la biblioteca sobre los softwares elegidos.

Horarios Alternativos - Realizar todas las mudanzas posibles fuera del horario del servicio de los usuarios, para minimizar los impactos de las actividades para los usuarios.

��


17.1.10 Resultados Positivos La mayor ventaja es la flexibilidad que el desarrollo de sistemas en Software libre

proporciona, fortaleciendo la mejoría continua en el área de TI, dotando las unidades ejecutoras de herramientas de soporte para maximizar la utilización de los recursos en la ejecución de las acciones del MDA a su público beneficiario y en la transparencia de los resultados al restante de la sociedad.

��


CAPÍTULO 18

18. MINISTERIO DE COMUNICACIONES

Institución: Ministerio de Comunicaciones Sitio: www.mc.gov.br

Caso: Migración para Software Libre

Responsable: Welber António Luchine [email protected]

Palabras-Llave: Planeamiento, Sensibilización, Entrenamiento.

18.1 Plan de migración

18.1.1 Introducción En junio de 2003 iniciamos el estudio de viabilidad del proyecto de migración para

software libre del Ministerio de Comunicaciones, y desde entonces estamos trabajando para concretizar lo más rápido posible esa solución.

18.1.2 Escopo Migración de la plataforma operacional de los servidores del CPD, sustitución de los

sistemas operacionales, suites de oficina y otros aplicativos de las estaciones de trabajo y sustitución de las herramientas de administración de red y desarrollo de sistemas.

18.1.3 Planeamiento y Ejecución Realizamos un planeamiento estratégico con toda el equipo de técnicos de Coordinación

de Informática de MC, durante un día, fuera del local de trabajo para que pudiésemos aprovechar lo máximo posible el tiempo sin que hubiera cualquier interferencia de trabajo. Además, disponibilizamos de un profesional facilitador del proceso de planeamiento para ayudarnos en la tarea propuesta.

Consecuentemente, varias acciones fueron definidas y están siendo seguidas como plan de trabajo de este Ministério. Abajo explicitamos las acciones y sus desdoblamientos.

a) Patrocinador del proyecto - es fundamental que el proyecto sea apoyado por la alta administración del órgano. Sin ese apoyo no podemos implementar el proyecto, pues el no estaría en la política estratégica de organización. El apoyo deberá ser renovado siempre que haya una sustitución de patrocinador.

��


b) Estudio de viabilidad - buscamos comparar el gasto anual con licenciamiento de software

con el gasto en sustituciones (consultorias y entrenamientos), además de la compatibilidad técnica entre los programas que deberían ser sustituidos. De ese levantamiento, mapeamos todos los posibles problemas de adecuación de nuevos programas.

c) Decisión sobre la distribución que sería utilizada - inicialmente decidimos utilizar la distribución Debian en los servidores, teniendo como premisa, que esa distribución no podría ser adquirida por ninguna empresa de tecnología de información. Así, iniciamos concomitantemente, los testes con la distribución Kurumin en ambiente corporativo. Ella se mostró ser una herramienta de rápida configuración, permitiendo disminuir el tiempo de instalación de la estación para el usuario en relación con las máquinas que usan programas propietarios.

Pero, la distribución todavía no está completa para ejecución en ambiente corporativo. Nuestro equipo tuvo que construir algunos scripts para que el ambiente corporativo sea incor-porado y pudiese funcionar adecuadamente. Mientras, es una herramienta que puede facilitar la introducción del software libre en las estaciones, sin costo y con una excelente performance.

d) Capacitación del equipo técnico - investir en la capacitación de sus técnicos para que ellos puedan actuar sobre ese nuevo paradigma es factor crítico para el suceso de su proyecto y debe ser la primera acción efectuada. Sin el comprometimiento del equipo técnico y su habilidad en contornear determinadas situaciones, el proyecto quedará sin rumbo y predestinado al fracaso. En nuestro caso, definimos los entrenamientos técnicos en sistema operacional GNU-Linux de acuerdo con el perfil del profesional, pudiendo de esa forma adecuar el contenido programático de cada entrenamiento.

Caso haya un equipo tercerizado, de acuerdo con cada contracto de servicio, se puede ne

gociar con la empresa el entrenamiento de los profesionales. En caso de nuestro proyecto, definimos junto a la administración del MC el entrenamiento para algunos servidores del cuadro y para los colaboradores tercerizados negociaremos con la empresa su capacitación.

e) Migración de los servicios básicos de red (no críticos) - El equipo técnico del MC, después su capacitación, inició la sustitución de algunos servicios no críticos de red que estaban en software propietario, para su correlactivo en software libre. Esa mudanza fue totalmente transparente para los usuarios del Ministerio. Hoy una tercera parte de los servicios de red ya están migrados y sin que ningún presente cualquier alteración o falla.

f) Sensibilización de los usuarios - la mudanza de paradigma es grande para el usuario de las estaciones de trabajo. Esa resistencia puede ser disminuida si ellos están preparados para la mudanza, buscando mostrar la importancia de esa alteración para nuestro país.

Nosotros realizamos tres días de conferencia sobre software libre, con la participación del Sr. Djalma Valois, mostrando para los usuarios la necessidad de mudar y que ellos no dejarían de cumplir sus tareas, pues todas las principales herramientas ya tienen sustitutas en software libre.

g) Consultoria técnica especializada - Fue definido como crítica la migracáo de los servicios fundamentales de comunicación de las estaciones con el ambiente externo y la configuración de alta disponibilidad de los servicios. Para solucionar ese problema, preparamos una licitación para el auxilio en esa tarea crítica que esperamos finalizarla en diciembre/2004.

h) Capacitación de los usuarios - Configuramos un proyecto de capacitación de los usuarios para uso de las estaciones con la preocupación de no dejarlos despreparados para la tarea.

��


Nuestra intención es construir una cultura de entrenamiento en informática en el órgano, capacitando los usuarios para las mudanzas deseadas, sin traumatizarlos con las mudanzas.

Nuestro proyecto prevé la mudanza de la plataforma operacional de la estación de trabajo, simultaneamente con el término del entrenamiento del usuario.

��


CAPÍTULO 19

19. RADIOBRÁS

19.1 Migración de estaciones de trabajo

Institución: RADIOBRÁS Sitio: www.radiobras.gov.br

Caso: Migración de RADIOBRÁS Responsable: José Roberto Barrozo Costa [email protected]

Palabras-llave: Estación de Trabajo, Sistema Operacional, Legado.

Para no haber solución de continuidad en los trabajos desempeñados en la empresa y posibilitar la implantación del Linux en estaciones de trabajo. El procedimiento a ser adoptado es:

• En las estaciones que sólo utilizan la herramienta Office (principalmente Word ® y Excel ® ) y acceso a la internet, será instalado el sistema operacional Linux y el Openoffice (ambos softwares libres).

-En microcomputadoras que utilizan programas propietarios (como por ejemplo el sistema de recursos humanos, el sistema de publicidad legal, etc) será necesario la utilización de un software para accesar tal recurso. Este programa es el Rdesktop.

Teniendo estas directrices como norte, fueron electos equipos en diversas áreas, dando preferencia a aquellos que no necesiten utilizar el Rdesktop, por un problema de infraestructura y de licencias.

En julio de 2003 adelante de inminente migración, fue iniciado el entrenamiento en sistema operacional linux para el equipo de informática. Fue ministrado un curso con carga horaria de 60 horas. Fueron entrenadas tanto las personas de soporte, bien como los desarrolladores.

En septiembre/2003 con el apoyo de ITI, PRODABEL y UFMG fue efectuada la migración de 14 (catorce) estaciones de trabajo, en 3 áreas de la administración. La distribución utilizada fue el Libertas 2.0 de la PRODABEL y con el apoyo de la UFMG fue iniciada la autenticación de estas estaciones en el LDAP.

Como habíamos hecho la migración y las personas de la informática continuaban extremamente inseguras en tocante principalmente al soporte, a los usuarios y servicios. Enfrentamos diversos problemas con impresión y acceso a los archivos del legado.

Con las dificultades enfrentadas en el día-a-día, resolvimos continuar testando otras distribuciones, y optamos por hacer una mudanza del Libertas 2.0 para el Red Hat 9, con esta

��


pequeña mudanza conseguimos mejorar el flujo de los servicios y las demandas de los usuarios diminuyeron mucho.

Aún así, había un gran problema, el acceso al SERPRO, que en esta época era hecho vía HOD 6, y el mismo no tenía soporte al Java Virtual Machine 2 o superiores, siendo que los navegadores usados en el linux ya los utilizaban. Esto, además de haber causado trastornos a los usuarios que tuvieron sus equipos migrados e imposibilitando migrar a áreas donde el uso de los sistemas basados en SERPRO es fundamental.

Con mucha lucha y apoyo del ITI, el SERPRO actualizó su versión de HOD y posibilitó este acceso, que abre nuevas posibilidades de migración.

Hoy, contamos con 37 estaciones utilizando linux/openoffice y 7 servidores (Postfix, Squid, MySQL, APACHE, LDAP, DNS, DHCP y Firewall).

Mostrando nuestra disposición cuanto a la migración, fue autorizada por el Director de Área Administrativa la participación del mayor numero de técnicos de área de informática en la semana de capacitación promovida por el ITI. De los 17 funcionarios del Departamento, 15 participaron de por lo menos un curso.

EL equipo de desarrollo está preparándose para programar en PHP, un equipo que cuenta con programadores en lenguajes Delphi, VB, JAVA e ASP, e ya está cierto que los nuevos desarrollos de sistemas serán utilizando este lenguaje.

Principales problemas enfrentados:

• el equipo técnico no estaba preparado para la migración. Había sido dado sólo un entrenamiento de 60 horas, pero no había todavía personas habilitadas para efectuar el soporte;

• la instalación fue efectuada en un fin de semana, sin haber sido hecho un plan B y sin haber entrenamiento para los usuarios, y ni mismo una conferencia de esclarecimiento;

• la distro seleccionada para implantación en las máquinas fue el Libertas 2.0 GNU/LINUX de PRODABEL, por falta de conocimiento por parte del equipo técnico de la RADIOBRAS. Esta distro presentó varios problemas por causa de nuestra realidad de equipos (eran bien más nuevos que los usados con la distro en Minas Gerais), lo que ocasionó problemas de configuración de equipos, principalmente impresoras;

• Migración del cliente de e-mail (Xmian - evolution) sin mientras haber habido la migración del servidor (Exchange), los usuarios quedaron sin listas de direcciones y contactos, entre otros;

• la versión de openoffice utilizada, todavía presentaba muchas incompatibilidades con los docu

• mentos del legado, producidos con el Microsoft ® Word ® ;

• no había la opción de utilizar el RDESKTOP para acceso a los sistemas legados, pues no

• poseíamos licencias de uso para terminal service en nuestros servidores Windows ® ;

��


• pierda de acceso a los sistemas do SERPRO, pues con la utilización del mozilla que utiliza el Java2 quedamos imposibilitados de comunicar con el sistema HOD de SERPRO que sólo trabajaba con Java1;

Principales avanzos:

• El equipo técnico se quedó más cohesa con el nuevo desafió, y profundó sus conocimientos de linux. Aprendió a compartir más el conocimiento y a investigar las soluciones a los problemas presentados;

• El equipo de desarrollo está padronizando el lenguaje de nuevos desarrollos facilitando la manutención de los sistemas, bien como el desarrollo colaborativo;

��


CAPÍTULO 20

20. MARINA DE BRASIL

20.1 Plan de migración para mainframe

Institución: Marina de Brasil Sitio: www.mar.mil.br

Caso: Experiencia en utilización de Software Libre en Mainframe

Responsable: Cap. António Luiz Barbosa

[email protected] .br

Palabras-llave: Mainframe, Plan.

En el período de un año, fueron iniciados estudios, realizados testes e implantado ambiente Linux en IBM S/390 de la Marina de Brasil, demostrando la posibilidad de preservación de investimentos ya instalados.

En una 1a. fase, están siendo mantenidos en paralelo, en áreas virtuales distintas, S.O. propietario y S.O. Linux.

Ventajas:

• compartimiento de recursos;

• múltiplos ambientes operacionales;

• uso compartido y flexibilidad;

• flexibilidad de software y hardware;

• particiones lógicas distintas;

• • consolidación de servidores para: contingencia, desarrollo, entrenamiento etc;

• Con eso, el "mainframe"puede ser empleado como servidor corporativo (web, Intranet, e-mail, EAD).

• Resultados esperados:

• uso más racional de recursos de hardware;

• reducción de costos ( flexibilidad de configuración);

• interoperabilidad;

• portabilidad de las aplicaciones;

• aumento de los requisitos de seguridad con la customización.

��


CAPÍTULO 21

21. DATAPREV

21.1 Servidores de autenticación Institución: DATAPREV Sitio: www.dataprev.gov.br

Caso: Procedimientos adoptados por la Dataprev en la migración de servidores Netware (Novell) para servidores Linux, mas de 200 servidores.

Responsable: Énio Tolentino Silva

[email protected]

Palabras-llave: Servidor, Samba, Autenticación.

La DATAPREV incentivó la realización de las migraciones en junio de 2001, se creó un documento de orientación para sus técnicos, pero dejando claro que no sería una "receta de pastel", y sin padrones y procedimientos mínimos para que la migración sea realizada con suceso en todas las áreas de la Previdencia Social. También para ese proceso fue creada una lista en correo interno para poner dudas, otro recurso fue la disponibilidad de 2(dos) ramales directos con la División de Soporte Básico para apoyo a los técnicos que actuaron directamente en migración.

Para el suceso en el proceso de migración sugerimos una evaluación completa de todo ambiente, en nuestro caso procedimos de la siguiente forma: montamos laboratorios simulando el ambiente de producción (Netware + Aplicaciones) y migramos para (Linux) ejecutamos el mayor número de testes y simulaciones posibles, hasta alcanzar total estabilización del ambiente LINUX.

Documento de Orientación utilizado en el procedimiento de migración. Ambiente Novell:

1) Recomendamos para el proceso de migración el apoyo de un empleado de la regional que

conozca Novell para ayudar el empleado responsable por el ambiente LINUX, pues durante todo proceso de migración serán necesarias informaciones del ambiente Novell. Llamaremos durante la documentación este equipo de "servidor Novell".

2) Levantar toda configuración del servidor Novell: los volúmenes, los directorios, los

usuarios activos y inactivos, los programas, las permisiones, los grupos, los archivos. 3) El levantamiento de configuración debe ser detallado para que ninguna configuración o

datos de ambiente antiguo sean perdidos 4) Realizar Backup.

Ambiente Linux:

1) La distribución del Linux utilizada fue Conectiva con el servicio SAMBA.

2) Verificación de compatibilidad de hardware con Linux.

��


Ambiente de Triangulación:

Será utilizada una máquina con el windows instalado: 95, 98, NT o 2000, puede ser servi-dor o estación, que desempeñará la función de triangulación entre los dos ambientes: servidor Novell y servidor Linux. Llamaremos este equipo de máquina de triangulación.

Etapa configuración de linux:

Instalar con perfil de servidor de red con el servicio SAMBA.

Los servicios adicionales serán el PROFTP, SSH, INET, MC, Apache y PHP.

Para instalación de servidor linux, fue creada una ruta de acuerdo con los padrones de la Dataprev.

Utilizamos el Particionamiento de Disco descrito en la tabla a seguir, para máquinas con HD con 2GB o más:

Tabela 21.1: File-system y Espaco

Filesystem Espacio /boot 15MB /swap 2,5 veces la memória RAM, com no Maximo 256MB / 25% Del espacio, mínimo de 500MB e Maximo de 1GB /apl Todo lo resto

Crear los directorios. Algunos en el futuro serán mapeados para el usuario en sus estaciones de trabajo.

Home/usr - Abajo del usr quedaron los directorios de los usuarios.

Home/samba/temp - Directorio temporario, específicos para archivos administrativos, compartillados, comunes, macros etc.

Home/samba/datos - Directorio que recibe el volumen sys y datos (no de los usuarios) del servidor Novell.

Home/samba/netlogon - Directorio de configuración de logon de usuarios en la red, donde quedará el archivo startup.bat en anexo.

Caso se elija el proceso manual:

Digitar en prompt linuxconf => elección el ítem Cuentas de Usuarios => Adicionar => rellenar los campos Nombre da Cuenta y Nombre Completo Crear los Grupos

Son necesarios caso exista una política de grupos en servidor novell Definición de grupos => Adicionar => rellenar el campo Nombre del Grupo

Configurando el SAMBA:

El archivo para configuración del SAMBA es el smb.conf, conforme ejemplificado en figura 21.1. Los mapeamientos padrón serán de acuerdo con su ambiente. Habilitar acceso via WEB

Caso el administrador quiera gerenciar el SAMBA vía WEB, editar el archivo inetd.conf y deshabilitar la línea referente al SWAT.

��


Digite linuxconf => Procure la opción painel de controle => elija Control de Actividad de Servicios. En la lista disponible procure INET y lo marque como [x] automático, procure linuxconf y lo deje como activo y en SWAT marque el activo.

También en linuxconf Ambiente de red Habilitación linuxconf vía red Máquinas que pueden accesar: rellenar con la dirección de las máquinas que podrán accesar por la internet, preferencialmiente los administradores.

Etapa Migrando del Novell para el Linux

Verificar si en el servidor linux fueron creados los usuarios activos y de los inactivos lo que todavía serán utilizados del antiguo servidor novell

A través de la máquina de triangulación, accese con el usuario administrador en los dos ambientes y mapee el servidor Novell después mapee el servidor linux, ambos para todo el directorio raíz Transfiera los datos usuario por usuario de una máquina para otra.

Al migrar archivos para el directorio del usuario sus archivos fueron grabados por el root y el propio usuario no puede accesar su archivo. Se debe alterar las permisiones en todos los archivos. Acabando los usuarios comience los datos.

��


Figura 21.1: Archivo de configuración de SAMBA.

La estructura que fue solicitada en inicio para ser anotada será importante ahora. Críe abajo de /home/samba los mismos directorios que existían en el servidor novell, Por ejemplo:

Servidor novell: /sys/rh servidor linux: /home/samba/rh

Después de crear todos los directorios de forma idéntica al servidor novell comience a través de la máquina de triangulación a transferencia de los datos.

En este caso como los volúmenes son grandes haga en etapas.

Acabando la migración de los datos entre en la fase de testes del servidor linux.

# Archivo de Configuración de SAMBA # Parámetros de configuración global

,[global] workgroup = <nombre de grupo de trabajo> netbios name = <nombre netbios de servidor> server string = <descripción de servidor>

security = SERVER <para autenticación en un servidor> password server = <nome

ou ip do servidor de autenticación> log level = 2

log file = /var/log/samba/log.%m :lmhosts bcast>max log size = 50 keepalive = 20name resolve order = <orden de resolución de nombrs de red, ex:wins

socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 wins server = <ip

do servidor wins> :administradores, ex: @adm>admin users = <nome do administrador o grupo de los usuarios ex:/*.db?/*.DB?/*.ftp>

add user script = /usr/sbin/adduser -n -g estaciones -d /dev/null -s /bin/false %u

#<entre abajo con los compartimientos que deben ser creados, ex:>

# [<nome-do-compartimiento>] # comment = <descripción> # path = <camino>

# read only = <si es apenas lectura, ponga yes, si lectura/escrita, no>

# create mask = <mascara de permisiones en los archivos y archivador creados

dentro del compartimiento>

eiWiPpdkft?~'0 Pan~a de permisiones, ex: yes> [datos] comment = sistemas y datos de usuarios

path = /apl/datos

read only = No

force create mode = 0775

force directory mode = 02775 [restore] comment = datos restaurados

valid users = @adm path = /apl/restore

read only = No

force create mode = 0775

force directory mode = 02775

��


Etapa de teste de funcionamiento

Accese con un usuario cualquier por el ambiente del cliente y verifique si el mismo consigue trabajar con sus archivos y si los sistemas utilizados por ellos están en pleno funcionamiento.

¡Buena Suerte!

��


21.2 Herramienta de control de versión Institución: DATAPREV Sitio: www.dataprev.gov.br

Caso: Implantación de Herramienta de Control de Versión.

Responsable: Jorge Maciel Pereira

[email protected]

Palabras-Llave: Controle de versión, CVS

21.2.1 Introducción

La DATAPREV, empresa de Tecnología e Informaciones de la Previdencia Social, experimentó en los últimos cuatro años, un crecimiento exponencial del uso del ambiente de plataforma baja en la construcción de sus aplicativos. Sumándose a este hecho, los proyectos de nivel estratégico de la Previdencia Social, apuntan para el uso de plataformas abiertas y uso de herramientas no propietarias.

La necesidad de atender a las directrices de estos planes estratégicos y, al mismo tiempo, padronizar el ambiente tecnológico de esta plataforma, motivó a las equipes de Administración de Datos y de Soporte a Aplicaciones, bajo patrocinio de los respectivos gerentes de departamento, a buscar alternativas para preservar las inversiones ya realizadas, diseminar conceptos de la Gerencia de Configuración de Sistemas en la empresa y minimizar las dificultades de las áreas de apoyo y soporte, para garantir la sustentación de los sistemas en esta plataforma.

Con este objetivo, el equipo técnico propuso y el Comité de Tecnología de la empresa homologó en 08/2002, la herramienta CVS (Concurrent Version System) para gestión de fuentes en plataforma baja. Es la principal herramienta de guarda de objetos en el mundo del software libre, siendo utilizado, incluso, para almacenar los programas fuentes del propio LINUX.

El objetivo mayor de este esfuerzo es internalizar en la cultura de la empresa, los conceptos de guardia y administración de fuentes, usando la herramienta homologada como instrumento de gestión. Para tal, fue elaborada una estrategia de internalización de la herramienta, basada en la capacitación de los equipos de apoyo, conferencia para divulgación junto al cuerpo gerencial de la empresa, entrenamiento de los desarrolladores utilizando instructores de la propia empresa e implantación de la herramienta.

Estas acciones fueron realizadas durante el 2o semestre de 2002 y todo el año de 2003. Actualmente, más de 350 desarrolladores fueron entrenados y más de 170.000 objetos están catalogados en 247 proyectos. Además, evitamos el gasto de cerca de R$200.000,00 en entrenamiento para la empresa, con la capacitación interna que fue realizada.

21.2.2 Resumo de la migración de los objetos Antes de la implantación del CVS, el almacenamiento de programas y objetos en

plataforma baja no era padronizado, siendo que cada equipo de desarrollo utilizaba métodos propios de salva y versionamiento de programas y objetos. Las soluciones adoptadas recorrían

��


espectro bastante variado, yendo del "back-up"en disquetes hasta el uso de gerenciadores de fuentes propietarios.

Con la implantación del servidor CVS en 07/2002, los equipos de desarrollo definieron la prioridad de migración de sus proyectos para el nuevo ambiente. Los equipos de desarrollo fueron entrenadas en el uso de la herramienta conforme prioridad definida. El directorio de cada proyecto fue creado, conforme padrones de la empresa y fue autorizada el acceso para que cada gerente de proyecto registre su equipo e iniciar la migración de los programas y objetos.

Cada equipo definió su ritmo de migración y uso del aplicativo, cabiendo a los equipos de apoyo garantir la disponibilidad del ambiente y el apoyo al uso de la herramienta.

Actualmente, la empresa discute los procedimientos y normas necesarias para que el CVS sea efectivamente utilizado para el pasaje de programas y objetos para el ambiente de producción.

21.2.3 Datos técnicos del ambiente CVS en la DATAPREV

Versión instalada en los servidores

cvs-1.11.16-1.11.17.diff.bz2 Configuración de los servidores

La herramienta está instalada en dos servidores, siendo un para atender a los proyectos desarrollados Por los equipos sediados en Rio de Janeiro y otro para los proyectos de Brasília. Ambos los servidores poseen sistema operacional LINUX y la autenticación para acceso es hecha a través del propio archivo de señas del sistema operacional.

• La configuración del servidor CVS situado en Rio de Janeiro es la siguiente: Pentium III - 512 Mb de RAM - HD 40 Gb;

• La configuración del servidor CVS situado en Brasília es la siguiente: Pentium Pro - 128 Mb de RAM - HD 20 Gb.

Estación cliente

La herramienta instalada en la estación cliente es el WinCVS, en la versión 1.30, siendo que no hay configuración mínima necesaria para su instalación.

Herramientas de apoyo

Como herramientas de apoyo en el ambiente de desarrollo es utilizado el WinMerge y el aplicativo CVSAdmin. La primera herramienta tiene como objetivo comparar versiones ("revisions") de un mismo objeto. Fue elegida por el equipo de la empresa, pero cualquier otra herramienta de comparación podrá ser utilizada en conjunto con el WinCVS. Esta segunda herramienta fue desarrollada en la propia empresa para divulgar el contenido de los archivadores en la intranet. Esta divulgación tiene por objetivo facilitar la investigación de objetos ya disponibles.

Como herramienta de apoyo para el ambiente de producción, fue desarrollado el aplicativo CVSOper, que será utilizado por las áreas de operación de la empresa, para transferir los programas y objetos del repositorio CVS para el ambiente de producción.

Instalación de las herramientas

��


Para instalación de la versión de la herramienta WinCVS, dentro de la empresa, fue creada archivador para baja de archivos, bastando informar: ftp://<nombre servidor cvs>

Soporte externo

Además de la formación del equipo de apoyo/soporte, la DATAPREV identificó en el mercado un socio para soporte de nivel más alto y adaptación de la herramienta a las necesidades específicas de la DATAPREV. Para eso, fue firmado, con una empresa de Rio de Janeiro, participante de la comunidad de software libre, un contrato de soporte.

21.2.4 Instalación de las herramientas

Para la sociedad en general, las herramientas y respectivas documentaciones pueden ser obtenidas en las siguientes direcciones:

• CVS – http://www.cvshome.org

• WinCVS – http://www.wincvs.org o http://cvsgui.sourceforge.net/download.html

��


CAPÍTULO 22

22. EMBRAPA

Institución: Embrapa – Empresa Brasileña de Investigación Agropecuaria Sitio: www.embrapa.gov.br

Caso: Red de Software Libre para Agropecuaria. Responsable: Moacir Pedroso Júnior [email protected] Palabras-Llave: Agropecuaria, AgroLibre, Software Livre

22.1 AgroLibre El Software Libre permite que el usuario pueda ejecutar, copiar, distribuir, evaluar,

modificar y perfeccionar el código fuente del software, sin que sea necesario solicitar cualquier autorización previa al autor del programa. Varias iniciativas vienen siendo tomadas para el uso e incentivo de desarrollo de software libre en el país, principalmente en el sector público, visando no apenas una economía de recursos, con efecto inmediato, pero posibilitando un aumento de la soberanía tecnológica del país e incentivo a programas de inclusión digital.

La Embrapa - Empresa Brasileña de Investigación Agropecuária1, referencia nacional en investigación agropecuaria, posee las condiciones técnicas para incentivar y apoyar el uso y el desarrollo del software libre para el sector. El conocimiento del dominio agropecuario distribuida en sus 40 Unidades de investigación, aliado a la capacidad técnica de los profesionales de informática de la empresa, y más específicamente, de los técnicos de la Embrapa Informática Agropecuaria, establecen las condiciones adecuadas para la actuación en este sector.

En este contexto está siendo creada la Red de Software Libre para Agropecuaria - AgroLibre 2, que visa atender a la demanda del sector agropecuario en las áreas de sistemas de apoyo a la tomada de decisión, de apoyo a la investigación científica y de apoyo a proyectos de inclusión digital.

La Red AgroLibre es un proyecto de la Embrapa, bajo la coordinación de las unidades Departamento de Tecnología de la Información - DTI3 y Embrapa Informática Agropecuaria 4. Compete al DTI la definición de las políticas de adopción de software libre y de certificación digital en la Embrapa. Cabe a la Embrapa Informática Agropecuaria la coordinación del repositorio de software libre para uso del sector agropecuario, bien como la creación y la manutención del sitio de la Red.

Para la Embrapa Informática Agropecuaria, cuya misión es generar, promover, difundir y aplicar tecnologías de información y comunicación, viabilizando soluciones para el desarrollo sustentable de la producción y de la investigación agropecuaria, el momento se muestra

��


oportuno para iniciar un proyecto de apoyo e incentivo al uso de software libre, visando acelerar la generación de sistemas que faciliten el acceso a la información de calidad y de interés para el sector agropecuario.

La actuación calificada del Departamento de Tecnología de la Información en este proceso es imprescindible para la implantación del uso efectivo del software libre en la empresa, tanto en sus sistemas corporativos como en las herramientas de oficina, adecuándose a las directivas del Gobierno Federal. En particular, en los sistemas corporativos, hay la necesidad de adecuar y construir sistemas con certificación digital, creando las condiciones necesarias para agilizar el trámite de documentos tanto interno como externo y, consecuentemente, aumentar la eficacia y la eficiencia de la empresa en el cumplimiento de su misión.

El apoyo del Instituto Nacional de Tecnología de la Información - ITI en este desafío es fundamental tanto en el desarrollo de proyectos con certificación digital, pero también como uno de los órganos incentivadores en el uso de software libre en soluciones para las instituciones gubernamentales, beneficiando directa y indirectamente la populación brasileña.

��


CAPITULO 23

23. SERPRO

Institución: SERPRO – Servicio Federal de Procesamiento de Datos

Sitio: www.serpro.gov.br

Caso: Gerenciamento de las Redes Locales en el SERPRO.

Responsable: Jones Lamanna Tesser

[email protected]

Palabras-Llave: Gerenciamento de Redes, MRTG, Nagios.

23.1 Gerenciamento de Redes

23.1.1 Introducción

La Gestión de Redes Locales, además de las actividades de administración propiamente dicta, exige profundo conocimiento de los procesos de Gerencia. Estos cuando bien definidos y estructurados posibilitan control de la infraestructura utilizada, acompañamiento del desempeño, anticipación a las fallas, monitoración y análisis de ocurrencia y tendencias.

23.1.2 Objetivo

Presentar de manera clara y sucinta los procesos, procedimientos o actividades, herramientas y resultados, de la Gerencia de Redes Locales, buscando ejecutarlas con eficiencia y eficacia.

23.1.3 Escenario

El ambiente de Red Local presenta grande complejidad con innúmeros problemas y cuestiones que exigen actuación precisa e inmediata. El desempeño de una red local casi siempre es previsible con razonable antecedencia, cuando procesos son aplicados y practicados. Las actividades relacionadas a los procesos de Gerencia de Redes Locales, son bastante simple y, justamente por esto llevan varios profesionales a cometer errores primarios por entender que la ejecución de algunas prácticas son suficientes para el adecuado gerenciamento de la red local. El almacenamiento de informaciones de configuración o de algunos datos relacionados al desempeño de los recursos, así como la análisis eventual de estes ambientes no representan de manera alguma Gerenciamento de la Red. La Gerencia exige procesos bien estructurados, procedimientos adecuados, disponibilización de indicadores, análisis e interpretación de resultados, planeamiento y, además, disciplina en la práctica de estos requisitos.

��


23.1.4 Procesos de gerenciamento

El modelo de referencia adoptado por el SERPRO para la Gerencia de Redes Locales, es el ITIL - "IT Infrastructure Library"(Biblioteca de Infra Estructura de la Tecnología de la Información), que fue desarrollado en la década de 80 por la agencia del gobierno Británico, "OCG - (Office of Government Commerce)".

Esta Biblioteca compuesta por 10 (diez) libros/procesos está agrupado como: Soporte (Service Support) y Entrega (Service Delivery), este segundo más apropiadamente calificado como Servicios.

La implementación de estos procesos exige estudio y dedicación, pero principalmente disciplina. Estos procesos deben ser implementados progresivamente sin que la cultura de las organizaciones sean desrespetadas y abandonadas, valorizando los procedimientos implantados que ya estén produciendo buenos resultados, observando y persiguiendo las mejores prácticas del mercado. Considerando estas dificultades, en esta primera etapa estaremos implementando los procesos más esenciales, que posibiliten avanzos para el SERPRO en la prestación del servicio de Administración de Redes Locales, sin que sea necesario investimientos y mudanzas radicales en nuestra cultura y de nuestros clientes.

El gerenciamiento a ser estructurado, implementado y practicado por la SUPTI en la prestación del servicio de Administración de Redes Locales, presupone la implantación de los procesos de Capacidad, Continuidad y Disponibilidad, cabiendo en este momento el destaque para la necesidad de implementación de otros procesos que se relacionan con estos y que tienen extrema importancia para el suceso do gerenciamento de las redes locales. Son ellos: Incidentes, Problemas, Mudanza, Configuración y Niveles de Servicio, debiendo los procesos de Gerenciamiento de Liberaciones y de Financiero sean tratados en otro momento.

Es importante resaltar que los procesos aquí mencionados tienen fuerte relacionamiento unos con los otros, de forma que el desrespeto y la discontinuidad en la ejecución de los procedimientos y actividades en ellos descriptos reflejará negativamente en los demás, recordando todavía sobre la importancia de la manutención de las prácticas de suceso existentes en la organización.

Buscando preservar la cultura de nuestra organización estaremos implementando las disciplinas de "Capacidad, Continuidad y Disponibilidad", como sub-procesos del entitulado "Proceso de Gerenciamento".

Gerenciamento de la Capacidad

Al Gerenciamento de la Capacidad es atribuida la responsabilidad de garantir la capacidad de tráfico interno, procesamiento y almacenamiento de los servidores de las redes locales, acompañando las demandas del negocio, buscando mayor eficiencia y menor costo. Así siendo, este sub-proceso contempla procedimientos y actividades que propicien controlar y acompañar la capacidad de los recursos, de forma que las cargas de trabajo estén adecuadas al potencial de los recursos en producción.

Gerenciamento de la Continuidad

El Gerenciamiento de la Continuidad es el sub-proceso responsable por observar todas las interrupciones de los recursos que afecten o puedan afectar los servicios, garantiendo acciones alternativas que permitan restablecer la continuidad del servicio, a través de Ítenes de Configuración alternativos o sustitutos, manteniendo así los niveles de servicio contratados. Es importante resaltar que este sub-proceso tiene profundo envolvimiento con seguridad, pues

��


varias acciones de continuidad están ligadas a los planes de contingencia, de recuperación y de reducción de riesgos.

Gerenciamento de la Disponibilidad

Es el sub-proceso que permite optimizar el uso de los recursos, anticipar y evaluar fallas e, implementar políticas de seguridad, a través de la monitoración permanente de los recursos de TIC, buscando así el cumplimiento de los acuerdos de niveles de servicio. Hacen parte del gerenciamiento de disponibilidad, cuestiones de Seguridad, Oficiosidad, Capacidad de Recuperación, Sustentabilidad y Resiliencia de los recursos de TIC.

Gerenciamento de Incidentes

Es el proceso responsable por registrar todo y cualquier evento que haya ocurrido que no hace parte del servicio contratado. En la mayoría de las veces son eventos conocidos y que interrumpen el servicio o, degradan su desempeño, siendo su objetivo el de restaurar el servicio lo más breve posible, minimizando los impactos negativos sobre los procesos de negocio con la disminución del tiempo perdido.

Gerenciamento de Problemas

Es el proceso responsable por tratar todos los registros de recursos de TIC que fallaron, analisando las causas raíces, recomendando alteraciones en los IC (Itenes de Configuración), adoptando medidas que empiezan su repetición. En esencia este proceso está vuelto para identificar, analizar el nivel de gravedad (severidad), adoptar acciones de solución, investigar y diagnosticar los problemas.

Gerenciamento de la Mudanza

Es el proceso responsable por el acompañamiento y planeamiento de toda y cualquier acción que suministre mudanzas en el ambiente de Red Local, disponibilizando técnicas para que sean utilizadas cuando de mudanzas autorizadas de forma que no incurran en fallas y creando procedimientos específicos para aquellas no autorizadas. Teniendo la competencia para autorizar, o no, mudanzas en el ambiente de TIC.

Gerenciamiento de la Configuración

Es el proceso responsable por mantener control rígido sobre todos activos, comprendiendo hardware, software, ambientes, circuitos, topología, procesos, scripts y, documentos de TIC. Su objetivo es suministrar informaciones confiables y actualizadas de todos los elementos en uso, garantiendo la sustentación y el relacionamiento con los demás procesos de TIC.

Gerenciamento del Nivel de Servicio

Es el proceso responsable por administrar la calidad y el cumplimiento de los Niveles de Servicio de TIC, tanto en los aspectos cuantitativos, cuanto cualitativos, garantiendo Acuerdos de Niveles de Servicio, agregando valor y dándoles conformidad al contrato.

��


23.1.5 Procedimientos, Actividades, Herramientas y Resultados de la Gerencia de la Red Local

Comprende el conjunto de acciones relacionadas con el Proceso de la Gerencia de Desempeño, responsable por garantir la Capacidad, Continuidad y Disponibilidad del servicio.

Capacidad

Este sub-proceso posibilita a el área de TIC, definir, monitorar y controlar la capacidad del servicio (switches y servidores), garantiendo que las cargas estén suficientemente dimensionadas para atender las necesidades de los clientes, en los niveles de servicio acordados. Del punto de la calidad es esencial observar la importancia de los servidores y de la red (LAN), pues estos son componentes vitales para el suceso del servicio. Las informaciones relacionadas a la capacidad son críticas para el atendimiento de nuevas demandas y servicios.

1. Actividades:

• Inventariar los recursos;

• Identificar los requisitos de los trabajos y demandas (esfuerzo/carga);

• Configurar el perfil del servicio (capacidad);

• Identificar los requisitos del perfil del servicio;

• Leer SNMP, RMONI, RMONII, MIB de los recursos monitorados;

• Encaminar resultado de las colectas para el banco correspondiente;

• Analizar desempeño de la capacidad;

• Generar relatos cuando del desvío del baseline definido;

• Enviar alerta/alarme al responsable por el recurso;

• Encaminar trap para abertura de ocurrencia de problema cuando constatado desvío;

• Informar la estructura (Gerentes, Gestores y técnicos envueltos) sobre el desempeño del recurso;

• Informar al usuario sobre el desempeño del recurso y el impacto en el ambiente;

• Proponer mejorías de servicio (capacidad);

• Desarrollar recomendaciones y especificaciones de compra y construcción (capacidad de servicios);

• Gerenciar las demandas de servicios y;

• Generar relatos.

2. Herramientas:

• Monitoramiento de los recursos – SIDE

• Colectores de la Capacidad - SIDE/MRTG

��


• Scripts, SNMP y MIB.

3. Resultados:

• Relato de la Capacidad de los Recursos de la Red

• Relato de evolución del consumo y de la capacidad de los recursos

• Relato Comparativo de utilización de los recursos (por demanda)

• Alertas/Alarmes de Capacidad

Continuidad

Este sub-proceso posibilita a el área de TIC, definir monitorar y controlar la continuidad de los servicios (switches y servidores), garantiendo que haya acompañamiento permanente de las interrupciones que afecten o puedan afectar los servicios, propiciando acciones alternativas para el restablecimiento de la continuidad del mismo, a través de Ítenes de Configuración alternativos o sustitutos.

1. Actividades


• Identificar los requisitos de continuidad de los servicios (contingencia/seguridad/confiabilidad);

• Configurar el perfil del servicio (continuidad);




• Analizar desempeño de la continuidad;




• Informar la estructura (Gerentes, Gestores y técnicos envueltos) sobre el desempeño del recurso;

• Informar usuario sobre el desempeño del recurso y el impacto en el ambiente;

• Proponer mejorías de servicio (continuidad);

• Desarrollar recomendaciones y especificaciones de compra y construcción (continuidad de servicios);

• Gerenciar las demandas de servicios y;


2. Herramientas:

• Monitoramiento de los recursos - SIDE;

��


• Colectores de la Continuidad - SIDE/MRTG e SIDE/NAGIOS;

• Scripts, SNMP e MIB.

3. Resultados:

• Relato del nivel de Continuidad de los Recursos de la Red;

• Relato de evolución de la Discontinuidad de los recursos;

• Relato Comparativo de utilización de los recursos (por demanda);

• Alertas/Alarmes de Continuidad.

Disponibilidad

Es el sub-proceso que permite optimizar el uso de los recursos, anticipar y evaluar fallas e, implementar políticas de seguridad, a través de la monitoración permanente de los recursos de TIC, revisando los planes cuando necesario de forma a buscar y obtener los resultados necesarios para garantir los acuerdos de niveles de servicio.

1. Actividades:


• Identificar los requisitos de confiabilidad y utilidad;

• Identificar los requisitos de contingencia;

• Configurar el perfil del servicio (disponibilidad);




• Analizar desempeño de la disponibilidad;

• Analizar los riesgos de disponibilidad de los servicios;




• Informar a la estructura (Gerentes, Gestores e técnicos envueltos) sobre o desempeño del recurso;

• Informar usuario sobre el desempeño del recurso y el impacto en el ambiente;

• Proponer mejorías de servicio (disponibilidad);

• Desarrollar recomendaciones y especificaciones de compra y construcción (disponibilidad);

• Gerenciar las demandas de servicios;

• Simular y revisar el plan de contingencia y;


2. Herramientas:

• Monitoramiento de los recursos - SIDE;

��


• Colectores de la Disponibilidad - SIDE/NAGIOS, SIDE/ICMP;

• Scripts, SNMP e MIB.

3. Resultados:

• Relato de la Disponibilidad de los Recursos de la Red

• Relato de evolución de la Disponibilidad de los recursos

• Relato Comparativo de Disponibilidad de los recursos (por demanda)

• Alertas/Alarmas de Disponibilidad

23.1.6 Funciones de la Gerencia de Redes Locales, Competencias y Requisitos

El Gerenciamento de Redes Locales tienen funciones especificas y bien definidas. Los profesionales que actúan en este segmento tienen características y particularidades muy propias, tanto del punto de vista del perfil, cuanto del punto de vista de las calificaciones y conocimientos.

Hacen parte de la Gerencia de Redes Locales los siguientes profesionales:

• Analista de Gerencia Central;

• Gestores Regionales de Gerenciamento;

• Analistas y Técnicos del Centro de Especialización y;

• Técnicos de la Torre de Control.

Analista da Gerencia Central

1. Competencias:

• Este profesional tiene la responsabilidad de analizar los problemas, comportamientos y tendencias de los recursos de red local, a partir de los resultados presentados por la solución de gerenciamiento - SIDE, o a través de otros datos colectados por herramientas/soluciones no automatizadas, proponiendo soluciones o encaminando para otros especialistas con su parecer sobre Capacidad, Continuidad y Disponibilidad.

2. Requisitos:

• Inglés Técnico;

• Facilidad de Comunicación;

• Experiencia comprobada de 03 años en administración, soporte o proyectos de Red Local;

• Profundo conocimiento de los protocolos de red (TCP/IP, RMON, RMONII, MIB, MIBII e SNMP);

• Conocimiento de la topología de la LAN y WAN.

3. Actividades:

��


• Identificar y entender los requisitos de los trabajos y demandas (esfuerzo/carga);

• Configurar el perfil de los servicios;


• Analizar el desempeño de la capacidad;


• Informar la estructura (gerente, gestores y técnicos envueltos) sobre el desempeño de los recursos;

• Proponer mejorías en el servicio (capacidad);

• Desarrollar recomendaciones para la compra y construcción recursos/soluciones (capacidad de los servicios);

• Gerenciar las demandas de los servicios y;


Gestores Regionales de Gerenciamento

1. Competencias:

• Son profesionales alocados en las Torres de Control, con competencia para acompañar los restablecimiento de los recursos, interagir con otros profesionales de la TC objetivando agilizar los procedimientos y generar relatos del ambiente, del punto de vista de la Capacidad, Continuidad y Disponibilidad, a partir de los resultados presentados por la solución de gerenciamento - SIDE.

2. Requisitos:

• Facilidad de comunicación;

• Nociones de administración de redes locales;

• Conocimiento de la topología de la LAN y WAN;

• Conocimiento de los procesos de gerenciamiento de TI;

• Perfil de Líder y;

• Capacidad de planear y organizar

3. Actividades:

• Monitorar diariamente la disponibilidad de las redes en el sistema de desempeño;

• Monitorar diariamente la disponibilidad de las informaciones de los recursos bajo su gestión;

• Analizar diariamente la coherencia de los datos publicados;

• Accionar los gestores de la solución de GERENCIAMENTO (SIDE), a través de ticket ARS/REMEDY, cuando identificada cualquier anormalidad en la disponibilidad de las informaciones y coherencia de las mismas;

• Analizar mensualmente el desempeño de las redes y recursos bajo su gestión;

• Generar relatos mensuales cuando de las ocurrencias y desvíos de los recursos sobre su gestión;

��


• Generar relatos mensuales conteniendo evaluación individualizada del desempeño de las redes locales de su región, para posicionamiento de los Clientes, Coordinadores, Superintendente y TIGER;

• Informar la estructura (gerentes, gestores y técnicos envueltos) sobre el desempeño de los recursos;

• Proponer mejorías en el servicio cuanto a la capacidad, disponibilidad y continuidad;

• Registrar usuarios regionales en el SIDE, conforme perfil y competencia;

• Auditar la base de configuración (SICO y REMEDY) con relación a las informaciones de losrecursos monitorados.

Analistas y Técnicos del Centro de Especialización

1. Competencias:

• Estos profesionales tienen la competencia de prospectar y estudiar soluciones de gerenciamiento más adecuadas a las necesidades de la empresa y de los processos implantados. Analizar y construir herramientas y procedimientos para gerenciamiento. Actuar como 3o nivel de recorrencia en lo que concierne a los problemas de gerenciamiento, en el uso de estas herramientas y, en contacto con los suministradores;

2. Requisitos:

• Inglés Técnico

• Facilidad de Comunicación

• Experiencia comprobada de 03 años en administración, soporte o proyectos de Red Local.

• Profundo conocimiento de los protocolos de red (TCP/IP, RMON, RMONII, MIB, MIBII e SNMP)

• Conocimiento de la topología de la LAN y WAN.

3. Actividades:

• Prospectar y estudiar soluciones de gerenciamiento;

• Construir soluciones/scripts de gerenciamiento objetivando dar eficiencia y eficacia al proceso;

• Apoyar Analista de la Gerencia Central en la identificación y entendimiento de los requisitos de los trabajos y demandas (esfuerzo/carga);

• Estudiar los requisitos del perfil del servicio. Estudiar y proponer mejor configuración para el perfil del servicio;

• Apoyar Analista de la Gerencia Central en la análisis del desempeño de la capacidad;

• Apoyar Analista de la Gerencia Central en la generación de los relatos cuando del desvío del baseline definido;

• Proponer mejorías en el servicio (capacidad), cuando detectada alguna irregularidad;

��


• Desarrollar recomendaciones y especificaciones de compra y construcción (capacidad de servicios).

Técnicos de Torre de Control

1. Competencias:

• Los profesionales alocados en las Torres de Control, del punto de vista de Gerenciamento, serán responsables por el 1o nivel de atendimiento y restauración de los recursos de la Red Local, minimizando así las interrupciones de los servicios.

2. Requisitos:

• Nociones de Inglés Técnico;

• Facilidad de Comunicación;

• Iniciativa;

• Pró-activo;

• Experiencia comprobada de 02 años en administración de red local, soporte, y proyecto de redes;

• Conocimiento de los sistemas de gestión (SIDE, SICO y REMEDY);

• Conocimiento de los protocolos de red (TCP/IP e SNMP) y;

• Conocimiento de topología de la LAN y WAN.

3. Actividades:

• Monitorar los recursos apuntados como indisponibles en el mapa de gerenciamiento;

• Identificar los incidentes provenientes de la monitoración y tomar acciones inmediatas para la recuperación de los recursos;

• Contactar soporte de 2o nivel buscando auxilio para resoluciones del incidente;

• Instalar scripts de gerenciamiento bajo demandado TIGER/SUPTI;

• Configurar recursos monitorados y de monitoración conforme orientación del TIGER/SUPTI y;

• Informar usuarios y Gestor Regional sobre la indisponibilidad y la expectativa de resolución del incidente, así como cuando haya retorno de la disponibilidad del recurso, alimentando el sistema de work ow (REMEDY) de estas ocurrencias.

��


CAPÍTULO 24

ITI – Instituto Nacional de Tecnología de Información

Institución: ITI – Instituto Nacional de Tecnología de Información

Sitio: www.iti.br

Caso: Migración de Red local (servidores y estaciones de trabajo)

responsable: Jean Carlo Rodrigues

[email protected]

Palabras-Llave: Correo Electrónico, Estación de Trabajo, Red Local, Servicios de Red, Servidores, Sistemas Legados, Software Libre, software Propietario

24.1 Migración de Red Local – servidores y estaciones de trabajo

24.1.1 Contexto – ITI y la adopción del SL

El Instituto Nacional de Tecnología de la Información – ITI tiene el desafío de ofrecer a la sociedad brasileña un sistema de certificación digital estable y confiable que dé mayor seguridad a las informaciones que trafican en las redes de computadores.

El ITI es una autarquía vinculada a la Casa Civil de la Presidencia de la República, con la atribución de mantener plenamente operacional y confiable la Infraestructura de Llaves Públicas (PKI, en inglés) Brasileña – ICP-Brasil. Desde 2001, con la edición de la MP 2200-2, de 24 de agosto de 2001, el ITI Es la Autoridad Certificadora Raíz de la ICP-Brasil y trabaja para aplicar y hacer cumplir las normas que rigen toda la cadena del sistema nacional de certificación digital.

Desafío Inicial – Red Local Propietaria

Comenzar utilizando programas de código abierto en su propia red es ejemplo para mostrar que la auditabilidad plena es requisito fundamental para conocer, auditar y operar redes de computadoras. Adicionalmente se resuelven problemas como la falta de licenciamiento para determinados programas y economía con relación a las constantes renovaciones de esas licencias.

La red instalada en el ITI - Red-ITI, en enero de 2003, era integralmente dotada de programas propietarios, a través de topología barramento, siendo considerada como estaciones de trabajo de la red de la Presidencia de la República - Red-PR y teniendo todos sus servidores compartidos con los demás segmentos de la Red-PR.

Desafio Estructural – Plataforma Criptográfica Propietaria

Más importante que mudar sólo las estaciones clientes y los programas más conocidos fue la determinación del Comité Gestor de la ICP-Brasil de dar al ITI la responsabilidad de coordinar el desenvolvimiento de un módulo criptográfico (software y hardware) con tecnología nacional para la emisión, guarda y gerenciamento de la Autoridad Certificadora Raíz (AC). La plataforma que viabiliza actualmente la cadena de certificación brasileña (ICP-Brasil) fue

��


producida por empresa extranjera utilizando tecnología cerrada, sin la posibilidad de transferencia de ese conocimiento para el ITI o para empresas nacionales. Con la producción de la plataforma en el país, será posible su gerenciamento, el dominio de la tecnología y auditoria del proceso, elevando substancialmente la seguridad de la cadena de certificación en Brasil.

24.1.2 Etapas – Plan Estratégico de Migración Aunque no tenga seguido originalmente e integralmente ningún guía de migración, la

experiencia y vivencia de los profesionales de TI responsables por la red migrada, determinó un itinerario adherente y compatible a los procesos de migración para cualquier red de computadoras que necessite de alteración de camadas de aplicativos.

Las dificultades eran mayores que las inicialmente esperadas, así fueron detallados los pormenores para la reducción del riesgo inherente a proyectos de esta naturaleza, de forma a tratarlos, identificando y encaminando las soluciones adecuadas.

Siendo así, la migración del ITI se dio en etapas con el objetivo de sustituir todos los programas instalados en las estaciones de trabajo (desktops) y mantener el acceso a sistemas legados y software propietario. Un diagrama esquemático de la migración es presentado en la Figura 24.1

Etapa 1 – Levantamiento

Esta etapa consistió en el levantamiento y documentación detallados de la red local del ITI, además de la descripción y determinación del perfil básico de los usuarios para delimitación de configuración padrón de software básico a ser sustituído. Fue necesaria a la identificación de las rutinas que deberían ser mantenidas en función de los sistemas legados. Este levantamiento, que incluye hardware disponible, fue la base para el proyecto de mudanza de los servidores y necesidad de redimensionamiento y topología de la estructura de red de datos local (segmento de red ITI) y de conexiones con la red de la Presidencia de la República, ambiente en la cual la red del ITI estaba inserida.

��


Figura 24.1: Diagrama esquemático de migración

Etapa 2 – Capacitación de los Técnicos

La segunda etapa fue la de capacitación del personal técnico que promovió la migración y prestó el soporte necesario al proceso. Fue necesario formar un grupo de especialistas tanto en programas propietarios como en abiertos, que conociesen profundamente las diferencias entre las tecnologías, para que pudiesen identificar los mejores caminos de la migración, además de proporcionar el soporte adecuado a los usuarios. Fueron estudiadas diversas herramientas y programas fundamentales, enumerados en la Figura 24.2.

��


Figura 24.2: Comparativo de herramientas

Etapa 3 – Sustitución en la Infraestructura de Red

Después de la capacitación de los técnicos se puede trabajar en la sustitución de los programas propietarios, como por ejemplo, software básico en servicios de red en uso en los servidores. Tal estratégia tuvo sentido para que cuando las mudanzas ocurriesen en las estaciones de trabajo, todas las compatibilidades ya estuviesen previstas e interrupciones y fallas en los servidores no fuesen albo de problemas en la migración.

En caso específico de la migración del ITI, la complejidad fue mayor, pues los servicios no fueron simplemente migrados. Hubo la necesidad de instalación de software libre e implementación de nuevos servicios en la red local compatibles con los servicios de la Red-PR (ver Figura 24.2 ). Como ejemplo, se puede citar el servidor de correo electrónico, que mismo alterado mantuvo compatibilidad y acceso con el servidor de correo electrónico de la Red-PR. L elección sobre la distribución, aunque no sea fundamental ni la principal, fue hecha y permitió incluso la posibilidad de mudarse de distribución durante el proceso de migración sin que el usuario final no sintiera diferencia cuanto a la distribución elegida o la que está en uso.

Etapa 4 – Sensibilización y Capacitación de Usuarios

El suceso de una migración depende de la aceptación y de la disposición de los usuarios para utilizar el nuevo ambiente es, también, del comprometimiento de los dirigentes del órgano para patrocinar la mudanza. En el ITI, las primeras estaciones de trabajo a recibir aplicativos en código abierto fueron la del director-presidente y la de los directores. En razón del reducido número de usuarios envueltos en la época se realizaron dos reuniones de sensibilización con el objetivo de mostrar la importancia de la mudanza y el porqué de su realización. Un documento con la exposición de motivos fue todavía divulgado entre los servidores para reducir el temor con relación a las mudanzas, demostrando la similaridad y la facilidad de uso de la plataforma libre con relación a la propietaria. Adicionalmente, notas técnicas

��


fueron publicadas visando esclarecer y orientar cuanto a la utilización de formatos de archivos aplicables al software abierto y los formatos exclusivos de programas propietarios.

Figura 24.3: Distribuciones Linux

Etapa 5 – Migración de las Estaciones de Trabajo

Después de superada la migración de los servidores y realizadas las adaptaciones criteriosas de las herramientas que serán colocadas en los servidores, se puede sustituir, con ventajas en calidad y cantidad, a las herramientas de las estaciones de trabajo. En redes corporativas, un detalle importante es la elección y el montaje de un padrón de software a ser colocado en la red local. No es recomendable dejar por cuenta de cada usuario la elección del paquete padrón de migración. Es posible que usuarios más avanzados hagan elección diferenciada. Entonces, es necesario dejar claro que el uso y la manutención de herramientas para las cuales los técnicos de soporte no fueron calificados es de responsabilidad del propio usuario. No observando este detalle causará pierda de control de los técnicos sobre las versiones y releases de las herramientas instaladas en la red. Cuanto mayor la red mayores serán los problemas decurrientes de la inobservancia de este ítem. La elección de aplicativos se dio en función de estudios comparativos de programas disponibles para sistema operacional de código abierto y sistema operacional de código propietario, conforme ejemplos presentados en la Figura 24.5.

Algunos pré-requisitos fueron considerados para realizar la migración de las estaciones de trabajo del ITI. El idioma utilizado debería ser el portugués del Brasil, el menú de las interfaces gráficas debería tener el menor impacto de alteración, el ambiente gráfico debería mantenerse integrado, la suite para oficina debería ser equivalente o compatible con el Microsoft Office ® y el cliente de correo electrónico debería ser gráficamente parecido con el cliente en uso (en el caso se adoptó el Ximian Evolution). El sistema operacional debería permitir la personalización padronizada para el ambiente de red en cuestión, además de posibilitar la actualización remota de las estaciones de trabajo a partir de servidor local.

��


Figura 24.4: Elección de aplicativos

Etapa 6 – Legados y Excepciones

Después las migraciones de servidores y estaciones de trabajo, todavía restaron algunos usuarios que no encontraron herramientas en software libre compatibles a las actividades que ellos realizaban o la necesidad de programas y sistemas legados que poseian protocolos propietários que no admitian interoperabilidad. La opción fue la de mantener esos servicios como excepción en la Red-ITI y la de utiliza la Rdesktop como herramienta para la manutención, de forma temporaria, a ser eliminada a la medida en que los programas incompatibles fuesen adquiriendo integración con la nueva plataforma.

La mayoría de los sistemas que exigieron tal procedimiento son sistemas estructurantes y mantenidos por el Serpro siendo ejecutados, en su mayoría, en el mainframe IBM. Algunas otras funciones y sistemas fueron adaptados con conectores que pasaron a reconocer los navegadores y otros programas de código abierto.

Etapa 7 – Proveimiento de Seguridad

Durante todas las etapas, el proceso de migración de la Red-ITI exigió la verificación y el aprimoramiento de los niveles de seguridad de una red local. Situaciones que pasan desapercibidas como definición de nombres y direcciones de red, definición de prerrogativas de acceso al sitios Web, entre otras, llevaron el ITI a rever varios procedimientos que eran usados por la Red-PR. Fue necesario negociar las alteraciones, mismo quedando evidente que los procedimientos adoptados en la Red-ITI daban mayor seguridad, transparencia, flexibilidad e interoperabilidad a la red.

24.1.3 Detalles – Migración de la Red-ITI Proyectada inicialmente para ser migrada en 90 (noventa) días, a la Red-ITI llevó cerca

de 140 (ciento cuarenta) días para ser concluida, considerando casi 50 estaciones de trabajo (desktops) y 10 notebooks La migración fue concluida en agosto de 2003.

��


Como destaque se puede citar que durante ese período fueron efectivadas licitaciones para aquisición de hardware (desktops y notebooks), sin sistema operacional instalado, reduciendo los costos de adquisición y permitiendo la interoperabilidad de los equipos en la Red-ITI. Al final del plazo de migración a la red ya poseía en torno de 70 (setenta) equipos entre servidores, desktops y notebooks, además de otros equipos de red adquiridos para mantener la conectividad e interoperabilidad con la Red-PR y Web.

Para operacionalizar la migración de la Red ITI fue creada una tabla de actividades esenciales y una pequeña red de precedencia(s) y resultado(s) de cada una de las actividades, compuesta de:

Actividad Precedencia Pendencias Resultado/ producto Responsable

Donde:

• Actividad - Etapa a ser cumplida conforme relación a seguir y compatible con el Plan Estratégico de Migración ya descrito.

• Precedencia - Mapeamiento de las actividades que deben anteceder otras.

• Pendencias - Relacionamiento de pendencias y actividades fuera del guión de migración (ejemplo licitación de hardware).

• Resultado/producto - Relación de productos que serán obtenidos o construidos después la actividad.

• Responsable - Nombre de la persona o equipo responsable por la actividad. Las actividades realizadas en la migración de la Red-ITI fueron:

Actividades

1. Levantamiento de Equipamientos y Red

• Topología de Red

• Tecnología de Red

• Servicios de Red

2. Levantamiento do Perfil dos Usuarios (Programas y Equipamientos)

• Programas de oficina utilizados

• Programas exclusivos utilizados

• Programas en estaciones

• Programas en servidores

• Equipamientos disponibles

3. Adaptación y Remodelación de Servicios de Red

• Servicio de sincronismo de tiempo (NTP)

• . Servicio de Correo (Mensajera)

• Servicio de Agenda

• Servicio de Noticias

��


• Servicio de Áudio

• Servicio de Imagen

• Servicio de Resolución de Nombres (DNS/WINS)

• Servicio de Conexión Mainframe (SNA)

• Servicio de Conexión Legado (Rdesktop)

• Servicio de Directorio (LDAP) 11. Servicio de SGBD

• Servicio de Impresión

• Servicio de Cache/Proxy

• Servicio de Hospedaje de Página Web (HTTP)

• Servicio de Transferencia de Archivos (FTP)

• Servicio de Seguridad - Filtros (Firewall)

• Servicio de Seguridad - Anti-Virus

• Servicio de Configuración de Estaciones de Trabajo en la Red (DHCP)

4. Capacitación de los profesionales de soporte a las nuevas herramientas y aplicaciones

• Sensibilización de técnicos y profesionales de apoyo

• Capacitación Gnu-Linux

• Capacitación Servicios de Red

• Capacitación Soporte a Herramientas de Oficina

5. Revisión de los Servicios y Topología de la Red-ITI

• Operacionalización Servicios de Red Anterior/Actual

• Ajuste de los Servicios de Red

6. Capacitación de los usuarios en las mudanzas de las herramientas de oficina

• Sensibilización de usuarios de servicios de red

• Capacitación diferencias ambiente operacional

• Capacitación diferencias herramientas de oficinas

7. Ajuste del uso de programas propietarios con estaciones con programas abiertos

• Sustitución de los programas de oficina de las estaciones de trabajo

• Ajuste de los programas de la estación de trabajo

8. Estabilización del Funcionamiento de las Estaciones de Trabajo

9. Implementación de Certificación Digital en los Sistemas Internos de Red

10. Implementación de Certificación Digital en los Sistemas Externos de Red

��


24.1.4 Solución Web – Sitio www.iti.br y Twiki PKI-enable El proyecto de construcción del portal del ITI se inició con el desenvolvimiento, en 2003,

del sitio que hace uso de la herramienta Twiki PKI-Enable. Aunque todavía esté en pleno desenvolvimiento y mejoría, desde el inicio permitió la administración on-line del contenido y la habilitación del sitio para uso de certificado digital de la ICP-Brasil, en sustitución a tradicionales sistemas de identificación y autenticación. Fueron adoptados el sistema operacional Solaris ® y el servidor web Apache.

El ITI mantiene todavía el sitio www.iti.gov.br, hospedado en el Serpro, en plataforma propietaria que tiene como custión básica la alta disponibilidad (99,99% del tiempo), por determinación legal, para consulta de la lista de los certificados revocados (LCR) por las Autoridades Certificadoras vinculadas a la ICP-Brasil. El referido sitio no permitía todas las funciones con navegadores de código abierto y actualmente está compatible con estos navegadores.

Ejemplo - Migración de archivos digitales legado de herramientas propietarias

Los archivos digitales creados y manoseados bajo las especificaciones técnicas del MicrosoftOffice ® eran utilizados para componer documentos, planillas y presentaciones en el ITI. Para efectuar la migración de archivos digitales de formato propietario para libre, manteniéndose accesibles, fue adoptado el OpenOffice que es una suite LIBRE. Ese paquete trabaja con diversos formatos de archivos de forma transparente, incluso con el Microsoft Office y posee procesador de texto, planilla de cálculos, editor HTML, editor vectorial y editor de presentación.

Constatándose el problema de la existencia de diversos padrones de formato de documentos, hubo la necesidad de utilizarse un conversor automático de formatos.

Figura 24.5: Comparativo entre extensiones de archivo

Durante el proceso fueron repasadas las siguientes orientaciones a los usuarios:

1. Críe un directorio denominado Documentos-MS en la raíz de su usuario.

2. En el OpenOffice abra el archivo deseado y sálvelo con (Archivo -> Guardar Como) el mismo nombre, pero, con la extensión (Tipo de Archivo: Microsoft Word 97/2000/XP) en el directorio creado anteriormente.

3. Envíe el documento en el formato inmediatamente salvo.

4. Apague el documento salvo en el directorio denominado Documentos-MS. No es necesario ser mantenido en su desktop dentro del directorio arriba, pues el OpenOffice podrá generar de nuevo a cualquier tiempo una nueva copia, caso sea

��


necesario. Eso significa que usted pudo apagar todos los archivos de este directorio, con el objetivo de evitar la edición de los mismos en tal formato, pues acarreará pierda de formatación.

Además de las siguiente recomendaciones:

1. Cuando necesite editar un documento ya existente nunca haga la edición directa de un archivo .RTF, .DOC, .XLS o .PPS, pues a pesar del OpenOffice editar, alguna formatación puede ser perdida en la grabación. En los testes realizados verificamos que al cerrar el archivo salvo en formato propietario y abrir de nuevo tanto en el OpenOffice como en el Word/Excell/PowerPoint algunas formataciones son perdidas nos dando la recomendación de que el OpenOffice todavía no suporta 100% tales formatos de archivos para grabación.

2. El directorio Documentos-MS sólo debe ser utilizado para grabar los archivos que serán transferidos y/o copiados para redes externas.

24.2 Resultados - Atendiendo a las Expectativas La construcción de una nueva red en software libre es más fácil y rápida de que la

migración de redes y sub-redes en funcionamiento con software propietario para software libre. La opción adoptada por el ITI fue la de integración de la Red-ITI con la Red-PR, tornándola un ejemplo claro de la posibilidad de convivencia de redes locales heterogéneas.

Se consideró todavía que la migración de Red-ITI con total conectividad a la Red-PR fue una demostración de como obtener expresiva reducción en los costos de manutención y de operación, resaltados por la eliminación de los gastos con licencias de software de servidores y de estaciones de trabajo.

Un cuadro resumo de la migración efectuada es presentado en la Tabla 24.1 (recordando que cada caso se torna diferente de los demás, por tener red con topología y tecnología específicas y costos diferenciados):

Además de esas ventajas, se debe destacar el aumento del nivel de seguridad. La sub-red del ITI se consistió en la unión más fuerte de toda la Red-PR. Entre los usuarios finales hubo la desmitificación del software libre, la diseminación de esa tecnología y la conquista de nuevos adeptos.

24.2.1 Referencias - Bibliografía y Consultas Un grande diferencial en la migración de ambientes integralmente en software propietario

para ambientes totalmente en software libre es que en ciertos documentos técnicos todavía consiste en diseminación del miedo, duda y el incierto, a través de papers y documentos contradictorios, puede ser comprobado por el ITI en su migración de Red-ITI. El soporte y las consultorías recibidos para la migración integral de la Red fueron los mínimos y, en la mayoría de los casos, provocados por la incompatibilidad de los programas propietarios en recibir y tratar archivos de formatos abiertos (lo que no acontece en el caso inverso). La consulta a libros y revistas especializadas (a partir de la adquisición de literatura por el ITI para formación de biblioteca específica para servicios que utilizan programas de código abierto) fue basilar para la capacitación de los técnicos responsables por la migración. El soporte obtenido en las redes de relacionamiento en la Web también fue determinante para la agilidad del proceso. Un ejemplo claro fue tardar en obtener soporte para un sistema operacional

��


propietario que tardó ocho veces más de que el montaje del mismo servicio completo en software libre.

Tabla 24.1: Resumo de migraciones efectuadas

Servicio/Padrón Condiciones Generales Costos Aproximados

Sistema Operacional con aplicación en servicios de red.

Exige hardware más potente con software propietario y flexibiliza el hardware con sistemas operacionales libres padrón Gnu/Linux.

Economía de Licencias de Uso y diminución de costo unitario de los servidores (HW con arquitectura CISC al envés de equipamientos con arquitectura RISC) con aprovechamiento de un mismo servidor para servicios diferentes. Economía en la Red ITI de aproximadamente R$400.000,00.

Software Básico en estaciones de trabajo como Herramienta Office.

Exigen hardware mínimo en aplica -ciones cliente-servidor y licenciamiento por estaciones de trabajo cuando usado con software propietario. No exige renovación de licencias con software libre. Se observa que la ca

pacitación de las diferencias de softwarelibre y software propietario son más

concisas y de costo menor de que entrenamientos completos como si los usuarios estuviesen aprendiendo el uso de una nueva herramienta.

Economía y ampliación del tiempo útil de uso del HW. Liberación de periféricos utilizados en el desktop en función de la mudanza del perfil de uso de servicios en red (audio, grabación de datos, backup etc.). Sustitución de renovación de licencias. Economía en la Red-ITI de aproximadamente R$80.000,00 (para 50 estaciones y notebooks).

Adquisición de nuevos desktops y notebooks

Acompañamiento de licencias de uso con software propietario. Adquisición sin software instalado.

Economía en las licitaciones con equipa mientos (desktops y notebooks) con periféricos con mejor calidad y capacidad en sustitución a las licencias embutidas. La economía, en terminos financieros, no fue significativa, pero en termos de recursos de los equipamientos adquiridos (como memoria y almacenamiento) fueron sensibles

��


24.2.2 Conclusiones - Experiencia Adquirida y Recomendaciones

Se puede imaginar que los responsables por la migración de la Red-ITI recomendarían o colocarían a disposición de los interesados las herramientas y el trabajo realizado, para que fuesen reproducidos en las redes de otras organizaciones, sean ellas del sector público, privado o tercero sector.

Entendemos que la experiencia adquirida no recomienda tal posicionamiento y lo que podemos colocar a disposición, después de una corta pero ardua jornada de migración, es la fuerte recomendación de que la mayor preocupación del responsable por la migración sea la etapa de planeamiento y el reconocimiento completo y detallado del ambiente de red o de sub-red, con sus respectivos servicios en uso y los servicios reprimidos por la falta de calidad e el uso de redes propietarias.

Lo que queda es la seguridad de que tener un Guía para apoyarse en el planeamiento de migración y la comprensión y apoyo de los usuarios para las mudanzas que ocurrieron son factores esenciales para el suceso de un proyecto de esta naturaleza, a ejemplo del ocurrido en la Red-ITI. Por lo tanto registramos aquí agradecimientos a los usuarios de la Red-ITI por la comprensión de eventuales atrasos en la resolución de problemas, a veces triviales, y por las diferencias de configuración hasta obtenerse un padrón para el ambiente. Sin esos usuarios compreensivos no conquistaríamos los objetivos en el corto plazo de mudanzas.

��


APENDICES

��


APENDICE A REFERENCIA DE SOFTWARE LIBRE

Abajo es mostrado el listado de referencia de soluciones de software libre apresentadas en este documento fecha de referencia: 20/09/2004

��


��


��


��


APÉNDICE B MARCAS REGISTRADAS

Fueron utilizadas marcas registradas en este documento con el propósito de identificación. El equipo de elaboración del Guía Libre reconoce la propiedad de esas marcas registradas, conforme demostrado en la Tabla E.

Caso usted crea que su marca fue utilizada sin la debida referencia de propiedad, por favor, encamine un mensaje para: [email protected] para que el equipo pueda regularizar la situación en las próximas versiones del documento.

��


��


APÉNDICE C - W I N E – HISTÓRICO

Wine significa "Wine Is Not an Emulator", y si puede encontrar detalles completos en http://www.winehq.com.

La historia del Wine comienza por vuelta de 1993, cuando diversas fuerzas convergían en busca de hacer posible la ejecución de aplicativos Windows ® . En la ocasión, la Microsoft había conseguido, al lanzar el Windows ® , un gran suceso en el mercado de computadoras personales. La IBM creía que el OS/2 sería un concurriente a la altura y que "vencería" la disputa, pero reconocía que la "sobrevivencia"de su sistema dependía fuertemente de la capacidad de este ejecutar aplicativos desarrollados para Windows ® , y se vio obligada a investir en esa posibilidad. En esta misma época, el mundo comenzó a presenciar el surgimiento de sistemas operacionales multiusarios/multitareas de código libre para la utilización en computadoras personales (PCs).

La Sun, después de adquirir la Praxys, en septiembre de 1992, condujo el desarrollo de un producto conocido como Wabi. En 1993, la Sun demostró el producto en una conferencia de desarrolladores del Solaris, este producto permitía que usuarios del Solaris x86 y del Solaris 2.2/SPARC utilizasen los aplicativos para MS Windows ® . La gran innovación del Wabi, fue posibilitar que las llamadas gráficas de Windows ® (ie. renderización de ventanas) fuesen traducidas diretacmente para llamadas do X-Window. Emulando el resto de las instrucciones x86 era posible ejecutar los aplicativos Windows ® de forma más rápida en la arquitectura RISC. Otra grande innovación de Wabi incluía la habilidad de manipular fuentes True Type (fuentes Bitstream’s).

En junio de 1993, los usuarios de GNU/Linux comenzaron a vislumbrar la posibilidad de desarrollar algo parecido. En la ocasión la posibilidad de Wabi ser portado para el GNU/Linux era mínima o ninguna. Una lista de discusiones fue creada para facilitar la integración de los desarrolladores El nombre Wine fue rápidamente adoptado. El grupo inicial de colaboradores incluía algunos de los primeros "hackers"del kernel de GNU/Linux, incluyendo Eric Youngdale y David Metcalfe, además de Alexandre Julliard (que, actualmente, hace el gerenciamento del proyecto) y Miguel de Icaza (famoso por el GNOME). Bob Amstadt dirigió el desarrollo.

El trabajo inicial consistía en crear un cargador de programas (program loader) que per-mitiera trabajar con programas binarios de 16 bits de Windows ® . Inicialmente, las llamadas gráficas de Windows ® eran mapeadas para llamada en Tcl/Tk.

En 1994, el proyecto pasó por una reformulación, ya existían versiones de Wine para otros sistemas UnixLike (NetBSD, etc), y la parte de ventanas pasó a ser reescrito usando llamadas de Xlib.

En 1995, fueron relatados sucesos en la ejecución de diversos aplicativos en el Wine, destacandose, entre ellos, el MS Word y el MS Excel. Todavía en 1995 con el anuncio, por la Microsoft, de su nuevo sistema de 32 bits, los desarrolladores del Wine pasaron a desarrollar el soporte para nuevas llamadas de 32 bits y para nuevas características, tales como Registro, mecanismos para conexión de red, etc.

Fueron creadas técnicas para identificación de las llamadas al sistema operacional realizadas por el programa a ser emulado. En mayor parte de los casos, el desarrollo de un pequeño número de códigos habilitaba un aplicativo a ser ejecutado. Se Descubrió que los programas frecuentemente se preparan para llamar una interface particular, pero de hecho no hacen la llamada. Entonces fue escrito un código para permitir que los programas continuasen a hacer esas llamadas preparatorias, sin que hubiese errores inmediatos y códigos para dar soporte a las llamadas verdaderas también fueron escritas en esa ocasión.

��


El primer uso comercial de Wine fue por el Corel, que trabajó bastante en el soporte del Wine, y lo usó para producir una versión nativa GNU/Linux del Wordperfect 8. A partir de eso, otras compañías pasaron a usar el Wine para producir versiones GNU/Linux de sus productos y mudanzas para software libre. Uno de los últimos casos es el Xilinx, que produce paquetes CAD electrónicos especialistas. El proyecto Ximian Mono también hizo uso del Wine para permitir que aplicativos.NET escritos para Windows ® trabajen sin ser reescritos. Vea http://appde.winehq.con para detalles sobre el nivel de soporte para varios aplicativos.

Recientemente, un equipo de desarrolladores de aplicativos Windows ® experiente comenzó a producir un conjunto de programas-teste para verificar, sistemáticamente, las 12.000 llamadas de sistema actuales en la biblioteca del Windows ® .

En la actualidad, el Wine alcanza más de 1.200.000 líneas de código "C"realizando cerca de 90% de las llamadas en especificaciones populares del Windows ® , como ECMA-234 y Open32. Las llamadas no documentadas públicamente son más difíciles de implementar, pero hay progresos en esa área.

Algunas compañías, entre las cuales se destacan TransGaming Technologies y Code Weavers, que trabajan con el Wine, desarrollan códigos para funciones particulares (como, por ejemplo, juegos y soporte a la Suite Office, que inicialmente son propietarias). Ellas lo hacen para financiar a si, mientras realizan su trabajo en el proyecto principal. Y mueven su código para el proyecto principal cuando obtiene una fuente de receta alternativa conveniente.

��


APÉNDICE D - SISTEMAS DE CORREO

Este apéndice detalla sistemas de correo en general, porque la abarcancia de los productos de correo software libre puede, a veces, ser confusa y la terminología usada ni siempre es clara.

El Modelo de Correo de la Internet es basado en varios componentes lógicos, cada uno de los cuales tiene un trabajo específico para hacer, y se comunica con los otros a través del uso de protocolos abiertos. Este es el modelo usado por los sistemas software libre. El modelo puede ser mejor descripto con la ayuda de algunos diagramas.

Figura B.1: Como Funciona el Correo Electrónico

Este diagrama muestra el camino para la entrega de una correspondencia simple. La correspondencia es generada por un Agente Usuario de Correo (Mail User Agent/ MUA) . Después es pasado para un servidor de correo, que tiene que resolver si puede entregar la correspondencia localmente o si la correspondencia debe ser pasada para otro servidor. La correspondencia es pasada de servidor en servidor, hasta que uno de ellos decida que puede entregar la correspondencia localmente, y lo hace entonces. Cuando esa entrega esté completa, la correspondencia estará disponible para que un MUA la lea. El MUA final tiene la responsabilidad de recuperar la correspondencia, bien como de pasarla para una Interface Usuario de Correo (MUI), para exhibirla para el usuario.

��


Figura B.2: Servidor de Correo Electrónico

De que forma cada servidor de correo decide entregar la correspondencia localmente o no, podría ser asunto para un otro capítulo. En síntesis, cada servidor consulta uno o varios archi-vos de configuración local, junto con información de servidores DNS (principalmente los registros MX). Todo eso es usado entonces para decidir lo que es considerado local. Para la correspondencia no local, el servidor usa la información para determinar la dirección del próximo servidor de correo al cual se debe mandar la correspondencia.

Cada servidor de correo tiene, en general, la estructura mostrada en la B.2.

El Agente de Transporte de Correo (Mail Transport Agent/ MTA) acepta conexiones de o-tros servidores de correo y MUAs vía Protocolo de Transporte de Correo Simple (Simple Mail Transport Protocol/ SMTP). Caso la correspondencia no sea para entrega local, es entonces enviada a otro servidor por el MTA. Si la correspondencia es para entrega local, ella es pasada para un Agente de Entrega de Correo (Mail Delivery Agent/ MDA). El MDA es responsable por almace-nar la correspondencia en la caja de correo del usuario. La caja de correo es simplemente una forma de almacenar datos, por ejemplo, un archivo, una serie de archivos separados o hasta un banco de datos SQL. La estructura de almacenamiento necesario es definida por aquello que el MDA soporta. Cuando un usuario desea ver su correspondencia, él usa un MUA que recupera la correspondencia directamente o entra en contacto con un componente del servidor, que recupera la correspondencia de la caja de correo y pasa para el MUA. Tales componentes del servidor no se encajan en el modelo tradicional MTA/MDA/MUA y nosotros los llamaremos de Agentes de Acceso al Correo (Mail Access Agents/ MAA). Este término, sin embargo, no es de uso corriente.

El MUA se comunica con un MAA usando un protocolo abierto, que usualmente es el Protocolo de Correo (Post Office Protocol/ POP), o el Protocolo de Acceso al Correo Internet (Internet Mail Access Protocol/IMAP). El protocolo POP normalmente apaga correspondencias de caja de correo cuando estas son pasadas al cliente y el IMAP normalmente las deja allá. El protocolo IMAP también permite que el MUA altere la caja de correo, por ejemplo, apagando correspondencia o moviéndola de un directorio para otro.

El MUA puede almacenar correo localmente, en la máquina donde está trabajando. Eso ocurre normalmente cuando el POP es usado. Ese almacenamiento local entonces permite que el acceso futuro sea independiente del servidor, que es particularmente útil para máquinas que no son permanentemente conectadas a la red. Por otro lado, el IMAP normalmente opera sin copias locales, pero también puede operar en lo que llamamos de modo desconectado, que mantiene una copia local, permitindo al correo ser manipulado sin una conexión de red. En ese modo, las cajas de correo local y del servidor están sincronizadas cuando es hecha una conexión de red. Infelizmente, ni todos los MUAs soportan completamente el IMAP desconectado.

Algunas veces, un programa diferente de un MUA recupera la correspondencia y la almacena localmente para un MUA, sin tener que conectarse al servidor. Tales programas traen correo para esas máquinas, en contraste con un MTA padrón, para lo cual el correo es empujado por otros MTAs. Eso puede ser útil si los usuarios no desean permitir conexiones de la Internet con sus máquinas, o estén operando por trás de una firewall. Un ejemplo de tal programa es el fetchmail.

La dificultad con ese modelo es que los aplicativos disponibles no se organizan directamente para él. Los aplicativos, muy frecuentemente, hacen más que una de las funciones; por ejemplo, el MTA puede incorporar la función MDA, y el Sendmail MTA popular puede hasta ser usado como un MUA en algunas circunstancias.

Como la correspondencia es pasada del MUA origen a través de varios servidores, hasta el MUA final, es acrecentada una serie de encabezamiento, que graba los detalles de viaje y también controla el procesamiento de correspondencia por los servidores intermediarios y por el MUA final. Algunos de ellos son encabezamientos Multi-purpose Internet Mail Extension

��


(MIME), que son usados para una serie de objetivos de control, incluso soporte para conjuntos de caracteres non-ASCII, soporte para contenido embutido como imágenes y soporte para anexos. Cuando un MUA anexa un archivo, él graba su tipo como un encabezamiento MIME y entonces, es responsabilidad del MUA final estar apto a decodificarlo.

Abajo discutimos partes de ese modelo más detalladamente:

B.1 MTA

La mayor parte de los MTAs permite al administrador controlar la aceptación de la

correspondencia en función del remitente. Eso es hecho, frecuentemente, limitándose el número de direcciones IP, que vienen de conexiones SMTP, que el MTA va aceptar. Eso es extremamente valioso en la prevención de spammers que usan el MTA como un relay y entopen la anchura de banda de la red al MTA.

Existe un conjunto de más o menos 20 extensiones para el SMTP llamadas Extended SMTP o ESMTP. Esas extensiones permiten, entre otras cosas, transferencia más rápida de corres-pondencia entre MTAs concordantes, usando la extensión de un canal de información.

Una otra extensión posibilita la codificación del Transport Layer Security (TLS) entre MTAs concordantes, y una otra, la SMTP-AUTH, permite que los usuarios sean autenticados, usando una serie de técnicas. Ambas las extensiones son útiles cuando el MTA no permite que un cliente se conecte normalmente porque su dirección IP está fuera del espacio de enderezamiento confiable. Eso puede pasar, por ejemplo, si un usuario de laptop digitar de un sitio cualquier de la Internet – vea Sección.

El modelo original asumió que el propietario de una cuenta de correo tenía una cuenta de login en el servidor de correo. Eso significaba que el MTA podría examinar el archivo de seña local para autenticar los usuarios. Ese modelo es muy restrictivo y los MTAs modernos necesitan dar soporte a los Usuarios Virtuales donde los detalles del propietario de la cuenta son mantenidos en un banco de datos, frecuentemente de forma independiente de los detalles de la cuenta de login normal. Eso significa que un usuario puede tener una seña para correo y una otra para login.

El banco de datos puede recibir soporte de LDAP, un banco SQL o un archivo simple. El MySQL es el servidor de SQL preferido pues es eficiente, es rápido en lo que dice respecto a un aplicativo básicamente "sólo para lectura". El PostgreSQL y el Oracle también pueden ser usados.

Un banco de datos con soporte LDAP es recomendado pues ofrece soporte mejor para distribución. Implementaciones con default LDAP frecuentemente usan los productos Berkeley Database de Sleepycat Systems.

Algunas veces, una máquina sólo puede conectarse a un servidor de correo intermitentemente. Eso puede pasar en el caso de los que trabajan en casa o usuarios de laptop, por ejemplo. También puede acontecer en pequeñas oficinas, donde el costo de una conexión permanente no se justifica. En esas circunstancias, la central no puede enviar correspondencia como haría normalmente, y necesita almacenarla hasta que sea hecha una conexión. Comentarios similares son válidos para el MTA (si hubier) en la máquina cliente, o, en el caso de una oficina pequeña, el servidor de correo que es gateway. Esos MTAs pueden soportar tales situaciones y son normalmente llamados de Smart Host (Anfitriones Inteligentes) cuando lo hacen.

La distribución de un Smart Host puede ser hecha a través de SMTP o POP3.

��


La distribución vía SMTP es directa y la seguridad de la máquina receptora puede ser perfeccionada a través de la restricción de la conexión para dentro sólo a partir del Smart Host.

La distribución vía POP3 puede ser hecha usándose el MUA o el aplicativo fetchmail. El Fetchmail hará el download de la correspondencia para una caja de correo local, como mencionado anteriormente, o entregará en un MTA local, caso sea requerido, por ejemplo, donde están envueltas múltiplas cuentas de correo.

Ambos los métodos trabajan bien, pero presentan las desventajas de no permitir el uso de listas de bloqueo para prevenir spam de relays abiertos y de otras fuentes indeseables. Herramientas como SpamAssassin pueden eliminar la mayor parte del spam, pero los costos de procesamiento son mucho más altos y anchura de banda mayor es utilizada para descargar correo destinado al examen.

B.2 MUA El MUA y el MUI juntos forman el paquete que la mayoría de los usuarios considera "el

correo". Eso es el software cliente que opera en un servidor de la web o directamente en estación de trabajo para permitir a las personas enviar y recibir correspondencia. Es normalmente fornecido algún tipo de almacenamiento, de forma que la correspondencia pueda ser inserida en "archivador" o "cajas de correo locales"para referencia futura.

El MUA trabaja con protocolos del tipo SMTP para sumisión de correspondencia e IMAP o POP para recuperación de correspondencia y archivamiento. Él comprende el formato de los mensajes de correo y puede descomponer mensajes MIME en sus partes componentes. Donde hay una requisición de fuerte seguridad "punta-a la -punta", el MUA también es responsable por la codificación y asignatura de los mensajes. Hay dos padrones que competen en ese caso: el S/MIME, que es basado en certificados X.509, y el PGP/GPG, que es basado en un formato diferente de certificado con um modelo más "web-of-trust"de que "hierarchy-of-trust".

La mayoría de los MUAS de software libre da soporte a asignaturas digitales usando el GNU Privacy Guard (GPG). Pocos dan soporte a asignaturas S/MIME. Corporaciones de negocios y Gobiernos optaron por el padrón S/MIME y su uso debe, por lo tanto, contar con soporte.

B.3 Almacenaje de Correo Los sistemas Unís asumieron originalmente que el propietario de una cuenta de correo

tendría acceso a la máquina recibiendo el servidor de correo, y que podría leer un archivo conteniendo sus correspondencias - o, alternativamente, que la correspondencia sería entregue a la máquina normalmente usada por el usuario para trabajar. Eso funcionaba bien para ambientes con un número pequeño de usuarios que también necesitaban de una cuenta login real en una máquina con un servidor de correo, pero no es práctico o seguro en término generales.

El formato original para almacenar correo era un archivo único por usuario, con las corres-pondencias nuevas siendo anexadas al final. Ese archivo podría quedarse muy grande y la lectura a través de él una correspondencia aleatoria sería luego ineficiente. Ese formato es frecuentemente conocido como "mbox"y todavía es usado por algunos MUAs, en particular para correo almacenado localmente para el usuario. Fue hecha una alteración en que cada correspondencia pasó a ser mantenida como un archivo diferente en la estructura del directorio, que permite acceso aleatorio más eficiente. Una variante de esa estructura es llamada "mh"y una otra particular con directorios y procedimientos de acceso definidos es llamada "maildir".

��


Ni todos los MTAs dan soporte a esos métodos diferentes de acceso directo, por eso la ne-cesidad de MAAs. Un MUA que no puede accesar el depósito de correo directamente, tendrá que usar un componente MAA que usa POP o IMAP.

Tanto el POP3 cuanto el IMAP envían señas como texto simple por default. El IMAP puede usar señas mezcladas, si el MUA soportar. El uso de links TLS criptografados es posible, si el MAA y el MUA soporten, es recomendable en redes locales, y debe ser obligatorio para acceso remoto.

Los MTAs algunas veces se comunican con los MDAs usando el Local Mail Transport Protocol o LMTP. La mayor parte de los MTAs e MDAs dan soporte al mismo.

��


APÉNDICE E - LICENCIA CC-GNU GPL

Figura C.1:

Licencia Pública General del GNU (GPL) [General Public License]

Versión 21 , Junio de 1991 Derechos Autorales Reservados (c) 1989, 1991 Free Software Foundation, Inc. 59 Temple Place, Suite [conjunto] 330, Boston, MA [Massachusetts] 02111-1307 USA [Estados Unidos de América]

Es permitido a cualquier persona copiar y distribuir copias sin alteraciones de este documento de licencia, siendo vedada, por lo tanto, cualquier modificación.

Introducción Las licencias de la mayoría de los softwares son elaboradas para suprimir su libertad de

compartirlos y modificarlos. La Licencia Pública General del GNU, al contrario, visa garantir su libertad de compartir y modificar softwares libres para asegurar que el software sea libre para todos sus usuarios. Esta Licencia Pública General es aplicable a la mayoría de los softwares de la Free Software Foundation [Fundación del Software libre] y a cualquier otro programa cuyos autores se comprometan a usarla. (En vez de ella, algunos otros softwares de la Free Software Foundation son cubiertos por la Licencia Pública General de Biblioteca del GNU). Usted también podrá aplicarla a sus programas.

Cuando hablamos de software libre, estamos refiriéndonos a la libertad, no al precio. Nuestras Licencias Públicas Generales visan garantir que usted tenga la libertad de distribuir copias de software libre (y cobrar por eso si se desea), que reciba código-fuente o pueda obtenerlo si se desea, que pueda em http://creativecommons.org/licenses/GPL/2.0/legalcode.pt. modificarlo o usar partes de ellos en nuevos programas libres; finalmente, que usted tenga conciencia de que puede hacer todo eso.

Protegemos sus derechos a través de dos pasos: (1) estableciendo derechos autórales sobre el software y (2) concediendo a usted esta licencia, que da permisión legal para copiar, distribuir y/o modificar el software.

Además, para la protección de cada autor y la nuestra, queremos tener seguridad de que todos entiendan que no hay ninguna garantía para este software libre. Si el software es modificado por alguien y pasado adelante, queremos que sus receptores sepan que lo que recibieron no es el original, de forma que cualquier problema introducido por terceros no afecten las reputaciones de los autores originales.

Finalmente, cualquier programa libre es constantemente amenazado por patentes de software. Queremos evitar el riesgo de que redistribuidores de un programa libre obtengan individualmente licencias bajo una patente, tornando el programa, con efecto, propietario. Para impedir eso, dejamos claro que cualquier patente debe ser licenciada para el uso libre por parte de cualquier persona o, entonces, simplesmente no debe ser licenciada.

��


Los exactos términos y condiciones para copia, distribución y modificación siguen abajo. TÉRMINOS Y CONDICIONES PARA COPIA, DISTRIBUCIÓN Y MODIFICACIÓN.

1. Esta Licencia se aplica a cualquier programa u otra obra que contenga un aviso inserido por el respectivo titular de los derechos autorales, informando que la referida obra puede ser distribuída en conformidad con los términos de esta Licencia Pública General. El término "Programa", utilizado abajo, se refiere a cualquier programa u obra, y el término "obras basadas en el Programa" significa tanto el Programa, como cualquier obra derivada en los términos de la legislación de derechos autorales: esto es, una obra conteniendo el Programa o una parte de ella, tanto de forma idéntica como con modificaciones, y/o traducida para otro lenguaje. (De ahora en adelante, el término "modificación"incluye también, sin reservas, la traducción). Cada licenciado, ahora será denominado "usted".

Otras actividades que no la cópia, distribución y modificación, no son cobiertas por esta Licencia; ellas están fuera de su albo. El acto de ejecutar el Programa no tiene restricciones y el resultado generado a partir del Programa se encuentra cubierto sólo si su contenido constituir una obra basada en el Programa (independiente de haber sido producida por la ejecución del Programa). En la verdad, esto dependerá de lo que el Programa hace.

2. Usted podrá hacer cópias idénticas del código-fuente del Programa al recibirlo y distribuirlas, en cualquier mídia o medio, desde que publique, de forma ostensiva y adecuada, en cada copia, un aviso de derechos autorales (o copyright) apropiado y una notificación sobre la exoneración de garantía; mantenga intactas las informaciones, avisos o notificaciones referentes a esta Licencia es la ausencia de cualquier garantía; y dé a cualquier otros receptores del Programa una copia de esta Licencia junto con el Programa. Usted podrá cobrar un valor por la transferencia de una copia, y usted puede ofrecer, si quiere, la protección de una garantía en cambio de un valor.

3. Usted podrá modificar su copia o copias del Programa o cualquier parte de él, formando, de esa forma, una obra basada en el Programa, bien como copiar y distribuir esas modificaciones u obra, de acuerdo con los términos de la Cláusula 1 arriba, desde que usted también atienda a todas las siguientes condiciones:

a. Usted debe hacer con que los archivos modificados contengan avisos, en destaque, informando que usted modificó los archivos, bien como la fecha de cualquier modificación.

b. Usted debe hacer con que cualquier obra que usted distribuya o publique, que en el todo o en parte contenga el Programa o sea de él derivada, o derivada de cualquier parte de él, sea licenciada como un todo sin cualquier costo para todos los terceros en los términos de esta licencia.

c. Si el programa modificado normalmente lee comandos interactivamente cuando ejecutado, usted deberá hacer con que él, al comenzar a ser ejecutado para ese uso interactivo en su forma más simple, imprima o muestre un aviso incluyendo el aviso de derechos autorales (o copyright) apropiado, además de una notificación de que no hay garantía (o, entonces, informando que usted ofrece garantía) e informando que los usuários podrán redistribuir el programa de acuerdo con esas condiciones, esclareciendo al usuario como visualizar una copia de esta Licencia. (Excepción: si el Programa en si es interactivo pero no imprime normalmente avisos como esos, no es obligatorio que su obra basada en el Programa imprima un aviso). Esas exigencias se aplican a la obra modificada como un todo. Si partes identificables de esa obra no sean derivadas del Programa y puedan ser consideradas razonablemente como obras independientes y separadas por si propias, en ese caso, esta Licencia y sus términos no se aplicaran a esas partes cuando usted distribuirlas como obras separadas. Todavía, cuando usted las distribuya como parte de un todo que constituye una obra basada en el Programa, la distribución de este todo tendrá de ser realizada en conformidad con esta Licencia, cuyas permisiones para otros licenciados se entenderán a la obra por completo y, consecuentemente, a toda y cualquier parte, independiente de quien la escribió.

��


Por lo tanto, esta cláusula no tiene la intención de afirmar derechos o contestar sus derechos sobre una obra escrita enteramente por usted; la intención es, antes, de ejercer el derecho de controlar la distribución de obras derivadas u obras colectivas basadas en el Programa.

Además, la simple agregación de otra obra que no sea basada en el Programa a él (o a una obra basada en el Programa) en un volumen de mídia o medio de almacenamiento o distribución, no incluye esta otra obra en el ámbito de esta Licencia.

4. Usted podrá copiar y distribuir el Programa (o una obra basada en él, de acuerdo con la Cláusula 2) en código-objeto o formato ejecutable de acuerdo con los términos de las Cláusulas 1 y 2 arriba, desde que usted también tome una de las siguientes providencias:

a. Incluir el código-fuente correspondiente completo, pasible de lectura por la máquina, lo cual tendrá que ser distribuido de acuerdo con las Cláusulas 1 y 2 arriba, en un medio o mídia habitualmente usada para intercambio de software; o,

b. Incluir una oferta por escrito, válida por lo menos por tres años, para suministrar a cual-quier tercero, por un costo que no sea superior a su costo de físicamente realizar la distribución de la fuente, una copia completa pasible de lectura por la máquina, del códigofuente correspondiente, a ser distribuido de acuerdo con las Cláusulas 1 y 2 arriba, en un medio o mídia habitualmente usado para intercambio de software; o,

c. Incluir las informaciones recibidas por usted, cuanto a la oferta para distribuir el código-fuente correspondiente. (Esta alternativa es permitida sólo para distribución no comercial y apenas si usted haya recibido el programa en código-objeto o formato ejecutable con esa oferta, de acuerdo con la letra b, arriba). El código-fuente de una obra significa el formato preferencial de la obra para que sean hechas modificaciones en ellas mismas. Para una obra ejecutable, el código-fuente completo significa el código-fuente entero de todos los módulos que ella tenga, más cualquiera de los archivos de definición de interface asociados, además de los scripts usados para controlar la compilación e instalación del ejecutable. Sin embargo, como una excepción especial, el código-fuente distribuído no necesita incluir nada que no sea normalmente distribuído (tanto en el formato fuente como en el binario) con los componentes principales (compilador, kernel y así por delante) del sistema operacional en el cual el ejecutable es ejecutado, a menos que este componente en si acompañe el ejecutable. Si la distribución del ejecutable o código-objeto es hecha mediante la permisión de acceso para copiar, a partir de un local designado, entonces, la permisión de acceso equivalente para copiar el código-fuente a partir del mismo local será considerada como distribución del código-fuente, mismo que los terceros no sean llevados a copiar la fuente junto con el código-objeto.

5. Usted no podrá copiar, modificar, sublicenciar o distribuir el Programa, excepto conforme expresamente establecido en esta Licencia. Cualquier tentativa, de otra manera, copiar, modificar, sublicenciar o distribuir el Programa será inválido, y automáticamente rescindirá sus derechos bajo esta Licencia. Por lo tanto, terceros que recibieron copias o derechos de acuerdo a esta Licencia no tendrán sus licencias rescindidas, mientras que mantengan su pleno cumplimiento.

6. Usted no es obligado a aceptar esta Licencia, una vez que usted no la firmó. Sin embargo, nada más le concede a usted permiso para modificar o distribuir el Programa o respectivas obras derivativas. Tales actos son prohibidos por ley si usted no aceptar esta Licencia. Consecuente-mente, al modificar o distribuir el Programa (o cualquier obra basada en el Programa), usted estará manifestando su aceptación de esta Licencia para hacerlo, bien como de todos sus términos y condiciones para copiar, distribuir o modificar el Programa u obras en él basadas.

7. Cada vez que usted redistribuye el Programa (u obra basada en el Programa), el receptor recibirá, automáticamente, una licencia del licenciante original, para copiar, distribuir o modificar el Programa, sujeto a estos términos y condiciones. Usted no podrá imponer cualquier restricción adicional al ejercicio, por los receptores, de los derechos concedidos por este instru-mento. Usted no tiene responsabilidad de promover el cumplimiento por parte de terceros de esta licencia.

��


8. Si, como resultado de una sentencia judicial o alegación de violación de patente, o por cualquier otro motivo (no restricto a las cuestiones de patentes), sean impuestas a usted condiciones (tanto a través de mandado judicial, contrato o cualquier otra forma) que contradigan las condiciones de esta Licencia, usted no estará desobligado cuanto a las condiciones de esta Licencia. Si usted no puede actuar como distribuidor de modo a satisfacer simultáneamente sus obligaciones bajo esta licencia y cualquier otras obligaciones pertinentes, entonces, como consecuencia, usted no podrá distribuir el Programa de ninguna forma. Por ejemplo, si una licencia bajo una patente no permite la redistribución por parte de todos aquellos que recibieron copias, directa o indirectamente de usted, sin el pago de royalties, entonces, la única forma de cumplir tanto con esta exigencia cuanto con esta licencia será dejar de distribuir, por completo, el Programa.

Si cualquier parte de esta Cláusula sea considerada inválida o no ejecutable, bajo cualquier circunstancia específica, lo restante de la cláusula deberá continuar a ser aplicado y la cláusula, como un todo, deberá ser aplicada en otras circunstancias. Esta cláusula no tiene la finalidad de inducir usted a inflingir cualquier patentes o derechos de propiedad, ni de contestar la validad de cualquier reivindicaciones de este tipo; la única finalidad de esta cláusula es proteger la integridad del sistema de distribución del software libre, lo cual es implementado mediante prácticas de licencias públicas. Muchas personas han hecho generosas contribuciones a la amplia gama de software distribuído a través de ese sistema, confiando en la aplicación consistente de este sistema; cabe al autor/donador decidir si desea distribuir software a través de cualquier otro sistema y un licenciado no puede imponer esta elección.

Esta cláusula visa dejar absolutamente claro lo que se cree ser una consecuencia de lo restante de esta Licencia.

9. Si la distribución y/o uso del Programa sea restricta en determinados países, tanto por patentes o por interfaces protegidas por derecho autoral, el titular original de los derechos autorales que poner el Programa bajo esta Licencia podrá acrecentar una limitación geográfica de distribución explícita excluyendo esos países, de modo que la distribución sea permitida sólo en los países o entre los países que no fueron excluidos de esa forma. En ese caso, esta Licencia pasa a incorporar la limitación como si esta hubiese sido escrita en el cuerpo de esta Licencia.

10. La Free Software Foundation podrá de tiempos en tiempos publicar nuevas versiones y/o versiones revisadas de la Licencia Pública General. Esas nuevas versiones serán semejantes en espíritu a la presente versión, pero pueden diferenciarse, además, en detalle, para tratar de nuevos problemas o preocupaciones.

Cada versión recibe un número de versión distinto. Si el Programa especifica un número de versión de esta Licencia que se aplique a ella y a "cualquier versión posterior", usted tendrá la opción de seguir los términos y condiciones tanto de aquella versión como de cualquier versión posterior publicada por la Free Software Foundation. Si el Programa no especifica un número de versión de esta Licencia, usted podrá elegir cualquier versión ya publicada por la Free Software Foundation.

11. Si usted desea incorporar partes del Programa en otros programas libres cuyas condiciones de distribución sean diferentes, escriba al autor solicitando la respectiva permisión. Para software cuyos derechos autorales sean de la Free Software Foundation, escriba para ella; algunas veces, abrimos excepciones para eso. Nuestra decisión será guiada por los dos objetivos de preservar la condición libre de todos los derivados de nuestro software libre y de promover el compartimiento y reutilización de software, de modo general.

EXCLUSIÓN DE GARANTÍA 12. COMO EL PROGRAMA ES LICENCIADO SIN COSTO, NO HAY NINGUNA

GARANTÍA PARA EL PROGRAMA, EN EL LIMITE PERMITIDO POR LA LEY APLICABLE. EXCEPTO CUANDO DE OTRA FORMA ESTABLECIDO POR ESCRITO,

��


LOS TITULARES DE LOS DERECHOS AUTORALES Y/U OTRAS PARTES, DAN EL PROGRAMA "EN EL ESTADO DONDE SE ENCUNTRA", SIN NINGUNA GARANTÍA DE CUALQUIER TIPO, TANTO EXPRESA COMO IMPLÍCITA, INCLUYENDO, ENTRE OTRAS, LAS GARANTÍAS IMPLÍCITAS DE COMERCIABILIDAD Y ADECUACIÓN A UNA FINALIDAD ESPECÍFICA. EL RIESGO INTEGRAL CUANTO A LA CALIDAD Y DESEMPEÑO DEL PROGRAMA ES ASUMIDO POR USTED. CASO EL PROGRAMA CONTENGA DEFECTOS, USTED ARCARÁ COM LOS COSTOS DE TODOS LOS SERVI-CIOS, REPAROS O CORRECCIONES NECESARIAS.

13. EN NINGUNA CIRCUNSTANCIA, A MENOS QUE EXIGIDO POR LA LEY APLICÁBLE O ACORDADO POR ESCRITO, CUALQUIER TITULAR DE DERECHOS AUTORALES O CUALQUIER OTRA PARTE QUE PUEDA MODIFICAR Y/O REDISTRIBUIR EL PROGRAMA, CONFORME PERMITIDO ANTERIORMENTE, SERÁ RESPONSABLE PARA CON USTED POR DAÑOS, INCLUYENDO ENTRE OTROS, CUALQUIER DAÑOS GENERALES, ESPECIALES, FORTUITOS O EMERGENTES, ADVINDOS DEL USO O IMPOSIBILIDAD DE USO DEL PROGRAMA (INCLUYENDO, ENTRE OTROS, PIERDAS DE DATOS O DATOS SIENDO GENERADOS DE FORMA IMPRECISA, PIERDAS SUFRIDAS POR USTED O TERCEROS O LA IMPOSIBILIDAD DEL PROGRAMA DE OPERAR CON CUALESQUIERA OTROS PROGRAMAS), MISMO QUE ESE TITULAR, U OTRA PARTE, TENGA SIDO ALERTADA SOBRE LA POSIBI-LIDAD DE OCURRENCIA DE ESES DAÑOS.

FINAL DE LOS TÉRMINOS Y CONDICIONES

Como Aplicar Estos Términos para Sus Nuevos Programas.

Si usted desarrolla un programa nuevo y quiere que él sea de la mayor utilidad posible para el público, el mejor camino para obtener esto es hacer de él un software libre, lo cual cualquier persona puede redistribuir y modificar bajo los presentes términos.

Para hacer esto, anexe las notificaciones siguientes al programa. Es más seguro anexarlas al comienzo de cada archivo-fuente, de modo a transmitir del modo más eficiente la exclusión de garantía; y cada archivo debe tener al menos la línea de "derechos autorales reservados" y una indicación de donde la notificación completa se encuentra.

<una línea para informar el nombre del programa y una breve idea de lo que él hace.> Derechos Autorales Reservados (c) <nombre del autor> Este programa es software libre; usted puede redistribuirlo y/o modificarlo bajo los términos de la Licencia Pública General GNU conforme publicada por la Free Software Foundation; tanto la versión 2 de la Licencia, como (a su criterio) cualquier versión posterior. Este programa es distribuido en la expectativa de que sea útil, además, SIN NINGUNA GARANTÍA; ni mismo la garantía implícita del COMERCIABILIDAD O ADECUACIÓN A UnA FINALIDAD ESPECÍFICA. Consulte la Licencia Pública General del GNU para más detalles.

Usted debe haber recibido una copia de la Licencia Pública General del GNU junto con este programa; si no, escriba para la Free Software Foundation, Inc., en la dirección 59 Temple Street, Suite 330, Boston, MA 02111-1307 USA. Incluya también informaciones sobre como contactarlo por correo electrónico y por medio postal.

Si el programa es interactivo, haga con que produzca una pequeña notificación como esta, cuando sea iniciado en un modo interactivo:

Versión 69 del Gnomovision, Derechos Autorales Reservados (c) año nombre del autor. El Gnomovision NO POSEE CUALQUIER TIPO DE GARANTIA; para detalles, digite ’show w’.

��


Este es un software libre y usted es bienvenido para redistribuirlo bajo ciertas condiciones; digite ’show c’ para detalles.

Los comandos hipotéticos ‘show w’ y ‘show c’ deben mostrar las partes apropiadas de la Licencia Pública General. Naturalmente, los comandos que usted utilizar podrán tener otras denominaciones que no ‘show w’ es ‘show c’; ellos podrán hasta ser cliques del mouse o itenes de un menú - lo que sea adecuado a su programa.

Usted también puede solicitar a su empleador (si usted es un programador) o su institución académica, si es el caso, para firmar una "renuncia de derechos autorales"sobre el programa, si necesario. Sigue un ejemplo; altere los nombres:

La Yoyodyne Ltda., en este acto, renuncia a todos eventuales derechos autorales sobre el programa ‘Gnomovision’ (que realiza pasajes en compiladores), escrito por James Hacker. <Asignatura de Ty Coon> 1o de abril de 1989, Ty Coon, Presidente

Esta Licencia Pública General no permite la incorporación de su programa a programas propietarios. Si su programa es una biblioteca de sub-rutinas, usted podrá considerar ser más útil permitir la ligación de aplicaciones propietarias a su biblioteca. Si eso es lo que usted desea hacer, utilice la Licencia Pública General de Biblioteca del GNU, a envés de esta Licencia.

��


APÉNDICE F - GLOSARIO

�

ACL Access Control List. Una Lista de Control de Acceso es una lista anexa a un objeto, tal como un archivo. Consiste de expresiones de control, cada uno de los cuales concede o niega alguna capacidad a un usuario particular o a un grupo de usuarios.

��

��

API Application Programming Interface. El método específico recomen dado por un sistema operacional de computadora, aplicativo o herramienta de terceros, por lo cual un programador escribiendo un aplicativo puede hacer requisiciones del sistema operacional. también conocido por Application Programmers Interface.

ASP Active Server Pages. Una página HTML que incluye uno o más scripts (pequeños programas embutidos) que son procesados en un servidor de la Web Microsoft ® antes de la página ser enviada para el usuário. Un ASP es, de alguna forma, similar a la abarcancia de un serverside o un aplicativo de interface de gateway común (Common Gateway Interface - CGI) en que todo envuelve programas que operan en el servidor, normalmente tallando una página para el usuario.

BDC Backup Domain Controller. Papeles que pueden ser designados a un servidor en una red de computadores que usa el sistema operacional Windows NT ® . El Windows NT ® usa la idea de un dominio para gerir acceso a un conjunto de recursos de red (aplicativos, impre-soras, etc) para un grupo de usuarios. El usuario necesita sólo conectarse al dominio para ganar acceso a los recursos, que pueden estar localizados en varios servidores diferentes en la red. Un servidor, conocido como controlador de dominio primario, gerencia el banco de datos master del usuario para el domino. Uno o más otros servidores son designados como controladores del dominio de backup. El controlador de dominio primario envía copias del banco de datos, periódicamente, a los controladores de dominio del backup. Un controlador de domínio de backup puede intervenir como controlador de domínio primario, caso el servidor de PDC falle y también puede ayudar a equilibrar la carga de trabajo si la red esté muy ocupada��

�� !��"��!�� #�� $��

��%��&��#�� '��%�� %��!��%��!�� !� �� !� ��(�� #�� %�� )��)�� !� �� #�)��

Concurrent User Licence - Una forma de licencia que cobra sobre la base del mayor número de usuarios que pueden accesar un aplicativo al mismo tiempo.

Boilerplate Entries Cualquier padrón o partes indiferenciadas de datos, usualmente cosas que deben estar presentes, demás no son de gran interés.

CIL Common Intermediate Language. Código intermediario independiente del compilador y de la máquina, que va operar por un Common Language Runtime or CLR. Ese código puede ser obtenido de varios lenguajes, incluso C# y C. Ambos, CIL y CLR, son parte del CLI o

��


Common Language Infrastructure. Daemon Un programa ligado a un sistema o proceso, esperando para desempeñar su tarea, hasta que el evento sea accionado por un otro proceso.

DBMS Database Management System. Un programa que permite que uno o más usuarios de computador accesen datos en un banco de datos. El DBMS gerencia requisiciones de usuarios (y requisiciones de otros programas), de forma que usuarios y otros programas queden libres de tener que entender donde los datos son mantenidos físicamente en media de almacenamiento y, en un sistema multi-uso, quien más puede estar accesando los datos.

DEC Protocol The Digital Equipment Corporation or DEC created a set of protocols for controlling terminal devices. These protocols have become widely used and are now standards��

DHCP Dynamic Host Configuration Protocol. Un protocolo de comunica ción que permite a los administradores de la red gerenciar de forma central y automatizar la designación de las direcciones del Internet Protocol (IP) en la red de una organización.

Distribución Para softwares de fuente abierta como el Linux, compañías como la Red Hat se especializan en paquetes de imponentes de muchas fuentes juntos en un único paquete o un conjunto de paquetes, que pueden ser distribuídos convenientemente para suarios con un único download o en un conjunto de CDs.

DNS Domain Name Server. Usado para conversión entre el nombre de la máquina en la Internet y su dirección sumérico.

Domain (Authentication) Un conjunto de identificadores de autorización (personas y procesos) geridos por un servidor de autenticación.

%��*��"��

FTP File Transfer Protocol. Un medio independiente del sistema de transferir archivos entre sistemas conectados vía TCP/IP. Garante que el archivo fue transferido correctamente, mismo que tenga habido errores durante la transmisión.

+��)��,� ��,��)��-��+."�+��.��"��+/0��

Green Screen Un terminal o monitor que sólo es capaz de exhibir caracteres de tama ño fijo y (posiblemente) gráficos de bloques simple. El nombre viene de hecho de que muchas pantallas de monitores mainframe de los años 1970 y 1980 usaban fósforo verde.

+0��+�)��0��

Hashes Un Hash es un identificador short-form único, una "impresión digital"de algo más complicado. Hashes son producidos usándose funciones matemáticas one-way. Son usados en sistemas de banco de datos y en sistemas de seguridad y de codificación.

HTTP Hypertext Transfer Protocol. Un conjunto de reglas para cambio de archivos (texto, gráficos, imágenes, sonido, video, y otros archivos multimídia) en la World Wide Web. Con relación al juego de protocolos TCP/IP (que son la base para cambio de informaciones en la Internet), el HTTP es un protocolo de aplicativo.

Java Applet Un mini-programa de software que un navegador habilitado por Java o ActiveX usa y de lo cual hace el download automáticamente. Puede acrecentar soporte sofisticado a las páginas de la Web, muy además de programaciones como DHTML o Javascript.

Java Servlet un programa Java que opera como parte de un servicio de red, tipicamente en un servidor HTTP y responde a necesidades de clientes. El uso más común de un servlet es de extender un servidor de la web a través de la generación de contenido web dinámicamente. Por ejemplo, un cliente puede necesitar de información de un banco de datos; puede ser escrito un servlet que reciba el pedido, consiga y procese los datos de la forma como el cliente necesita y retorne el resultado para el cliente.

��


JDBC Java Database Connectivity. Una especificación de interface de programa aplicativo (application program interface - API) para conectar programas escritos en Java a los datos en bancos de datos populares. A interface de programa aplicativo permite que se codifique declaraciones de requisición de acceso en Structured Query Language (SQL), las cuales son entonces pasadas para el programa que gerencia el banco de datos. El resultado es retornado a través de una interface similar.

Kernel El núcleo de un sistema operacional que trabaja con tareas como alocación de memoria, dispositivo input y output, alocación de proceso, seguridad y acceso al usuario.

LDAP Lightweight Directory Access Protocol. Un protocolo de software para habilitar cualquier persona a localizar organizaciones, individuos y otros recursos como archivos y dispositivos en una red, sea en red (Internet) pública o en intranet interna. O LDAP es una versión "leve"(con poco volumen de códigos) del Directory Access Protocol (DAP), que es parte del X.500, un padrón para servicios de directorio en una red.

LGPL Lesser General Public License do GNU

Load Balancing Equilibrar la carga es dividir el volumen de trabajo que una computadora tiene para hacer entre dos o más rocesadores o computadoras, de forma que sea hecho un volumen mayor de trabajo al mismo tiempo y, en general, todos los usuarios son más bien servidos. El equilibrio de carga puede ser implementado con hardware, software o una combi-nación de los dos. Típicamente, el equilibrio de carga es la principal razón agrupamiento de servidores de computadoras.

MAA Mail Access Agent. Un término usado en este relato para describir el componente de correo del servidor que gerencia el acceso al depósito de correo por un MUA. Son ejemplos los servidores del POP y del IMAP. Vea Apéndice C página 108 arriba para una discusión completa.

MDA Mail Delivery Agent. Un componente de correo que acepta correo de un MTA y lo devuelve al depósito de correo.

Metadata Una definición o descripción de datos.

MTA Mail Transport Agent. Ese es el componente de correo que tiene la responsabilidad de decidir si la correspondencia entregue a él es para una cuenta local o no. Él pasa la correspondencia local para un MDA o la almacena directo en el mailstore. El correo remoto es pasado para un otro MTA.

MUA Mail User Agent. El componente de correo del cliente, lo cual recupera el correo del mailstore y lo presenta al usuario. Él permite al usuario crear nuevas correspondencias y mandarlas al MTA para que sean transmitidas. El MUA será frecuentemente asociado a una interface gráfica.

.NET Conjunto de tecnologías de software de la Microsoft ® para conectar in formación, personas, sistemas y dispositivos. Es basado en servicios de la web, que son pequeños aplicativos que pueden conectarse uno a los otros, bien como a otros aplicativos mayores en la Internet. El proyecto Mono software libre es una implementación de la estructura de desarrollo.NET.

NFS Network File Service. Un protocolo usado comúnmente por el Unix como sistema para accesar archivos mantenidos en sistemas remotos, como si fueran locales.

ODBC Open Database Connectivity. Una interface de programación de aplicativo de padrón abierto (application programming interface - API) para accesar un banco de datos. Usando relatos ODBC en un programa, se puede accesar archivos en varios bancos de datos di-ferentes, incluso Access, dBase, DB2, Excel, y Text. Además del software ODBC, es necesario un modulo o driver separado para cada banco de datos a ser accesado.

Open Relay Un relay abierto (algunas veces llamado de un relay inseguro o third-party relay) es un servidor de correo SMTP que permite la transmisión de mensajes de correo por terceros. A través del procesamiento de correo que no es para usuario local, ni de usuario local,

��


un relay abierto posibilita que un remitente inescrupuloso indique la rota de grandes volúmenes de spam. En la verdad, el propietario del servidor - que, típicamente, no tiene conocimiento del problema – da red y recursos de computadora para los objetivos del remitente. Además de los costos financieros incurridos cuando un spammer secuestra un servidor, una organización puede también sufrir trabamientos del sistema, daños a equipos y pierda de negocios.

PDA Personal Digital Assistant. Un computador de mano electrónico. PDC

Primary Domain Controller. Vea Backup Domain Controller (BDC).

PHP PHP: Hypertext Preprocessor. Un lenguaje y un intérprete criptografados disponibilizados gratuitamente y usados primariamente en servidores Linux Web. El PHP es una alternativa a la tecnología Active Server Page (ASP) de la Microsoft ® . Como el ASP, el script del PHP es embutido dentro de página de la web junto de su HTML. Antes de la página ser enviada a un usuario que a tenga solicitado, el servidor de la web llama el PHP para interpretar y desempeñar las operaciones solicitadas en el script PHP��

.1�� .�� 1�!� �� 0�� .1�� !��!�� #��!�� *��!�� !��

Potential User License - Una forma de licencia que cobra con base en el número máximo de usuarios que tiene capacidad de accesar un aplicativo.

Protocolo Un conjunto especial de reglas usado en una conexión de telecomunicación, entre puntos finales. Existen protocolos en varios niveles en una conexión de telecomunicación. Hay protocolos de hardware de telefonía. Hay protocolos entre cada una de las varias camadas funcionales y cada camada correspondiente del otro lado de una comunicación. Ambos los puntos finales necesitan reconocer y cumplir los preceptos del protocolo. Los protocolos son frecuentemente descriptos en una indústria o padrón internacional.

Proxy Server Un servidor que actúa como intermediario entre un usuario de una estación de trabajo y la Internet, de forma que la empresa pueda garantir seguridad, control administrativo y servicio de caching. Un servidor proxy es asociado a un servidor de gateway o a parte de él, que separa la red de la empresa de la red de fuera y un servidor firewall, que protege la red de la empresa de la intromisión de fuera.

Session Manager Cuando un usuario se liga a una computadora, se crea una sesión que consiste de un ambiente completo de información de control personal para ellos, una serie de procesos. El manager permite que el usuario mude ese ambiente y puede también salvarlo de forma que el próximo usuario, al ligarse a la computadora, vuelva a la situación en que estaba antes de desligarse por la última vez.

Smart Card Una tarjeta plástica que contiene un chip de computador. La tarjeta es usado para desempeñar operaciones que requieren los datos que están almacenados en el chip.

SMB Server Message Block. Este es el protocolo usado en la red Windows ® para permitir que recursos como archivos de una máquina sean partidos en otras máquinas como si fuesen locales.

SMS Short Message Service. Un servicio para enviar mensajes de hasta 160 caracteres (224 caracteres si esté usando un modo 5-bit) para teléfonos móviles que usan comunicación Global System for Mobile (GSM).

Software Abierto Software cuyo acceso a los códigos fuente es permitido, entretanto con eventuales restricciones cuanto al uso de estos códigos��

��


Software Libre Software disponibilizado, gratuitamente o comercializado, con las premisas de libertad de instalación; plena utilización; acceso al código fuente; posibilidad de modificaciones/aperfeccionamiento para necesidades específicas; distribución de la forma original o modificada, con o sin costos. Definición presentada en la subsección 2.2.1.

Source Code Vea Binaries.

SQL Structured Query Language. Un lenguaje de programación e interactiva padrón para obtener información de un banco de datos y para actualizarlo. Aunque el SQL sea padrón ANSI e ISO, muchos productos de banco de datos soportan el SQL con extensiones propietarias para el lenguaje padrón. Las queries asumen el formato de un lenguaje comando que permite seleccionar, inserir, actualizar y encontrar el local de los datos, y así por delante. También hay una interface de programación.

SSL Secure Sockets Layers. Un protocolo comúnmente usado para gerenciar la seguridad de una transmisión de mensajes en la Internet. El SSL fue sucedido recientemente por el Transport Layer Security (TLS), que es basado en el SSL. El SSL es incluso como parte de los navegadores de la Microsoft ® y de la Netscape es de la mayor parte de los productos servidores de la Web.

Stored Procedure Un conjunto de instrucciones del Structured Query Language (SQL) con un nombre designado que es almacenado en el banco de datos de forma compilada de forma que pueda ser partido por varios programas .

Trigger do Structured Query Language (SQL) que dispara automáticamente una acción, cuando una operación específica ocurre, como la mudanza de datos en una tabla.

TLS Transport Layer Security. Una camada que provee servicios de criptografía y autenticación que pueden ser negociados durante la fase inicial de muchos protocolos de la Internet (e.g. SMTP, LDAP, IMAP, POP3). El TLS es derivado del SSL y usa los mismos certificados, pero no requisita que cada servicio reciba un nuevo número de puerta; vea SSL.

VMS Un sistema operacional desarrollado por la Digital Equipment Corporation (DEC) para usar en sus minicomputadores VAX. Posteriormente transferido para el sistema Alpha 64-bit. Un de los principales designers do VMS, posteriormente diseñó el kernel del Windows NT ®

WebDAV World Wide Web Distributed Authoring and Versioning. El padrón Internet Engineering Task Force (IETF) para autoría colaborativa en la Web: un conjunto de extensiones para el Hypertext Transfer Protocol (HTTP) que facilita la edición colaborativa y la gestión de archivos entre usuarios localizados remotamente uno de los otros en la Internet.

2��3��%��#�� %�� )�� !��-��#��%�� 4�� #�� !��!��!�� 4�� !��(��

53"�%-��36��"��0��-��!��!��2��2��2��!��%��53"��2��2��2�� 728 9��&��#��2��:!��-��36��"��7:�3"9��

X Sesión Cuando un usuario se liga a una computadora y opera programas en el protocolo X, él crea una X sesión.

5��0�� 5�� -)�� 5��