Open Source Brasil

Guía Libre
Referencia de Migración para Software Libre

del Gobierno Federal
Versión 0.96 Beta - Mercosul Página 1

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 Traducción al portugués de la Guía con
Información (SLTI) 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 Alteraciones y reorganización de las
Trabajo Migración para Software Libre Partes 1 y 2.
(GT-MSL)
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 Alteraciones y reorganización de las
Implementación del Software Libre y Partes 1, 2, y 3
Comité Técnico de Licencias y Legados
21/05/04 0.4 14ª. Reunión GT-MSL Contribución Alteraciones y reorganización de las
individual de cada institución Partes 1, 2, y 3. Creación de la Parte 4.
colaboradora
01/06/04 0.5 15ª. Reunión GT-MSL. Contribución Reorganización y alteración para el
individual de cada institución lanzamiento de la versión Beta para el
colaboradora V. Foro Internacional de Software
Libre.
15/06/04 0.6 Conversión de la Guía para Alteraciones y reorganizaciones de las
procesamiento LATEX 2. 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:
guialivre@planejamento.gov.br
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 c o ...................................................................................... 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
guialivre@planejamento.gov.br 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

guialivre@planejamento.gov.br.
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 III - 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.

PAR T E I V - 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 SMB 1 , 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

paulo.oliveira@mda.gov.br
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

welber.luchine@mc.gov.br
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

jbarrozo@radiobras.gov.br
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

aluizbarbosa@s g m. mar . mil.b r
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

enio.silva@previdencia.gov.br
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.

# 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
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.

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

jorge.maciel@previdencia.gov.br
Palabras-Llave: Controle de versión, CVS
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

moacir.pedroso@embrapa.gov.br
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
jones.tesser@serpro.gov.br
Palabras-Llave: Gerenciamento de Redes, MRTG, Nagios.
23.1 Gerenciamento de Redes
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;
desvío;
• Informar la estructura (Gerentes, Gestores y técnicos envueltos) sobre el
• Informar usuario sobre el desempeño del recurso y el impacto en el
ambiente;
• Proponer mejorías de servicio (continuidad);
(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;
desvío;
• Informar a la estructura (Gerentes, Gestores e técnicos envueltos) sobre o
• Informar usuario sobre el desempeño del recurso y el impacto en el ambiente;
• Proponer mejorías de servicio (disponibilidad);
(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;

(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
jean.carlo@planalto.gov.br
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 Exige hardware más potente Economía de Licencias de

aplicación en servicios de con software propietario y Uso y diminución de costo
red. flexibiliza el hardware con unitario de los servidores
sistemas operacionales libres (HW con arquitectura CISC
padrón Gnu/Linux. 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 Exigen hardware mínimo en Economía y ampliación del

de trabajo como Herramienta aplica -ciones cliente- tiempo útil de uso del HW.
Office. servidor y licenciamiento por Liberación de periféricos
estaciones de trabajo cuando utilizados en el desktop en
usado con software función de la mudanza del
propietario. No exige perfil de uso de servicios en
renovación de licencias con red (audio, grabación de
software libre. Se observa datos, backup etc.).
que la ca Sustitución de renovación de
licencias. Economía en la
pacitación de las diferencias
Red-ITI de aproximadamente
de softwarelibre y software
R$80.000,00 (para 50
propietario son más
estaciones y notebooks).
concisas y de costo menor de
que entrenamientos
completos como si los
usuarios estuviesen
aprendiendo el uso de una
nueva herramienta.
Adquisición de nuevos Acompañamiento de licencias Economía en las licitaciones

desktops y notebooks de uso con software con equipa mientos (desktops y
propietario. Adquisición sin notebooks) con periféricos con
software instalado. 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: guialivre@planejamento.gov.br 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 - GLO S ARI O
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" %- 3 6 " 0 - !
! 2 2 2 !
% 53" 2 2 2 72 8 9
& # 2 :! -3 6 " 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

Open Source Brasil

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Open Source Brasil

Uploaded by

Copyright:

Available Formats

Guía Libre

Referencia de Migración para Software Libre

Versión 0.96 Beta - Mercosul Página 1

Versión 0.96 Beta - Mercosul Página 2

Este es un trabajo colectivo, unión de esfuerzos de cerca de 50 personas que integran el

Versión 0.96 Beta - Mercosul Página 3

Aunque originalmente el espectro de las actividades del grupo estuviera restricto a

Versión 0.96 Beta - Mercosul Página 4

Fecha Versión Autor Alteración

Versión 0.96 Beta - Mercosul Página 5

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

La comisión de redacción buscó atender a todos titulares de derechos autorales de partes

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

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

Versión 0.96 Beta - Mercosul Página 6

Creemos que, de esta manera, estamos garantizando la participación de la Sociedad en este

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

Versión 0.96 Beta - Mercosul Página 7

Secretaria de Logística y Tecnología de Información Versión 0.5, 0.9 y 0.95

0.3 DERECHOS AUTORALES

Gobierno Brasileño – la reproducción es autorizada desde que la fuente sea reconocida, de

Versión 0.96 Beta - Mercosul Página 8

0.1 Histórico del documento ....................................................................................................... 5

Versión 0.96 Beta - Mercosul Página 9

Versión 0.96 Beta - Mercosul Página 10

Versión 0.96 Beta - Mercosul Página 11

Versión 0.96 Beta - Mercosul Página 12

Versión 0.96 Beta - Mercosul Página 13

1.1 Abreviaturas y terminología

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

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

Versión 0.96 Beta - Mercosul Página 14

El Gobierno Brasileño agradece a la Comunidad Europea por el trabajo que subsidió a la

Versión 0.96 Beta - Mercosul Página 15

Versión 0.96 Beta - Mercosul Página 16

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

2.1.1 Sociedad de Información

• Mercado, trabajo y oportunidades;

Versión 0.96 Beta - Mercosul Página 17

2.1.2 Gobierno Electrónico Brasileño

El Gobierno Electrónico fue concebido como un instrumento de transformación de la

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

De esa forma, se hizo necesaria una rearticulación de las acciones inicialmente

Versión 0.96 Beta - Mercosul Página 18

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

• Promoción de la ciudadanía como prioridad;

En ese nuevo contexto, la actuación del Gobierno Electrónico objetiva la mejora de

2.1.4 Padrones de Interoperabilidad del Gobierno Electrónico

Con la intención de crear mecanismos capaces de promover la eficiencia de la

Versión 0.96 Beta - Mercosul Página 19

Además de la preocupación en garantizar los padrones de interoperabilidad previstos,

Versión 0.96 Beta - Mercosul Página 20

“Software Libre es el software disponible, gratuita o comercialmente, con las premisas de

Otro factor relevante se refiere a socialización del conocimiento. El acceso al código

El conocimiento se tornó, hoy más que en el pasado, uno de los principales

2.2.2 Razones para adopción de Software Libre

Versión 0.96 Beta - Mercosul Página 21

La cuestión de Software Libre está inserida en un amplio escenario integrado, compuesto

Delante del contexto presentado, se tornó fundamental la creación de un documento con

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