licenciamiento. En cuanto a la solución de correo electrónico actualmente implementada, Groupwise 6.2 sobre Novell, entra en este proceso, pero con consideraciones especiales.

Estos servidores presentan una configuración similar a nivel de hardware, en los siguientes cuadros resumimos sus características técnicas:

Cuadro N° 15

Configuración del servidor No. 1

Nombre	DI2000
Marca	HP
Modelo	LH4
Procesador	2 procesadores Intel Pentium III de 500 MHZ
Sistema de almacenamiento	RAID 5 conformado por 4 discos de 9GB
Capacidad de almacenamiento	27GB
Capacidad libre de disco	6GB
Memoria	512 MB
Tarjeta de Red	HP NetServer 10/100TX
Protocolos instalados	IP, IPX
Configuración de Red	IP 10.77.XX.XX, IPX 01.01.XX.XX (no se muestra completamente por razones de seguridad)
Jerarquía dentro del NDS	Primario
Servicios	Impresión, archivos compartidos y aplicaciones
Departamento que presta servicios	Dirección de Informática
Número de usuarios	30

Cuadro N° 16

Configuración del servidor No.2

Nombre	DE2000
Marca	HP
Modelo	LH4
Procesador	2 procesadores Intel Pentium III de 500 MHZ
Sistema de almacenamiento	RAID 5 conformado por 4 discos de 9GB
Capacidad de almacenamiento	27GB
Capacidad libre de disco	4GB
Memoria	512 MB
Tarjeta de Red	HP NetServer 10/100TX
Protocolos instalados	IP, IPX
Configuración de Red	IP 10.77.XX.XX, IPX 01.01.XX.XX (no se muestra completamente por razones de seguridad)
Jerarquía dentro del NDS	Secundario
Servicios	Impresión, archivos compartidos y aplicaciones
Departamento que presta servicios	Dirección General de Control de Estados y Municipio, Dirección General Técnica, Oficina de Atención al Ciudadano, Contralor General
Número de usuarios	208

Cuadro N° 17

Configuración del servidor No.3

Nombre	DA2000
Marca	HP
Modelo	LH4
Procesador	2 procesadores Intel Pentium III de 500 MHZ
Sistema de almacenamiento	RAID 5 conformado por 4 discos de 9GB
Capacidad de almacenamiento	27GB
Capacidad libre de disco	3GB
Memoria	512 MB
Tarjeta de Red	HP NetServer 10/100TX
Protocolos instalados	IP, IPX
Configuración de Red	IP 10.77.XX.XX, IPX 01.01.XX.XX (no se muestra completamente por razones de seguridad)
Jerarquía dentro del NDS	Secundario
Servicios	Impresión, archivos compartidos y aplicaciones
Departamento que presta servicios	Dirección General de Control de la Administración Central y Descentralizada
Número de usuarios	450

Cuadro N° 18

Configuración del servidor No. 4

Nombre	DD2000
Marca	HP
Modelo	2 procesadores Intel Pentium III de 500 MHZ
Procesador	RAID 5 conformado por 4 discos de 9GB
Sistema de almacenamiento	27GB
Capacidad de almacenamiento	12GB
Capacidad libre de disco	5GB
Memoria	512 MB
Tarjeta de Red	HP NetServer 10/100TX
Protocolos instalados	IP, IPX
Configuración de Red	IP 10.77.XX.XX, IPX 01.01.XX.XX (no se muestra completamente por razones de seguridad)
Jerarquía dentro del NDS	Secundario
Servicios	Impresión, archivos compartidos y aplicaciones
Departamento que presta servicios	Dirección de administración, Dirección de recursos humanos, Dirección General de los Servicios Jurídicos, Dirección de Averiguaciones Administrativas
Número de usuarios	104

Cuadro N° 19

Configuración del servidor No.5

Nombre	CGRMAIL90
Marca	HP
Modelo	LH3
Procesador	2 procesadores Intel Pentium III de 500 MHZ
Sistema de almacenamiento	RAID 5 conformado por 4 discos de 9GB
Capacidad de almacenamiento	27GB
Capacidad libre de disco	8GB
Memoria	512 MB
Tarjeta de Red	HP NetServer 10/100TX
Protocolos instalados	IP
Configuración de Red	IP 10.77.XX.XX (no se muestra completamente por razones de seguridad)
Jerarquía dentro del NDS	Primario
Servicios	Sistema de correo
Departamento que presta servicios	Toda la comunidad usuaria

El sistema de archivo es similar para cada servidor, su configuración viene dada por su división en volúmenes, y estos a su vez contienen las carpetas o directorios. Cada servidor contiene cuatro volúmenes, la siguiente tabla describe los nombres y función de cada uno de ellos:

Volúmenes de los servidores Novell

SYS	Contiene los archivos del sistema operativo, archivos de configuración, módulos que permiten el funcionamiento del servidor.
APL	Contiene los archivos de las aplicaciones especificas, formatos para comunicaciones internas y externas, y otras utilidades
DAT	Contiene los directorios de cada usuario (Home Directory) y datos no estructurados.
TEM	Contiene archivos temporales y los trabajos de impresión o colas de impresión

Es importante destacar la posibilidad de utilizar dos servidores adicionales y un Desktop, para el desarrollo del proyecto, los cuales se describen a continuación:

Cuadro N° 20

Configuración del servidor disponible No.1

Nombre	ALPHA
Marca	Digital
Modelo	Alpha Server
Procesador	Alpha
Sistema de almacenamiento	SCSI
Capacidad de almacenamiento	4GB
Memoria	512 MB
Tarjeta de Red	Digital 10/100

Cuadro N° 21

Configuración del servidor disponible No.2

Nombre	MIGRACION
Marca	COMPAQ
Modelo	PROLINEA 2500
Procesador	2 procesadores Intel Pentium Pro
Sistema de almacenamiento	RAID 5 conformado por 4 discos de 4.5GB
Capacidad de almacenamiento	18GB
Memoria	128 MB
Tarjeta de Red	10/100

Cuadro N° 22

Configuración del Desktop disponible

Nombre	BETA
Marca	HP
Modelo	VECTRA VL 8
Procesador	Pentium 4
Capacidad de almacenamiento	20 GB
Memoria	127 MB
Tarjeta de Red	10/100

Determinación de factibilidades

Factibilidad se refiere a la disponibilidad de recursos. Sirve para recopilar datos relevantes sobre el desarrollo del proyecto y en base a ello tomar la mejor decisión, si procede su estudio, desarrollo o implementación.

Factibilidad Técnica.

La plataforma informática de la Contraloría General de la República (CGR) a nivel de hardware tiene la capacidad de soportar la implementación de esta propuesta, además el software libre, se caracteriza por no requerir en la mayoría de los casos de grandes capacidades de hardware, por ende la (CGR) tiene la capacidad técnica para tomar como base este tipo de software y ejecutar la migración. La filosofía del software libre es un movimiento que se basa en el conocimiento público, lo cual permite poseer la información necesaria como: en forums publicados en Internet, artículos técnicos, que detallan como hacer la instalación e implementación de los diferentes software, lo cual se traduce en un gran apoyo para emprender un proyecto de esta magnitud, adicionalmente existen comunidades en Internet que mantienen páginas con información de experiencia obtenida en distintos ambientes, donde se realizaron las instalaciones o migraciones, así como sus resultados.

Es importante el respaldo técnico, que en un momento dado puedan prestar las empresas especializadas en soporte tecnológico, existe una tendencia a nivel nacional e internacional de empresas dedicadas a proveer soluciones tecnológicas para la adaptación del software libre dentro de sus productos. Además en Venezuela se ha comenzado una serie campañas dirigidas a las certificaciones de estudios especializados en el software libre, Linux y otros software asociados a este movimiento.

La experiencia de la implementación del software libre, en el sector público en países como, Argentina y Alemania,(ver anexo B) se encuentran disponibles en la Internet permitiendo obtener información técnica en cada uno de los casos, además es buen antecedente para establecer la factibilidad técnica de nuestro proyecto.

Factibilidad Económica.

El factor económico, es la principal ventaja del software libre frente al software propietario, ya que no se requiere de una inversión considerable en gastos de licenciamiento, además, la propuesta no incluye la adquisición de un hardware adicional al que ya se posee, como dato comparativo, el mantenimiento de licencias de Novell asciende a ochenta mil (80.000) dólares, contra el costo alrededor de ochocientos (800) dólares de una distribución empresarial de Linux, como se puede observar la diferencia es demasiado grande en las inversiones.

Así mismo, el intercambio de conocimiento y experiencias se ofrecen gratuitamente a través por Internet. La inversión debe enfocarse en la preparación del personal técnico que apoyara a la migración y mantenimiento de la nueva plataforma informática, la cual esta contemplada en la partida presupuestaria de la organización.

Factibilidad Operativa

A nivel de servidores la factibilidad operativa de realizar la migración, esta sustentada por el control. El software libre es en general es más robusto que sus contrapartes propietarias, sencillamente porque cuando los usuarios encuentran un defecto lo pueden arreglar o hacer arreglar de acuerdo a sus propios intereses. Y al ser la corrección libre, al igual que el programa original, basta con que algún usuario en el planeta encuentre méritos para resolver el problema para que esté solucionado para todos los demás. El usuario puede adaptar el programa a sus necesidades sin pedirle permiso a nadie, eligiendo plazos, presupuestos y proveedores de acuerdo a sus posibilidades y prioridades, y resolviendo sus problemas de una vez por todas, en vez de continuar luchando contra ellos cotidianamente. El personal técnico de la organización está dispuesto enfrentar este reto, ya que aporta la posibilidad de un crecimiento profesional para ellos.

A nivel de desktop, para una migración de este tipo, su principal debilidad esta en enfrentarse a la resistencia al cambio que se impone por parte de los usuarios. Todo ello debido a que son muchos años de interactuar con el software propietario, en especial con el software Microsoft (Windows, Office), como única solución disponible. Aunado a la costumbre de su interfaz, esto asociado al miedo de enfrentar nuevas posibilidades, lo que hace a la migración de todos los desktop un proyecto a largo plazo, sin embargo, en nuestra propuesta indicamos o tomamos como muestra un pequeño número de desktop, con usuarios específicos, que permitirá establecer el piloto para la migración de cada una de las estaciones de trabajo.

Rutas o mecanismo de migración

Se plantea dos rutas posibles a seguir para la migración de un ambiente de software propietario a un ambiente basado en software libre. A continuación se presenta gráficamente en N° 5 y 6 estas rutas:

Gráfico N° 5

Gráfico N° 6

La ruta numero 1 la consideramos la más segura porque se establece un tiempo para realizar las pruebas en el cliente antes de ir a un ambiente libre exclusivamente.

Consideraciones generales.

Existe mucha similitud entre el software propietario y el software libre. Esto es una ventaja en el momento de remplazarlo. En particular, la interfaz gráfica de usuario (GUI) tiene que proponer un estándar ya conocido para los usuarios finales, con lo cual reduce los problemas al moverlos de un sistema a otro.

Sin embargo, los usuarios finales necesitan de un entrenamiento, esto ayudará a identificar las diferencias y mejoras del sistema nuevo con respecto al sistema saliente. Detrás de la apariencia similar de las (GUI), existe una marcada diferencia entre el software propietario, Windows y Novell, con el software libre, la cual, amerita un adiestramiento particular para los administradores, donde la (GUI) no son relevantes, ya que la administración más efectiva se realiza por medio de línea de comando y herramientas como los denominados script, automatización de procesos, administración remota y control avanzado. Este adiestramiento debe ser planeado para el proceso de transición.

Uso del Username

Se debe mantener la estructura ya implementada, es decir, la primera letra del nombre y luego el apellido, por ejemplo:

Usuario: Rosa Pérez

Username: Rperez

Esta es una estructura establecida en la organización la cual no debe cambiar.

Uso del Password

Es importante resaltar que la migración de password de un sistema a otro no es posible, es necesario regenerar todos los password de los usuarios.

Servicio de autentificación

Cualquier Red que tenga un número considerable de computadores, necesita nombrar y autentificar los servicios. En Novell Netware esto se conoce como (NDS). La mayoría de los sistemas Unix y los sistemas de código abierto pueden trabajar con la mayoría de los servicios de autentificación. GNU/Linux es particularmente robusto en este sentido. El servicio propuesto en este documento es basado en LDAP, pero es posible el uso de múltiples autentificadores siendo útil durante la fase de transición.

Archivos

Un aspecto importante en cualquier plan de transición, es la migración de los datos de un sistema viejo a un sistema nuevo. Si se planificó el cambio de un momento a otro, apagar el sistema viejo y encender el nuevo sería lo ideal, pero lo más probable es mantener dos instancias corriendo paralelamente, el cruce de la información entre las dos plataformas será necesaria. Esto amerita un gran cuidado para evitar pérdida de los datos y confusión, que puede resultar por la manipulación de copias separadas de archivos entre los ambientes viejos y nuevos.

Nombre de los Archivos

Los nombres de los archivos en los sistemas de Windows o Novell, no son sensibles a las letras mayúsculas y minúsculas (case-insensitive), aplicaciones como el Windows colocan mayúscula la primera letra del nombre del archivo y puede tenerlo a lo largo del nombre por modificaciones del usuario consiente o inconscientemente, además pueden tener espacios en blanco.

Unix y los sistemas de código abierto no utiliza las letras de los drivers, y no requiere el nombre real de los servidores de archivos para obtener la ruta absoluta de los nombres de archivos, en cambio el sistema presenta todos los archivos como parte de una estructura jerárquica, conjuntamente con el uso de Links simbólicos en el sistema de archivos. Esta característica permite a los administradores gran flexibilidad en separar el nombre absoluto de los archivos de la localidad física del almacenamiento, en la mayoría de los casos todos los nombres de archivos pueden migrarse directamente a los sistemas de código abierto, con la excepción de los archivos que contengan el carácter “/”, esto va a necesitar la modificación durante la transición.

Acceso Dual

En el proceso de la migración ocurre un período donde se ejecuta paralelamente los dos sistemas, algunos usuarios utilizan el sistema de código abierto mientras otro grupo ejecuta el sistema propietario. Cuando ambos grupos necesiten acceder a los archivos, es necesario establecer mecanismos especiales para ello.

El mecanismo de acceder archivos a través de la Red utilizado por los sistemas de código abierto es el Network File System (NFS), que es un protocolo muy simple a diferencia de otros como por ejemplo el de Windows denominado Server Message Block (SMB). La opción a implementar en nuestro diseño, es instalar en los clientes de Windows el software Samba, este es un software maduro con excelente desarrollo que nos permitirá dar respuesta al requerimiento de acceder a los archivos en los servidores migrados.

Herramientas a implementar

En esta sección se presentarán las herramientas que nos permitirán realizar una migración apropiada a un software libre.

AMANDA

El Archivador de Disco de Red Automatizado Avanzado de Maryland ('Advanced Maryland Automated Network Disk Archiver'), es una utilidad de dominio público desarrollada en la Universidad de Maryland. Es tan avanzado como puede ser una utilidad propietaria de copias de seguridad, y cuenta con un gran número de usuarios. AMANDA permite establecer un único servidor de copias de seguridad para salvaguardar datos de múltiples máquinas en un mismo dispositivo de copia (también trabaja con un número de stackers o apiladores de cintas). AMANDA usa programas de copia nativos (GNU/tar), y puede hacer copias de un gran número de estaciones clientes corriendo múltiples versiones de Unix o Linux. Las versiones más recientes también puede usar SAMBA para hacer copias de máquinas Windows (95/98/NT/2000). Se puede encontrar más información sobre AMANDA en http://www.amanda.org.

AMANDA fue escrito originalmente por James da Silva del Departamento de Ciencias de la Computación de la Universidad de Maryland en 1992. El objetivo era crear un sistema capaz de hacer copias de seguridad de múltiples clientes en una única máquina servidora de copias de seguridad.

OpenWebmail

Es un software que permite el acceso a correo bajo una interfaz Web, escrito en el lenguaje Perl. Entre sus principales características se destacan una interfaz muy intuitiva, un desempeño bastante ágil y una serie de herramientas complementarias (búsquedas avanzadas, calendario, disco Web) muy útiles y que hacen de este programa una herramienta muy completa para su uso en ambientes de oficina.

KDE

Es un escritorio contemporáneo y transparente a la red para estaciones de trabajo UNIX o Linux. KDE pretende paliar la necesidad de un escritorio fácil de usar para las estaciones de trabajo UNIX o Linux, de forma similar a lo que se puede encontrar usando MacOS o Windows95/NT.

Sendmail

Es uno de los programas de transporte de correo más utilizados y que mejor se integran en sistemas UNIX (herramientas y aplicaciones). La legendaria reputación de que sendmail es difícil de comprender, duro de configurar y plagado de agujeros de seguridad se está quedando poco a poco en eso, actualmente evoluciona volviéndose más dócil, comprensible y corrigiendo sus propios errores.

Apache

El Proyecto Apache es un esfuerzo de desarrollo de software en colaboración destinado a crear un servidor HTTP (servidor Web) robusto, comparable a los comerciales y con muchas características y que permita disponer gratuitamente de su código fuente. El proyecto está gestionado conjuntamente por un grupo de voluntarios diseminados por todo el mundo, usando Internet y la Web para comunicarse, planear y desarrollar el servidor y la documentación correspondiente. Estos voluntarios son conocidos como el el Grupo Apache (Apache Group).Además, cientos de usuarios contribuyen al proyecto con ideas, código y documentación.

Samba

Samba es una suite de aplicaciones que habla el protocolo SMB (Server Message Block). Muchos sistemas operativos, incluídos Windows y OS/2, usan SMB para operaciones de red cliente-servidor. Mediante el soporte de este protocolo, Samba permite a los servidores Linux entrar en acción, haciendo que este interactúe con los directorios de Microsoft Windows o Novell Netware. De este modo, una máquina Linux con Samba puede enmascararse como servidor en la red Microsoft o Novell y ofrecer los siguientes servicios:

Compartir uno o más sistemas de archivos.

Compartir impresoras, instaladas tanto en el servidor como en los clientes.
Ayudar a los clientes, con visualizador de clientes de red.

OpenLDAP

OpenLDAP ha sido desarrollado por un conjunto de personas, algunas conocidas como el líder del proyecto Debian, Ben Collins o el desarrollador español Julio Sanchez Fernandez. OpenLDAP cuenta en este momento con:

Slapd
Un servidor para recibir las peticiones LDAP, servirlas y gestionarlas. Es el núcleo del proyecto y lo que implementa las funciones básicas de LDAP.
Slurpd
Un demonio que sirve para replicar un directorio LDAP. Por el momento OpenLDAP solo permite la replicación de un árbol entero sin replicar ninguna de sus partes.
Librerías y utilidades OpenLDAP, provee una serie de librerías (en C) y utilidades para el acceso al directorio, que también forman parte de su proyecto, de esa manera se aporta una solución integral al manejo del directorio en cuanto a sencillas aplicaciones y librerías de programación.

La versión estable en este momento es la versión 2.0.7 y dentro de sus objetivos a cumplir están algunos tan interesantes, como el soporte de transacciones para el backend de LDAP, implementar una mejor concurrencia y completar todo el estándar LDAPv3.

Vemos que el proyecto OpenLDAP en el que se integra la acción de trece (13) personas y de muchas más individuales que constituyen el equipo de desarrollo, es una prueba más de la impresionante fuerza que puede realizar un entorno de software libre en cuanto a colaboración.

Por otra parte, está el papel de la OpenLDAP foundation, la cual contribuye al desarrollo y uso de OpenLDAP, proporciona hosting para páginas de proyectos opensource con LDAP y sponsorización para los mismos, con esta Fundación contribuyen patrocinadores tan importantes como SuSe, el Internet Software Consortium o la empresa net Boolean.

Migración de los Servidores

La migración de los servidores, se debe realizar siguiendo un procedimiento que a continuación describiremos; el mismo se diseño para disminuir el impacto en la comunidad usuaria, sin que estos pierdan la continuidad de los servicios en red.

Este diseño se presentará en modo genérico y uno modo detallado, el cual tendrá configuraciones de ejemplo para los principales paquetes o software a implementarse.

Con la identificación de los servidores disponibles y desktop, así como los servidores en producción, es necesario enumerarlos para así ser mas explícitos en la demostración del diseño.

Servidor	Numeración	Estado
DI2000	1	Producción
DE2000	2	Producción
DA2000	3	Producción
DD2000	4	Producción
CGRMAIL90	5	Producción
ALPHA	6	Disponible
MIGRACION	7	Disponible
BETA	8	Disponible

Diseño genérico

Gráfico N° 7

Proceso N1. Instalación Servidor ALPHA

Gráfico N° 8

Proceso N2. Instalación Servidor Beta

Gráfico N° 9

Proceso N3. Instalación Servidor Migración

Gráfico N° 10

Proceso N4. Instalación Servidor N° 5 como servidor DI2000

Esta operación se repite para los servidores restantes N° 2, 3, 4, quedando un servidor libre al final del ciclo, el cual será destinado para el servicio de correo definitivo. Para ello se debe realizar la migración al mismo nivel del servidor N° 7 al N° 5.

Diseño detallado

Proceso general para todos los servidores en la instalación de Linux

I Instalación de Sistema Operativo (SO) Linux en el servidor No. 1

i. Esquema de particionamiento

Nombre	Punto de montaje	Tipo de File system	Tamaño
/boot	/	ext2	64MB
/		ext2	4GB
/apl	/apl	ext3	4GB
/home	/home	ext3	9GB
/swap		Swap-linux	1GB

ii. Instalación del sistema operativo (distribución SuSe 9.0)

iii. Configuración de interfaz de Red

iv. Paquetes por defecto (KDE, Perl, PHP, Apache, Cliente de Amanda)

v. Servicios de sincronización de tiempo.

Proceso N1

1. Configuración y migración de los servicios DNS, DHCP y servicios de respaldo

1.1. Instalación sistema operativo LINUX en el servidor ALPHA

1.2. Configuración de servicios DNS (ver codificación página 92 )

1.3. Configuración de servicios DHCP (ver codificación página 92)

1.4. Configuración servicios de respaldo Amanda. (ver codificación página 106)

1.5. Control y mantenimiento

Proceso N2

2.1 Instalación y configuración servidor Beta

2.1.1Configuración del servicio del tiempo para sincronización con los servidores Novell Netware.

2.2 Configuración del servicio LDAP

2.2.1 Depuración del árbol NDS

2.2.2 Evaluación de objetos sujetos a migración usuarios, grupos, campos de información a migrar (login, primer nombre, primer apellido, cargo, departamento, ubicación, teléfono, email).

2.2.3 Instalar y configurar el servidor LDAP (ver codificación página 94)

2.2.4 Probar con una aplicación (ejemplo, TUTOS) el funcionamiento

2.2.5 Migrar data al servidor LDAP

2.2.6 Prueba y control de los servicios LDAP, paralelo con los servicios NDS. En un laboratorio piloto.

2.2.7 Colar en producción hasta el final del proyecto.

Proceso N3

3. Instalación y configuración Linux para el servicio de correo (SENDMAIL).

3.1. Instalar (S.O) Linux en el servidor Migración

3.2. Configuración servidor Web, Apache (ver codificación página 97)

3.3. Configuración del servicio SENDMAIL (ver codificación página 100)

3.4. Instalación y configuración del cliente OpenWebmail. (ver codificación página 100)

3.5. Prueba de funcionamiento.

3.6. Adiestramiento a la comunidad usuario.

3.6.1. Respaldo de buzones de correo, realizado por cada usuario

3.6.2. Inducción del funcionamiento en la nueva interfaz Web.

3.7. Colocar en producción nuevo sistema de correo.

3.8. Control y mantenimiento.

3.9. Desactivar servicio de correo Groupwise.

3.10. Colocar en producción nuevo servidor de correo

Proceso N4

4. Migración del servidor DI2000

4.1. Respaldo de volúmenes APL y DAT

4.1.1. Proceso general para todos los servidores en la instalación Linux

4.1.2. Instalación SAMBA (ver codificación página 103)

4.1.2.1. Servicios de directorio y servicios de impresión.

4.1.2.2. Servicios de aplicaciones.

4.2. Control y mantenimiento.

4.3. Colocar en producción nuevo servidor DI2000

Proceso N5

5. Migración del servidor DE2000

5.1. Respaldo de volúmenes APL y DAT

5.1.1. Proceso general para todos los servidores en la instalación Linux

5.1.2. Instalación SAMBA (ver codificación página 103)

5.1.2.1. Servicios de directorio y servicios de impresión.

5.1.2.2. Servicios de aplicaciones.

5.2. Control y mantenimiento.

5.3. Colocar en producción nuevo servidor DE2000

Proceso N6

6. Migración del servidor DA2000

6.1. Respaldo de volúmenes APL y DAT

6.1.1. Proceso general para todos los servidores en la instalación Linux

6.1.2. Instalación SAMBA (ver codificación página 103)

6.1.2.1. Servicios de directorio y servicios de impresión.

6.1.2.2. Servicios de aplicaciones.

6.2. Control y mantenimiento.

6.3. Colocar en producción nuevo servidor DA2000

Proceso N7

7. Migración al mismo nivel del servidor N° 7 al N° 5

7.1. Migración de los servicios de correo a su lugar definitivo

Migración de los clientes Windows conjuntamente con aplicaciones

Luego de instalar el primer servidor Linux, se debe configurar un desktop piloto, al cual se le debe realizar todas las pruebas posibles de funcionamiento. Las aplicaciones ha instalar son las siguientes:

Para el entorno gráfico, se utilizará para una muestra de los clientes el software KDE 3.2.

Para el software de automatización de oficina se reemplazará Microsoft Office por OpenOffice, y como navegador de Internet se empleará Mozilla.

Otras Soluciones

En la comunidad de software libre, existen numerosas soluciones que se pueden adaptar a la Contraloría General de la República (CGR).  Una de ellas fue probada y demostró ser una potencial solución. Se trata de TUTOS (The Ultimate Team Organisation Sofware), es una aplicación bajo Web, la cual se especializa en la administración de proyectos.

Configuración y Codificación de los servicios

Para esta sección, las configuraciones relacionadas con direcciones IP, no se mostrarán completamente o no acorde a la realidad, por razones de seguridad y confidencialidad

Servicios DHCP

El servicio de DHCP es muy fácil de configurar, el archivo de configuración es el dhcpd.conf ubicado el directorio /etc, en este archivo colocamos los rango de direcciones disponibles para la red local. Por ejemplo:

ddns-update-style none;

Subnet 10.77.xx.0 netmask 255.255.248.0 {

range 10.77.xx.3 10.77.xx.254;

range 10.77.xx.0 10.77.xx.254;

default-lease-time 604800;

max-lease-time 1209600;

option subnet-mask 255.255.248.0;

option broadcast-address 10.77.xx.255;

option routers 10.77.xx.1;

option domain-name-servers 10.77.xx.x;

option domain-name "cgr.gov.ve";

Servicios DNS

DNS es el Sistema de Nombres de Dominio (Domain Name System), las reglas de nomenclatura de las máquinas y el software que enlaza los nombres a números IP. Una conversión es simplemente una asociación entre dos cosas, en este caso un nombre de máquina, como DE2000.cgr.gov.ve a una dirección, 10.77.8x.XX.

Archivos de configuración

El archivo /etc/named.boot donde configuramos nuestro propio dominio, ejemplo

cgr.gov.ve

directory /etc/named.d

primary cgr.gov.ve named.hosts

cache . root.cache

primary 82.77.10.in-addr.arpa named.rev

primary 83.77.10.in-addr.arpa named1.rev

primary 80.77.10.in-addr.arpa named2.rev

primary 81.77.10.in-addr.arpa named3.rev

primary 84.77.10.in-addr.arpa named4.rev

primary 85.77.10.in-addr.arpa named5.rev

primary 86.77.10.in-addr.arpa named6.rev

primary 87.77.10.in-addr.arpa named7.rev

primary 0.0.127.in-addr.arpa named.local

;forwarders 161.196.66.2

Configuración del archivo /etc/named.d/named.soa

@ IN SOA alpha.cgr.gov.ve. root.alpha.cgr.gov.ve. (

9.48 ; Serial

10800 ; Refresh

1800 ; Retry

3600000 ; Expire

86400 ) ; Minimum

IN NS alpha.cgr.gov.ve.

Configuración del archivo /etc/named.d/named1.rev

$INCLUDE named.soa

1.in-addr.arpa IN PTR dummyb1.cgr.gov.ve

2.in-addr.arpa IN PTR dummyb2.cgr.gov.ve

3.in-addr.arpa IN PTR dummyb3.cgr.gov.ve

4.in-addr.arpa IN PTR dummyb4.cgr.gov.ve

5.in-addr.arpa IN PTR dummyb5.cgr.gov.ve

6.in-addr.arpa IN PTR dummyb6.cgr.gov.ve

7.in-addr.arpa IN PTR dummyb7.cgr.gov.ve

8.in-addr.arpa IN PTR dummyb8.cgr.gov.ve

9.in-addr.arpa IN PTR dummyb9.cgr.gov.ve

10.in-addr.arpa IN PTR dummyb10.cgr.gov.ve

11.in-addr.arpa IN PTR dummyb11.cgr.gov.ve

12.in-addr.arpa IN PTR dummyb12.cgr.gov.ve

Servicios LDAP

El servicio LDAP se obtendrá por medio del paquete OpenLDAT, el cual contiene:

Ldapadd: abre una conexión a un servidor LDAP, enlaza y añade entradas.

ldapcompare abre una conexión a un servidor LDAP, enlaza y hace una comparación usando los parámetros especificados.

ldapdelete abre una conexión a un servidor LDAP, enlaza y borra una o mas entradas.

ldapmodify abre una conexión a un servidor LDAP, enlaza y modifica entradas.

ldapmodrdn abre una conexión a un servidor LDAP, enlaza y modifica el RDN de las entradas.

ldappasswd es una herramienta para establecer la contraseña de un usuario LDAP.

ldapsearch abre una conexión a un servidor LDAP, enlaza y hace una búsqueda usando los parámetros especificados.

ldapwhoami abre una conexión a un servidor LDAP, enlaza y realiza una operación whoami.

slapadd se usa para añadir entradas especificadas en el formato Intercambio de Directorio de LDAP (LDIF) en una base de datos slapd.

slapcat Se usa para generar una salida LDAP LDIF basada en el contenido de una base de datos slapd.

slapd es el servidor LDAP independiente.

slapindex se usa para regenerar índices slapd basados en el contenido actual de una base de datos.

slappasswd es una utilidad de contraseñas OpenLDAP.

slurpd es el servidor réplica LDAP independiente.

liblber y libldap estas librerías dan soporte a los programas LDAP y suministran funcionalidad a otros programas que interactúan con LDAP.

Archivos de configuración

slapd.conf

Este es el archivo principal de OpenLDAP y es aquí donde se configuran todos sus parámetros, ubicado en el directorio /etc/openldap.

Parámetros globales

Los parámetros dentro de esta sección afectan el funcionamiento de todo el Servidor OpenLDAP, cualquier definición antes de un parámetro database es considerado global, cabe mencionarse que los valores de parámetros globales pueden ser contrarrestados al nivel de bases de datos, esto es, si se define el parámetro access globalmente, es posible alterar el valor de este parámetro en base de datos y el resto de las bases de datos permanecerán con el valor global.

Es importante destacar, en el sentido más estricto de la palabra OpenLDAP no utiliza una base de datos, la "base de datos" utilizada en OpenLDAP es un tipo de archivo plano.

slapd se suministra con tres diferentes bases de datos de backend (dorsal, o base de datos de segundo plano) entre las que elegir. Se trata de LDBM, una base de datos de gran rendimiento basada en disco: SHELL, una interfaz de base de datos para órdenes arbitrarias de UNIX o guiones (scripts) del intérprete de órdenes (shell); y PASSWD, una sencilla base de datos de contraseñas. Para la migración planteada, se ha elegido la base de datos LDBM.

Los siguientes son parámetros globales básicos para slapd.conf :

                               include                  /etc/openldap/slapd.at.conf

                               include                  /etc/openldap/slapd.oc.conf

include

Este parámetro indica otros archivos de configuración utilizados por el Servidor OpenLDAP, la declaración anterior carga el archivo slapd.at.conf, lapd.oc.conf.

               referral   ldap://DI2000.cgr.gov.ve

referral

Indica un Servidor LDAP alterno en dado caso de no poderse efectuar la búsqueda en el servidor LDAP actual.

               #access to *  by * write

access to ...: Parámetro utilizado para restringir acceso al servidor LDAP.

pidfile /var/run/slapd.pid

pidfile : Contiene el numero de proceso asignado al servidor LDAP al arranque.

argsfile /usr/local/var/slapd.args

argsfile : Contiene parámetros utilizados en la línea de comandos al iniciar el servidor OpenLDAP.

loglevel 0

loglevel : Indica el nivel de registros ("log") producidos por el servidor LDAP.

El archivo slapd.conf queda como sigue:

# This is the main ldapd configuration file.

# Schema and objectClass definitions

include                  /etc/openldap/slapd.at.conf

include                  /etc/openldap/slapd.oc.conf

# Where clients are refered to if no

# match is found locally

#referral ldap:// DI2000.cgr.gov.ve

# Where the pid file is put. The init.d script

# will not stop the server if you change this.

pidfile                    /var/run/slapd.pid

# Read slapd.conf(5) for possible values

loglevel  0

#######################################################################

# ldbm database definitions

#######################################################################

# The backend type, ldbm, is the default standard

database              ldbm

# The base of your directory

suffix                      "dc= cgr.gov.ve "

# Where the database file are physically stored

directory                "/var/lib/openldap"

cachesize 2000

dbcachesize 5000000

sizelimit 2000

index cn

index uid,allowedServices,email_access,mail eq

index default none

# Save the time that the entry gets modified

lastmod off

# By default, only read access is allowed

defaultaccess       read

# The userPassword by default can be changed

# by the entry owning it if they are authenticated.

# Others should not be able to see it, except the

# admin entry below

access to attribute=userPassword

               by dn="cn=root,dc=cgr.gov.ve" write

               by self write

               by * none

# The admin dn has full write access

access to * by dn="cn=root,dc= cgr.gov.ve " write

# End of ldapd configuration file

Servicios Web Apache

Apache es uno de los pocos servicios que no necesitan de mayores modificaciones después de su instalación a fin de funcionar. De hecho solo se necesita se inicie el servicio y se publiquen las páginas correspondientes.

Apache posee un comando llamado apachectl, el cual facilita el arranque y terminación de Apache.

apachectl start : Inicia el Servidor de Páginas

apachectl stop : Termina el Servidor Apache

apachectl restart : Re-Inicializa el proceso Apache

Al momento de ejecutar cualquier variación de apachectl, se lee el archivo principal de configuración de Apache, httpd.conf, ubicado en el directorio usr/local/apache/conf o etc/http.conf

Todos los parámetros que se incluyan en httpd.conf serán validados previo arranque de Apache, esto es, al ejecutar apachectl start (o apachectl restart); la única excepción a esto son los renglones que inicien con el signo: #, ya que estos indican un comentario.

Debido a la gran cantidad de parámetros modificables en el archivo httpd.conf no serán descritos todos, sin embargo, como ya fue mencionado todos los parámetros poseen valores razonables por defecto.

User, Group, ServerName, Port

Los parámetros User y Group indican el Usuario y Grupo al cual pertenece el proceso de Apache, estos parámetros básicamente indican que usuario será capaz de inicializar y terminar el servidor Apache, por lo general se recomienda generar un usuario y grupo especial para esta tarea.

El parámetro ServerName indica el nombre del Servidor que administra Apache, en otras palabras el sitio en cuestión, en nuestro caso es el, www.cgrmail90.cgr.gov.ve.

DocumentRoot, DirectoryIndex

Los pasos anteriores indican a Apache el nombre del sitio que se administra, sin embargo, aun falta indicar donde se encuentra el contenido de este sitio. El parámetro DocumentRoot indica el directorio local donde reside la información del sitio en cuestión, el valor por defecto en httpd.conf es /usr/local/apache/htdocs, El parámetro DirectoryIndex indica el documento que debe ser enviado al acceder un directorio, generalmente toma el valor de index.html.

            DocumentRoot /usr/local/cgr/

DirecotryIndex index.html, index.htm, index.cgi, home.html

Lo anterior indica que al intentarse acceder cualquier directorio bajo /usr/local/cgr, se intentará enviar el archivo index.html, si este no existe, se intenta con index.htm, seguido de index.cgi, y finalmente si no existiesen ninguno de los anteriores enviar home.html.

Servicios SENDMAIL

Para la instalación y configuración del servicio SENDMAIL, se debe establecer las siguientes premisas:

Primero es establecer como desea recuperar los mensajes de correo electrónico que arriben al servidor. POP3 o IMAP.

POP3: Es el protocolo de recuperación de correo electrónico más utilizado en la actualidad. Permite recuperar el correo pero este se almacenará localmente en el disco duro de las máquinas de los usuarios

IMAP: Este protocolo almacena el correo electrónico, y permite la creación de carpetas de usuario, en el servidor. De modo tal, los usuarios pueden acceder desde cualquier parte del mundo a su buzón de correo y carpetas personales. IMAP también facilita la utilización de webmails (servicios de correo basado sobre Web).Indicar el nombre o aliases que tenga el servidor. En nuestro caso es: mail.cgr.gov.ve

Configurar dos tarjetas, una para la red local, con la IP interna

Dirección interna IP 10.77.X.X

Otra para la dirección IP validad para Internet

Dirección de Internet IP 172.197.X.X (por vía del servicio de la red Platino, red del gobierno)

Verificando parámetros de red.

Se debe definirse el nombre de la máquina que funcionará como servidor de correo. Normalmente se utiliza el esquema nombre_maquina.nombre_dominio. En nuestro caso: cgrmail90.cgr.gov.ve

Se debe asegurar este nombre esté perfectamente definido en: /etc/sysconfig/network y /etc/hosts:

Para /etc/sysconfig/network, es decir, el nombre que asignamos a la máquina, correspondería lo siguiente:

               NETWORKING=yes

               HOSTNAME=cgmail90.cgr.gov.ve

               GATEWAY=172.197.X.X

Para /etc/hosts, es decir, la información de los hosts y las direcciones IP, correspondería lo siguiente:

               # Primero, verificamos que las direcciones IP del

               # servidor estén asociadas correctamente a un nombre

               # largo y uno corto. Los espacios son con tabuladores.

               127.0.0.1                             localhost.localdomain                        localhost

               172.197.X.X         mail.cgr.gov.ve                                   mail

10.77.X.X cgrmail90.cgr.gov.ve cgrmail90

Configuración de SENDMAIL

Antes de continuar, debemos editar el fichero /etc/mail/local-host-names, en el cual deberemos de listar todos y cada uno de los alias que tenga el servidor que estamos configurando, así como los posibles sub-dominios. Es decir, todos los dominios para los cuales estaremos recibiendo correo en un momento dado.

               # Incluya aquí todos los dominios para los que

               # recibamos correo.

               mail.cgr.gov.ve

Procederemos entonces a modificar el archivo /etc/mail/sendmail.mc. Por defecto Sendmail solo permitirá enviar correo solo desde la interfaz loopback (127.0.0.1), es decir, desde el mismo servidor. Si queremos enviar correo desde las máquinas de la red local es necesario comentar la línea o bien, si tiene varias, añada las interfaces desde las cuales se quiere que escuche peticiones sendmail y omita las que no deben, como sería una red local secundaria con restricciones.

dnl DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')

Si queremos filtrar Spam de manera eficiente, la mejor manera de empezar a hacerlo es rechazando correo proveniente de dominios no resueltos, es decir dominios que no están registrados en un DNS y que por lo tanto son inválidos. Para tal fin, a menos que se requiera lo contrario, es necesario mantener comentada la siguiente línea:

dnl FEATURE(`accept_unresolvable_domains')dnl

Es necesario establecer que mail.cgr.gov.ve corresponderá a la máscara que utilizaremos para todo el correo que emitamos desde nuestro servidor. Debe, por tanto, añadirse una línea justo debajo de MAILER(procmail)dnl y que va del siguiente modo:

MASQUERADE_AS(mail.cgr.gov.ve)dnl.

Estas son las directrices principales para el archivo de configuración de SENDMAIL.

Servicios Openwebmail

Para la configuración de Openwebmail es necesario que los servicios de SENDMAIL y Apache estén correctamente instalados y activos, es necesaria la siguiente lista de componentes:

CGI.pm-2.74

MIME-Base64-2.12

libnet-1.0901

Text-Iconv-1.2

libiconv-1.9.1

Luego de compilar e instalar los paquetes en el servidor de cgrmail90, asegurarnos de los permisos de los directorios, continuamos con la configuración del producto, la cual se realiza en el archivo /etc/openwebmail.conf

domainnames cgr.gov.ve

auth_module auth_unix.pl

mailspooldir /var/mail

ow_cgidir /srv/www/cgi-bin/openwebmail

ow_cgiurl /cgi-bin/openwebmail

ow_htmldir /srv/www/htdocs/openwebmail

ow_htmlurl /openwebmail

logfile /var/log/openwebmail.log

spellcheck /usr/bin/aspell

Como siguiente paso incluir en el archivo:

/srv/www/cgi-bin/openwebmail/etc/dbm.conf las siguientes directrices

dbm_ext .pag

dbmopen_ext none

dbmopen_haslock no

De igual modo en el archivo:

/srv/www/cgi-bin/openwebmail/etc/auth_unix.conf las siguientes directrices

passwdfile_plaintext /etc/passwd

passwdfile_encrypted /etc/shadow

passwdmkdb none

check_nologin no

check_shell no

check_cobaltuser no

Para inicializar Openwebmail se debe ejecutar el Script

/srv/www/cgi-bin/openwebmail/openwebmail-tool --init

Los clientes pueden acceder al servicio Openwebmail a través del Browser en los desktop en la siguiente dirección:

http://cgrmail90.gov.ve/cgi-bin/openwebmail/openwebmail.pl

Servicio de archivos e impresión SAMBA

El software requerido para la puesta en marcha de SAMBA son samba, samba-client, samba-common, samba-swat, xinetd.

Procedimientos

Es necesario definir primero los parámetros requeridos, como es el NetBIOS, lo cual permite que el grupo de máquinas Windows identifique el servidor Linux, el grupo al que pertenece y el rango de direcciones IP a las que se permitirá acceder hacia el servidor Linux, esto se indica el archivo /etc/samba/lmhosts:

127.0.0.1 localhost

10.77.8x.xx Servidor-Linux

10.77.x.x Desktop-Windows

Se debe configurar los parámetros necesarios en el archivo smb.conf, archivo de configuración de SAMBA, se establece el grupo de trabajo editando la línea workgroup, de este modo: workgroup = cgr

Después estableceremos, de acuerdo al fichero /etc/samba/lmhosts en la línea del parámetro netbios name: netbios name = Servidor-Linux

Es necesario establecer cierto nivel de seguridad. Primero especificando por cuales interfaces del sistema se escucharan peticiones. Cualquier interfaz omitida significará que Samba no responderá a peticiones provenientes de esa interfaz. Esto es útil cuando Samba se ejecuta en un servidor que sirve también de puerta de enlace para la red local, impidiendo se establezcan conexiones desde fuera de la red local.

interfaces = 10.77.8x.xx/24

Además especificar que rango de direcciones IP podrán acceder al servidor SAMBA, editando la línea hosts allow. La red de la Contraloría General de la República (CGR) consiste en la máquinas con dirección IP desde 10.77.80.X. hasta 10.77.86.X.

Para evitar el registro de Windows en todas las máquinas de la red local, se debe habilitar las siguientes líneas.

encrypt passwords = Yes

smb passwd file = /etc/samba/smbpasswd

Para transmisión de mensajes a toda la red local (broadcast), con el siguiente parámetro. remote announce = 10.77.XX.255

De ser necesario, puede especificar que el servidor sea el "maestro del domino", e incluso sobreponerse a cualquier otro en la red.

domain master = True

preferred master = yes

Puede habilitar convertirse en servidor WINS o bien utilizar un servidor WINS ya existente. Se puede ser un servidor WINS o un cliente WINS, pero no ambas cosas a al vez. Para la configuración del diseño que nos compete, se colocará como servidor WINS

wins support = yes

Lo siguiente es configurar las impresoras y los directorios compartidos. Para tal fin, debemos añadir solo public = yes en la sección de impresoras, de fin que quede del siguiente modo:

[printers]

comment = El comentario que guste.

path = /var/spool/samba

printable = Yes

browseable = No

public = yes

Para los directorios o volúmenes que se irán a compartir, en el mismo archivo de configuración encontrará distintos ejemplos para distintas situaciones particulares. En general, puede utilizar el siguiente ejemplo que funcionará para la mayoría:

comment = Directorios a compartir

path = /apl/aplicaciones; /apl/formas…..

guest ok = Yes

Para la ejecución del programa: /sbin/service smb start

Servicio Swat

Al instalar el paquete samba, este incluye una aplicación que podrá acceder desde cualquier navegador Web, desde cualquier máquina de la red local. Esta aplicación se llama Swat, y solo requiere el paquete samba-swat este instalado

Para acceder a Swat desde otras máquinas en la red local, debe añadir o cambiar la dirección IP de la interfaz por la que desea que Swat escuche peticiones.

service swat

               port    = 901

               socket_type     = stream

               wait    = no

               only_from = 10.77.X.X

               user    = root

               server  = /usr/sbin/swat

               log_on_failure  += USERID

               disable = no

Una vez hecho esto, se debe reiniciar el servicio xinet del siguiente modo: /sbin/service xinet restart

A partir de este momento, se podrá acceder por medio de un navegador Web, a la dirección del servidor Linux y SAMBA en el puerto 901, lo cual presentará el siguiente diálogo e interfaz

Pantalla de login de Swat

Pantalla de bienvenida de Swat

AMANDA software de respaldo

La típica configuración de AMANDA se ejecuta como un usuario distinto a root, como por ejemplo backup o amanda, con los permisos necesarios para relizar copias de seguridad. Frecuentemente, la posibilidad de hacer un login para el usuario que se cree está desactivada. El usuario que controla AMANDA debe estar en un grupo con permisos de lectura contra los dispositivos de copia. El número de miembros en este grupo debería estar muy controlado, ya que tienen permiso para abrir en lectura cada uno de los archivos de los clientes.

Hay dos formas para enlazar AMANDA y el grupo de miembros del dispositivo de copia. Poniendo al usuario AMANDA en el grupo al que actualmente pertenecen los dispositivos de copia, como el grupo primario o el secundario, o creando un nuevo grupo para AMANDA y pasando a este nuevo grupo a los propietarios de los dispositivos. AMANDA.

Para la configuración de AMANDA, es necesario establecer con anterioridad las políticas de respaldo, en ellas se tiene que indicar los siguientes criterios:

Decidir el servidor de cintas, en nuestro caso es el servidor ALPHA

Decidir qué dispositivo de cinta usar, el sistema operativo Linux normalmente incorporan características de los dispositivos en el nombre de archivo usado para acceder a una unidad de cinta. Las dos cosas a controlar son rebobinar “rewind” y compresión “compression”. AMANDA debe ser configurada con el dispositivo de cinta no-rebobinable, llamado así porque cuando el dispositivo es abierto y cerrado permanece en la misma posición y no hace un rebobinado automático. Normalmente es un nombre con una 'n', tal como /dev/nst0.

Decidir si usar Compresión, las imágenes de las copias pueden opcionalmente ser comprimidas en el cliente, el servidor de cintas, o mediante el hardware del dispositivo de cinta. La compresión vía software permite a AMANDA rastrear el uso y hacer mejores estimaciones de los tamaños de las imágenes, pero la compresión hardware es más eficiente en cuanto al consumo de recursos de la CPU.

Decidir dónde estará el espacio de almacenamiento, es necesario establecer espacio disponible para guardar la información, esto reduce significativamente el tiempo de copia, permitiendo la realización de varias copias al mismo tiempo, mientras la cinta se está grabando. Por ejemplo en /var/amanda

Establecer el ciclo de copias, para nuestro diseño es el siguiente, diario, semanal y mensual.

El diario de lunes a jueves, en cuatro cintas distintas: El semanal, los días viernes, en cuatro cintas distinta; El mensual, el último viernes del mes, el cual se mantendrá hasta doce meses

Archivo de configuración.

AMANDA contiene archivo de configuración por defecto ubicados en /usr/local/etc/Amanda, son plantillas de configuración, por ejemplo la denominada Diaria.

Cada cinta asignada a una configuración necesita tener una etiqueta única. Para nuestro ejemplo, usaremos el nombre de la configuración, un guión y un sufijo de tres dígitos, Diaria-000 hasta Diaria-999.

Es necesario copiar la plantilla de ejemplo del archivo example/amanda.conf, al directorio de configuración. Existen muchos parámetros, los cuales podemos resumir:

org

Esta cadena estará en la línea de Asunto (Subject) de los reportes recibidos vía e-mail desde AMANDA.

mailto

Usuarios destinatarios de los reportes que genera AMANDA y envía vía e-mail.

dumpuser

Igual que -with-user en ./configure.

dumpcycle

Ciclo de Copia.

runspercycle

Ejecuciones por ciclo.

tapecycle

Cinta para el ciclo.

runtapes

Número de cintas a usar por ejecución.

tapedev

El dispositivo de cinta no-rewind (no rebobinable) si no se va a usar un cambio de cintas automaticas, o si se va a usar el cambio manual.

tapetype

Tipo de cinta.

netusage

Ancho de banda de la Red asignado a AMANDA.

labelstr

Una expresión regular (grep pattern) usada para garantizar que cada cinta está asignada a esa configuración de AMANDA. Nuestro ejemplo debería usar 'Diaria-[0-9][0-9][0-9]'.

Los siguientes parámetros probablemente no necesitarán ser cambiados, pero mira sus valores para que sepas dónde espera AMANDA encontrar las cosas:

infofile

Localización de la B.D. que contiene el histórico de operaciones de AMANDA. Versiones antiguas de AMANDA usan esto como el nombre base de un archivo de bases de datos. Las nuevas versiones lo usan como nombre de directorio.

logdir

Directorio donde los registros de AMANDA son almacenados.

indexdir

Localización de la base de datos de catálogos (opcional) de AMANDA.

Beneficios de la propuesta

Beneficios Tangibles

El principal beneficio tangible en la implementación de la propuesta es la reducción considerable de los gastos en la adquisición de licencias, también en el mantenimiento, operación y ajuste correspondiente. Para el sector del público es importante mantener los costos bajo control, pues de lo contrario, puede llegar a verse impedido de llevar a cabo sus metas, a fuerzas de erogaciones no planificadas.

Es por ello que hay que brindar la adecuada protección de la inversión en software: ya que los desarrollos siempre son aprovechables para otros, si se licencian de manera "libre"; en el hardware no se necesita reemplazar constantemente; el soporte la experiencia ganada por los técnicos propios puede extenderse a otro tipo de software; en cuanto a capacitación como no existen artificios para ocultar información, puede elegirse a otra empresa que brinde con un precio mas accesible.

Así mismo hay que tomar en cuenta la relación rendimiento/ precio, como el costo del software libre que tiene la ventaja de no obligar a pagar una licencia por cada computadora en la que se instale; costo del hardware, ya que hay software propietario tiene requerimientos excesivos de hardware para funcionar, es decir, no hay relación razonable entre la tarea que realiza y el hardware que requiere; costo de soporte es menor porque cualquiera lo puede ofrecer, si bien es cierto que no tenemos una calidad garantizada; para la capacitación es menor el costo al no estar monopolizada.

Debido a la garantía de continuidad: el software libre puede seguir siendo usado aún después de que haya desaparecido la persona que lo elaboro, dado que cualquier técnico informático puede continuar desarrollándolo, mejorándolo o adaptándolo.

Beneficios Intangibles

El software libre permite al usuario la inspección completa y exhaustiva del mecanismo mediante el cual procesa los datos. El interés en el mecanismo de procesamiento es mucho más que académico. Sin la posibilidad de la inspección, es imposible saber si el programa cumple meramente con su función, o si además incluye vulnerabilidades intencionales o accidentales que permitan a terceros acceder indebidamente a los datos, o impedir que los usuarios legítimos de la información puedan usarlo. Este peligro puede parecer exótico, sin embargo, es muy concreto, y hay antecedentes documentados.

El hecho de permitir la inspección del programa es una excelente medida de seguridad, ya que al estar expuestos los mecanismos, estos están constantemente a la vista de profesionales capacitados, con lo que se vuelve inmensamente más difícil ocultar funciones maliciosas, aún si el usuario final no se toma el trabajo de buscarlas él mismo.

Independencia tecnológica

Son muchas y conocidas las ventajas aportadas por la adopción de herramientas de procesamiento de datos. Pero una vez comenzada la informatización de una tarea, la computadora se vuelve imprescindible, y la tarea pasa a depender de su disponibilidad. Si la institución que usa la aplicación no tiene libertad de contratación en lo que se refiere a ampliaciones y correcciones del sistema, se produce una dependencia tecnológica en la que el proveedor está en condiciones de dictar unilateralmente términos, plazos y precios.

Una forma particularmente desleal de esta dependencia tecnológica se produce a través de la manera en que se almacenan los datos. Si el programa usa un formato de almacenamiento estándar, entonces el usuario puede estar seguro de que en el futuro podrá seguir descifrando la información. Si, por el contrario, los datos se almacenan en un formato secreto, el usuario queda atrapado en un determinado proveedor, que es el único que puede ofrecer alguna garantía de acceso a ellos.

Regresar página principal

PROPUESTA