proyecto fin de carrera - dit.upm.esomar/pfc/proyecto_omar/proyecto_omar.pdf · antecedentes del...

UNIVERSIDAD POLITÉCNICA DE MADRID

ESCUELA TÉCNICA SUPERIOR DEINGENIEROS DETELECOMUNICACIÓN

PROYECTO FIN DE CARRERA

Implementación de un Sistema de Gestión paraLaboratorios Docentes

Sistema de Administración Centralizada

OMAR AURELIO WALID LLORENTE

22 de julio de 2003

UNIVERSIDAD POLITÉCNICA DE MADRID

ESCUELA TÉCNICA SUPERIOR DEINGENIEROS DETELECOMUNICACIÓN

DEPARTAMENTO DE INGENIERÍA DE SISTEMAS TELEMÁTICOS

Implementación de un Sistema de Gestiónpara Laboratorios Docentes


Autor: Omar Aurelio Walid LlorenteTutor: Tomás Pedro de Miguel Moro

Fecha:22 de julio de 2003

Título:

Implementación de un sistema de gestión para laboratorios docentes

Subtítulo:


Autor:

D. Omar Aurelio Walid Llorente

Tutor:

D. Tomás Pedro de Miguel Moro

Profesor Titular de la Universidad Politécnica de Madrid

Tribunal:

Presidente : D. Tomás Pedro de Miguel Moro

Vocal : D. Santiago Pavón Gómez

Secretario : D. David Fernández Cambronero

Suplente : D. Víctor Abraham Villagrá González

Calificación :

Madrid, de de 2003

A mi tía-abuela, a mi madre y a mi hermana.

A Judith, por su apoyo incondicional.

A los que han demostrado ser mis amigos,por escucharme siempre que lo he necesitado.

A todos los miembros del Centro de Cálculo del DIT,por su ilusión y su trabajo, y porque sin ellos,

este proyecto no habría sido posible.

Resumen:

En un sistema académico en el que las necesidades de software son cada día

más cambiantes mientras que los recursos disponibles permanecen estables, re-

sulta necesario encontrar una solución que permita gestionar de forma automáti-

ca y desatendida un gran número de computadores, sus redes, sus servicios y

sus usuarios. Este proyecto pretende ofrecer una solución general y demostrar

su viabilidad mediante su aplicación a los Laboratorios Docentes del Depar-

tamento de Ingeniería de Sistemas Telemáticos (DIT) de la Escuela Superior

de Ingenieros de Telecomunicación (ETSIT) de la Universidad Politécnica de

Madrid (UPM).

Abstract:

In academic systems where the software necessities are changing day by day,

while the available resources are stable, is becoming critical to find a solution

which allows the automatic and unattended administration of a big number of

computers, their data networks, their services and their users. This technical

report tries to offer a general solution and demonstrate its viability at the Grade

Laboratories at Technical University of Madrid’s Telematics Department.

Palabras Clave:

Administración cero, Administración centralizada, Instalación automática,

Instalación desatendida, Administración de sistemas, Administración de redes,

Regeneración de particiones, Arranque de red, PXE, DHCP.

Key Words:

Zero Administration, Centralized Administration, Automatic installation,

Unattended installation, Systems administration, Networks administration, Par-

tition regeneration, Network boot, PXE, DHCP.

Índice general

Índice general I

Índice de tablas V

Índice de figuras VI

1. Introducción 1

1.1. Antecedentes del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3. Sistemas Operativos para Ordenadores PC . . . . . . . . . . . . . . . . . . . . 4

1.4. Análisis de las soluciones disponibles . . . . . . . . . . . . . . . . . . . . . . 4

1.4.1. Entorno GNU/Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.2. Entorno Microsoft Windows . . . . . . . . . . . . . . . . . . . . . . . 7

2. Objetivos 10

2.1. Problemas que se pretenden resolver . . . . . . . . . . . . . . . . . . . . . . . 10

2.2. Requisitos generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3. Requisitos del entorno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3. Discusiones de diseño 18

3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2. Instalación automática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3. Regeneración cruda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.4. Procedimientos desatendidos . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4.1. Estado inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4.2. Fase de arranque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4.3. Fase de comprobación . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4.4. Fase de instalación automática o regeneración cruda . . . . . . . . . . 27

3.4.5. Fase de rearranque . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

I

3.4.6. Fase de finalización . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.4.7. Estado final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4. Arquitectura 28

4.1. Gestión de red local (nivel de enlace) . . . . . . . . . . . . . . . . . . . . . . . 28

4.2. Gestión de red de acceso (nivel de red) . . . . . . . . . . . . . . . . . . . . . . 29

4.3. Gestión de equipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.4. Gestión de arranque de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.5. Gestión de disco local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.6. Gestión de instalaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.6.1. Instalación automática de servidores GNU/Linux . . . . . . . . . . . . 34

4.6.2. Instalación automática de clientes GNU/Linux . . . . . . . . . . . . . 37

4.6.3. Regeneración automática de clientes Windows XP . . . . . . . . . . . 37

4.6.4. Instalación automática de clientes Windows XP . . . . . . . . . . . . . 38

4.7. Gestión de servicios generales . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.7.1. Gestión de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.7.2. Gestión de impresoras . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.7.3. Gestión de sistema de nombres . . . . . . . . . . . . . . . . . . . . . . 41

4.7.4. Gestión de correo electrónico . . . . . . . . . . . . . . . . . . . . . . 41

4.7.5. Gestión de web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.7.6. Gestión de disco de red . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.7.7. Gestión de dispositivos especiales . . . . . . . . . . . . . . . . . . . . 43

4.7.8. Gestión de reserva de equipos . . . . . . . . . . . . . . . . . . . . . . 43

4.7.9. Gestión de actualizaciones . . . . . . . . . . . . . . . . . . . . . . . . 43

4.7.10. Gestión de copias de seguridad. Plan de contingencia. . . . . . . . . . 44

4.7.11. Gestión de las caídas de tensión . . . . . . . . . . . . . . . . . . . . . 45

4.7.12. Gestión de estadísticas . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.7.13. Chequeo automático de servicios . . . . . . . . . . . . . . . . . . . . . 47

5. Implementación 48

5.1. Infraestructura de comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . 48

5.1.1. Nivel físico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.1.2. Nivel de enlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.1.3. Nivel de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.2. Sistema de administración centralizada . . . . . . . . . . . . . . . . . . . . . . 54

5.2.1. La jerarquía de servidores . . . . . . . . . . . . . . . . . . . . . . . . 55

5.2.1.1. Servidor principal . . . . . . . . . . . . . . . . . . . . . . . 55

5.2.1.2. Servidores secundarios . . . . . . . . . . . . . . . . . . . . 56

5.2.1.3. Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2.2. Sistema de instalación automática de servidores GNU/Linux . . . . . . 59

5.2.2.1. Modelos y patrones de estación . . . . . . . . . . . . . . . . 59

5.2.2.2. Transformación de patrones . . . . . . . . . . . . . . . . . . 60

5.2.2.3. Organización de la base de datos . . . . . . . . . . . . . . . 61

5.2.2.4. Procedimiento de instalación desatendida . . . . . . . . . . . 62

5.2.3. Sistema de instalación automática de clientes GNU/Linux . . . . . . . 65

5.2.4. Sistema de regeneración automática de clientes Windows XP . . . . . . 67

5.2.5. Sistema de instalación automática de clientes y servidores Windows XP 70

5.2.5.1. Estado inicial . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.2.5.2. Fase MS-DOS . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.2.5.3. Fase Windows . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.2.5.4. Fase Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . 73

6. Guía de Administración 75

6.1. Generación de la plataforma de administración . . . . . . . . . . . . . . . . . 75

6.2. Tareas frecuentes del administrador . . . . . . . . . . . . . . . . . . . . . . . 76

6.2.1. Creación y modificación de los perfiles para los servidores binarios . . 76

6.2.2. Creación de nuevos perfiles hardware para los clientes GNU/Linux . . 77

6.2.3. Creación y actualización de las imágenes de arranque para los

clientes GNU/Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.2.4. Creación y modificación de la imagen de reinstalación de los clientes

GNU/Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.2.5. Modificación del sistema para instalar de servidores GNU/Linux con

otras distribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.2.6. Creación de imágenes para la regeneración de Windows XP . . . . . . 83

6.3. Tareas frecuentes del operador . . . . . . . . . . . . . . . . . . . . . . . . . . 84

6.3.1. Configuración de la BIOS de los clientes del laboratorio . . . . . . . . 84

6.3.2. Grabación y actualización de las ROM de las tarjetas de red de los clientes 84

6.3.3. Regeneración de Windows XP en los clientes del laboratorio . . . . . . 85

6.3.4. Instalación y postinstalación de servidores secundarios GNU/Linux . . 85

6.3.5. Comprobación del funcionamiento del laboratorio . . . . . . . . . . . 86

6.3.6. Comprobar los clientes asignados a cada binario . . . . . . . . . . . . 87

6.3.7. Comprobar y gestionar la cola de las impresoras . . . . . . . . . . . . 87

6.3.8. Comprobar y gestionar la cola de correo electrónico . . . . . . . . . . 88

6.3.9. Dar de alta nuevos clientes y servidores . . . . . . . . . . . . . . . . . 89

6.3.10. Modificar la configuración de dispositivos de un cliente GNU/Linux . . 90

6.3.11. Dar de alta nuevos usuarios . . . . . . . . . . . . . . . . . . . . . . . 90

7. Casos de Aplicación 92

7.1. Los laboratorios del DIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

7.2. La red de producción del DIT . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

8. Conclusiones y Trabajos Futuros 97

8.1. Análisis del cumplimiento de objetivos . . . . . . . . . . . . . . . . . . . . . . 97

8.2. Beneficios extra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

8.3. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

8.4. Ampliaciones y Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . 102

Bibliografía 104

Pliego de condiciones 108

Presupuesto 109

Índice de tablas

6.1. Ejemplo de la línea de descripción de los equipos l001 y l002 en el archivo

dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

7.1. Necesidades específicas de los laboratorios de grado por asignatura . . . . . . . 92

10.1. Conmutador Ethernet Cisco Catalyst 2900 (WS-C2924M-XL-EN) . . . . . . . 109

10.2. Costes de Material Total . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

10.3. Horas de Mano de Obra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

10.4. Costes de Mano de Obra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

10.5. Presupuesto Total . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

V

Índice de figuras

4.1. Esquema de la jerarquía de servidores . . . . . . . . . . . . . . . . . . . . . . 34

5.1. Vista del laboratorio A.127-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2. Vista del laboratorio B.123 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.3. Mapa de red del laboratorio de Redes y Servicios Telemáticos (curso 01-02) . . 50

5.4. Mapa de Conmutadores Ethernet del Laboratorio . . . . . . . . . . . . . . . . 51

5.5. Imagen del rack de distribución de cableado y equipamiento en el aula A.127-2 52

5.6. Mapa general de la infraestructura de red del laboratorio . . . . . . . . . . . . 53

5.7. Imagen del rack de servidores del laboratorio en el CDC . . . . . . . . . . . . 54

5.8. Rack de equipos de comunicaciones en el aula B.123 . . . . . . . . . . . . . . 55

5.9. Esquema de la distribución jerárquica servicios para las instalaciones . . . . . . 56

5.10. Ejemplo del fichero estándar/etc/resolv.conf . . . . . . . . . . . . . . . . 59

5.11. Ejemplo de un fichero (/etc/resolv.conf) pertenciente a un patrón . . . . . 60

5.12. Fragmento del ficherobdm/net/admnet.m4 de la base de datos, que contiene

la definición de variables para DNS de una estación determinada . . . . . . . . 61

5.13. Esquema de directorios de la base de datos de máquinas (bdm) . . . . . . . . . 61

5.14. Ejemplo del perfil de una estación para la base de datos (bdm/nombremaq.m4) . 62

5.15. Esquema general de directorios del sistema de instalación para RedHat 7.3 . . . 63

5.16. Esquema del procedimiento de instalación desatendida para servidores GNU/Linux

en su primera fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.17. Esquema del procedimiento de instalación desatendida para servidores GNU/Linux

en su fase final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.18. Esquema del proceso de reinstalación de clientes GNU/Linux . . . . . . . . . . 67

5.19. Esquema del proceso de regeneración de clientes Windows XP en su fase inicial 69

5.20. Esquema del proceso de regeneración de clientes Windows XP en su fase final . 70

5.21. Esquema general de directorios del sistema de instalación para Windows XP . . 71

5.22. Esquema del proceso de instalación de sistemas Windows XP . . . . . . . . . . 73

6.1. Esquema general del directorio de servicios del usuario operador . . . . . . . . 78

6.2. Esquema detalle del subdirectorioarranque_maquinas . . . . . . . . . . . . 80

VI

Capítulo 1

Introducción

1.1. Antecedentes del proyecto

Ya en la década de los 80, el arranque remoto de ordenadores era algo muy utilizado en el

mundo de los ordenadores con sistema operativo UNIX, sin embargo, en el mundo del orde-

nador personal, este sistema de arranque era relativamente desconocido hasta la década de los

90.

En esta época, empezaron a surgir los primeros proyectos que permitían a un PC arran-

car desde un sistema servidor a través de la red, valiéndose del programa almacenado en una

pequeña memoria EEPROM que se alojaba en su adaptador de red (véase [3] para más infor-

mación sobre los esfuerzos que el DIT realizó en este campo en el pasado). Esto permitió que

los laboratorios basados en la utilización de ordenadores con este tipo de facilidades tuviesen

un entorno repetible y mucho más flexible de lo habitual, pero este sistema estaba limitado a un

único sistema operativo, que por aquellas fechas era de los pocos disponibles para ordenadores

PC, el MS-DOS. Para realizar la configuración del dispositivo de red se habían desarrollado

dos protocolos: RARP (Reverse ARP) y BOOTP (Protocolo de Arranque), mientras que para

realizar las transferencias de imágenes se utilizaba muy comúnmente TFTP (siglas de Trivial

File Transfer Protocol) que era un subconjunto del protocolo FTP y funcionaba sobre UDP/IP.

A mediados de los 90, los sistemas operativos empezaron a ofrecer utilidades basadas en

el procesador local, a crear entornos gráficos para el usuario y a requerir más espacio de al-

macenamiento, tanto de tipo permanente como de tipo temporal, lo que hizo que las utilidades

y aplicaciones que hasta entonces proporcionaban la posibilidad de efectuar el arranque del

sistema operativo desde la red dejaran de ser útiles. Surgieron entonces otros proyectos que

pretendieron resolver estas necesidades de forma muy similar a como se había hecho hasta

entonces, utilizando los mismos protocolos pero ampliando sus capacidades (véase [8, 7, 9])

basándose en el código proporcionado por los fabricantes para el uso de los adaptadores de

red que había disponibles en sistemas operativos de propósito general, como eran MS-DOS o

1

1. Introducción 2

Free-BSD.

A finales de los 90, surgieron nuevas especificaciones que cambiaron totalmente la defini-

ción de los protocolos e interfaces utilizados para el acceso a la red y a los recursos locales y

remotos de los ordenadores PC que pretendían iniciar sus sistemas operativos desde la red, así

surgieron el PXE [11] (siglas de Preboot eXecution Environment) y el DHCP [12] (acrónimo

de Dynamic Host Configuration Protocol y evolución del BOOTP).

1.2. Motivación

En el Departamento de Ingeniería de Sistemas Telemáticos (DIT), siempre ha habido un

gran interés en la creación de facilidades y procedimientos que permitiesen realizar un mante-

nimiento automático de los puestos de laboratorio en los que los alumnos realizan sus prácticas,

y éste ha sido el motor de cambio que ha permitido conseguir algo que, hoy por hoy, se aproxima

mucho a esa meta.

Las necesidades que han impulsado este proyecto son aquellas que resultan de la implanta-

ción de redes con alta densidad de ordenadores. El abaratamiento de costes y las economías de

escala de los ordenadores de tipo PC (siglas originales dePersonal Computer) han permitido la

ampliación de las redes de ordenadores de forma espectacular en los últimos años, permitiendo

crear salas de computadores mucho más grandes. Con ello, y de manera indefectible, ha llegado

la necesidad de gestionarlos de la manera más automática posible.

Como es bien sabido, cabe remarcar dos tipos de instalaciones de ordenadores según su

función en la red. Los primeros, llamados servidores, tienen una o varias funciones concretas

que proporcionan servicios que necesitan otros ordenadores y que éstos consiguen generalmente

a través de protocolos específicos de red. Los segundos, que llamaremos clientes a lo largo de

este proyecto, son aquellos que son utilizados principalmente por los usuarios para acceder a

los servicios telemáticos que los servidores ofrecen a través de la red, así como para realizar

tareas (normalmente de carácter ofimático) en el entorno local.

Son ejemplos comunes para el caso del entorno de los servidores, las granjas de ordenadores

y las salas de computación, mientras que para el caso de los ordenadores de tipo cliente, lo

son las salas de acceso a Internet que proliferan en universidades, colegios y lugares de ocio

(cibercafés).

Los dos tipos de instalaciones requieren un tratamiento diferente desde el punto de vista

de la administración del sistema. En el caso del ordenador de tipo cliente, el procedimiento

tradicional de gestión del ordenador comienza con la instalación manual de un sistema operati-

vo, continúa con la instalación de las aplicaciones y finaliza cuando el ordenador finalmente es

conectado a su red de acceso y empieza a ser utilizado por el usuario final. Esta instalación del

sistema completo es uno de los procedimientos que el sistema de gestión automatizada pretende

1. Introducción 3

resolver y en el cual entraremos en profundidad más adelante.

Una vez que el ordenador está instalado y funcionando, podríamos pensar que este proceso

de instalación será suficiente para que el ordenador en cuestión dé servicio durante un período

largo de tiempo, sin embargo, la estabilidad de los programas que se ejecutan en él no es tan

alta como la del sistema físico en el que se apoyan, siendo necesario regenerar la instalación del

sistema cada cierto número de horas de trabajo. Esto es especialmente cierto en entornos en los

que es necesario utilizar aplicaciones de programación que pueden afectar al funcionamiento

del propio sistema operativo, en entornos en los que el trabajo requiere partir de una instalación

específica del sistema o en aquellos en que los ordenadores están expuestos al ataque externo

en el amplio sentido de la palabra.

El número de horas que un sistema operativo está en perfectas condiciones de uso, es muy

difícil de determinar empíricamente debido a la gran dependencia con el tipo de usuario que

utilice el computador, así como del tipo de sistema operativo instalado, su conexión a Internet y

de la posibilidad de que el usuario instale sus propios programas en el sistema. También tienen

una influencia cada vez mayor los programas de distribución automática que aprovechan fallos

de seguridad del sistema, como son los virus, los troyanos, el spyware, las puertas traseras,

etc. Por todo esto, necesitamos que nuestro sistema de gestión de ordenadores de tipo cliente

permita la reinstalación del sistema cuantas veces sea necesario, en el menor tiempo posible y

con garantía total de que el sistema, una vez regenerado, está dispuesto para el funcionamiento,

tal y como lo estaba el primer día.

El ordenador de tipo servidor, al tener otros ordenadores que dependen de sus servicios

y se conectan a él a través de la red, tiene un perfil diferente y más crítico. La problemática

también es otra y viene derivada de que la instalación y administración de servidores requiere

mucho más tiempo y esfuerzo que la instalación de ordenadores de tipo cliente. Cuando tene-

mos grandes redes de ordenadores de tipo servidor, gran parte del sistema operativo suele ser

común entre ellos, mientras que éstos se diferencian entre sí en los servicios que ofrecen a la

red. El que tengan una gran parte común, permite racionalizar el esfuerzo para la instalación del

sistema operativo mediante la utilización de sistemas de instalación automática que se suelen

proporcionar a nivel de fabricante, pero aún queda la parte de configuración de los servicios que

un servidor concreto es capaz de implementar y que suele ser la que más tiempo de administra-

ción consume. Aunque la configuración del mismo servicio en servidores diferentes suele tener

una parte común muy importante, esta parte común es dependiente de parámetros generales de

nuestra red y de nuestro servicio que no suelen ser los propuestos por el sistema de instalación

automática del sistema operativo. Aquí surge, por tanto, una nueva necesidad que hemos de

acometer y que también será motivo de explicación en los próximos capítulos.

1. Introducción 4

1.3. Sistemas Operativos para Ordenadores PC

Hoy por hoy, hay una gran cantidad de sistemas operativos disponibles para la computadora

personal más común del planeta, el ordenador PC. Si bien, todas ellos ofrecen características

diferentes de funcionamiento y habilidades muy diversas, todos se basan en una plataforma

hardware común, el IBM PC que ha ido evolucionando a gran velocidad desde que los sistemas

operativos han empezado a utilizar entornos gráficos y sistemas de procesamiento de datos

mucho más potentes.

En el marco de este proyecto, sólo se ha atendido a las necesidades de utilización de los

laboratorios del DIT, por lo que las necesidades se han circunscrito a la implementación de

las facilidades necesarias para los sistemas operativos basados en Microsoft Windows y en

GNU/Linux.

Dentro de los entornos Windows, se ha dado soporte a diferentes sistemas (desde el Win-

dows 98 al Windows XP Professional, pasando por el Windows NT 4.0), sin embargo, en este

documento sólo se mencionarán las tareas realizadas para la automatización de la gestión del

entorno más moderno de todos ellos (el Windows XP Professional).

Dentro de los entornos GNU/Linux, hay una gran variedad de distribuciones que permiten

instalar, configurar y gestionar tanto servidores como máquinas de usuario, pero en este proyec-

to nos centraremos en la distribución RedHat 7.3, aunque se podrían haber utilizado otras dis-

tribuciones, de la miles que hay hoy en día disponibles. Las razones principales de esta elección

son la estabilidad y las facilidades de instalación y configuración, así como por las compila-

ciones del núcleo del sistema operativo Linux que suelen dar soporte a gran variedad de dispo-

sitivos hardware, incluyendo para éstos las mejoras más recientes.

En versiones anteriores de este proyecto, se han utilizado también otros sistemas operativos

que hoy en día han caído en desuso. Así, podemos mencionar que mediante Boots [3] se podía

hacer arrancar una imagen de MS-DOS de hasta 2.8MB que contenía el código necesario para

montar como discos locales los servidores de red por NFS (Network File System [26]) en la

época de los procesadores Intel 80286 y 80386. Más adelante, se utilizaba tanto Etherboot [8]

como Netboot [7] para iniciar imágenes de red que permitían transferir a través de la red el

núcleo GNU/Linux, esto ya se hacía con CPUs del tipo Intel 80486 y los primeros Pentium que

salieron al mercado.

1.4. Análisis de las soluciones disponibles

El objetivo de este proyecto, en pocas palabras, viene a ser la implementación de un sistema

centralizado que sea capaz de realizar el mantenimiento automático de los sistemas operativos

de un gran número de ordenadores, tanto de servidores de red como de máquinas de usuario o

1. Introducción 5

máquinas cliente. Para ello, el proyecto ha de hacer uso de las herramientas disponibles que,

si bien, tienen una alta utilidad, ninguna de ellas es capaz de llevar a cabo el objetivo de este

trabajo completo. Por eso, este proyecto se ha realizado con la idea de agrupar, aprovechar y

aumentar los esfuerzos que muchos otros han desarrollado previamente y así conseguir llevar a

la realidad el objetivo fundamental.

En esta sección, realizamos un análisis de las aplicaciones que se han puesto a disposición de

los distintos sistemas operativos (GNU/Linux y Microsoft Windows XP Professional) utilizados

por el DIT en sus laboratorios, para la simplificación de las tareas de administración de éstos

y veremos que aunque la mayoría tienen mucha utilidad en su área de aplicación, ni tienen

un entorno común de gestión ni proveen todas las facilidades requeridas, por lo que habrá que

unificar su administración y uso para llevar a cabo el proyecto.

1.4.1. Entorno GNU/Linux

Si nos planteamos el realizar un sistema de administración centralizada para sistemas GNU/-

Linux, estará bien que empezamos a analizar las utilidades disponibles para la gestión de orde-

nadores. Dada su naturaleza abierta, cabe decir que las propias características de este sistema

operativo crean un caldo de cultivo de soluciones que ha resultado ser muy próspero en los úl-

timos años en todos los sentidos. También cabe comentar que esta misma característica ha pro-

movido el desarrollo de diversas y muy diferentes distribuciones de GNU/Linux, cada una de

ellas con sus propias ventajas e inconvenientes pero también con un gran denominador común:

todas usan Linux [17] como núcleo del sistema y todas aprovechan en mayor o menor medida

la gran cantidad de herramientas proporcionadas por el proyecto GNU [16].

Así, mediante la funcionalidad de la herramienta Kickstart [13] de la distribución RedHat

[22] podemos realizar la instalación del sistema operativo, también podemos elegir las aplica-

ciones que queramos que tenga instaladas -dentro de las que vienen compiladas con la propia

distribución- y realizar una configuración básica de los dispositivos hardware basándonos en

la cantidad de memoria, tipo de CPU, pantalla, teclado, disco duro o tarjeta de red. Esta apli-

cación concreta, si bien resulta muy útil dado que permite clonar instalaciones desatendidas sin

demasiado esfuerzo, no está pensada para la configuración del software del servidor ni para la

gestión de las actualizaciones software del mismo. Hay proyectos que intentan mejorar la fun-

cionalidad de Kickstart (que realmente es una extensión del instalador de RedHat -anaconda-

para instalaciones desatendidas), en concreto, uno de los que cabe mencionar aquí, por estar

claramente relacionado, es Kickstart Tools [55].

También hay que mencionar Replicator [1] y FAI [2] que tienen muchas cosas en común

con RedHat Kickstart y que también tienen sus mismas limitaciones. Ambos proyectos están

orientados a la distribución Debian GNU/Linux. Replicator está más orientado a gestionar la

instalación desatendida de una máquina basándose en el patrón de la instalación de otra y así

1. Introducción 6

realizar un clon de la misma. FAI es un proyecto que pretende la automatización completa

de la instalación de un servidor y puede ser un candidato muy interesante a considerar para la

instalación de máquinas de forma desatendida, pero sin basarse en otras previamente instaladas.

Una de las partes más importantes para la gestión de la automatización de las instalaciones

es la posibilidad de gestionar el arranque desde los distintos medios disponibles, como son la

disquetera, el lector de CD-ROM, la red o el propio disco duro. Por tanto, será muy conveniente

que el sistema de gestión de arranque sea capaz de utilizar el medio que hayamos elegido para la

instalación. Así, podemos mencionar la utilidad del sistema de arranque GRUB [29] que permite

gestionar el arranque del núcleo de Linux tanto desde todos los medios mencionados, además de

ser capaz de cargar su configuración a través de la red utilizando una imagen compatible PXE

configurable también a través de la red. Otro de los sistemas más populares para el arranque de

un sistema PC es LILO[42], que últimamente ha introducido mejoras para el arranque de discos

virtuales y ofrece diferentes facilidades.

En el entorno de gestión de arranque, una de las novedades que han proporcionado más

potencia al sistema de arranque ha sido el proyecto Syslinux[9], un gestor de arranque que per-

mite configurar el inicio del sistema desde disquete (syslinux), CD-ROM (Isolinux+Memdisk)

o desde una imagen PXE traída por la red (Pxelinux). Este sistema tiene la ventaja, frente a sus

competidores en la gestión del arranque por red, de que no necesita tener un programa específi-

co de gestión del dispositivo concreto que tenga instalado el PC, sino que es capaz de adaptarse

a la especificación de PXE y utilizar el propio driver contenido en la pequeña ROM del propio

interfaz de red. Esta característica da una flexibilidad enorme a la hora del arranque de red,

ya que permite gestionar cualquier ordenador moderno que tenga una ROM compatible con el

estándar PXE.

Además, todos los sistemas de gestión de arranque que hemos mencionado tienen la posi-

bilidad de gestionar el inicio de otros sistemas operativos (como sería el de Microsoft Windows

en cualquiera de sus versiones o como el GNU-Hurd o el Free-BSD) lo que nos permite instalar

diversos sistemas en un solo PC y utilizar el más adecuado en cada momento. También son

capaces de presentar las opciones de arranque en forma de menú, de tal forma que sea el propio

usuario el que elija la opción de inicio más adecuada para su ordenador en cada momento, o en

su defecto se elija una de forma automática al pasar un cierto tiempo. Esta última característica

resulta muy interesante para la realización de tareas de gestión automáticas sin intervención del

usuario.

También para GNU/Linux y para otros sistemas operativos hay otros sistemas disponibles

de gestión de arranque que permiten realizar esta tarea en ordenadores más antiguos, previos a

la especificación del sistema PXE. Son principalmente Netboot[7], Etherboot [8], NILO [53],

Boots [3], Bootmagic [36] o Bp-batch [31] que no trataremos aquí en profundidad por salirse

de nuestro espacio de acción, pero que el lector puede consultar a través de las referencias

1. Introducción 7

aportadas.

Una de las principales ventajas con respecto a la gestión del sistema GNU/Linux viene

de la flexibilidad en el almacenamiento de sus datos. Así, por ejemplo, es posible generar la

instalación un sistema GNU/Linux con todas sus aplicaciones perfectamente funcionales en un

sistema de ficheros comprimido y de sólo lectura accesible desde un CD-ROM (véase el caso de

Knoppix [43]). Baste mencionar que basándose en este ejemplo sería sencillo crear un sistema

que en lugar de utilizar un CD-ROM con control de arranque, ofreciese lo mismo utilizando un

sistema de disco de red de sólo lectura.

Otra de las tareas que es necesario realizar en el proceso de instalación o regeneración de la

máquina es la de particionar el disco duro local. Hay algunas aplicaciones que permiten realizar

esta labor, no sólo para los tipos de sistemas de ficheros de Linux, sino también para otros tipos

de sistemas de archivos. Así, podemos hablar de fdisk [41], el más potente por sus opciones

de configuración, o de Disk Druid que viene en la distribución de RedHat y permite realizar

la configuración de las particiones del disco duro de forma automática, en función del espacio

disponible.

1.4.2. Entorno Microsoft Windows

Si hablamos ahora de las herramientas de instalación automática del sistema operativo Win-

dows XP Professional, aunque hay ciertas facilidades de red que permiten realizar la configu-

ración automática de los dispositivos soportados por el sistema operativo, no hay tantas facili-

dades disponibles para el administrador.

Así, el soporte para gestionar la instalación a través de la red es más bien escaso, dado que

obliga a que el administrador disponga de los drivers de configuración de los dispositivos de red

para el sistema operativo utilizado durante la instalación que es de tipo MS-DOS. Esta es una

de las desventajas que tiene frente al sistema operativo GNU/Linux, ya que en Linux se puede

realizar la instalación con el mismo núcleo que se utilizará posteriormente para el ordenador en

su uso normal, usando por tanto el mismo código para la gestión de los diferentes dispositivos

en tiempo de instalación y en tiempo de uso.

Además, después del proceso de instalación del sistema operativo, y aunque la instalación se

haga de forma desatendida mediante la configuración del programa Sysprep [24], hay realizar el

rearranque del sistema varias veces. Este programa, aparte de permitir la instalación de red sin

requerir la presencia del administrador, se encarga de la introducción de los datos de licencia

del producto y la generación automática del identificador único de sistema (SID), lo que es

fundamental para la compartición de datos a través de la red.

La gestión es particularmente más complicada, si queremos que la gestión de las cuentas

de usuario sea realizada también a través de la red (operación que en la jerga de Windows

viene a llamarse ”unirse al dominio”), sobre todo si deseamos que el controlador principal del

1. Introducción 8

dominio no sea un ordenador de la plataforma Microsoft Windows (véase la información sobre

el proyecto Samba [25]) ya que el protocolo utilizado para este tipo de servicios está lejos de

ser una especificación abierta.

En este entorno (en el que un servidor Samba da servicio de dominio a un servidor XP)

hemos detectado otros problemas añadidos, como viene a ser el caso de la clave privada gene-

rada para la conexión al dominio caduca cada mes, con lo que hay que regenerar la clave o el

servidor cada vez que ha caducado[27].

Este tipo de sistema también da más trabajo al administrador porque la mayor parte de

las aplicaciones no vienen integradas en el mismo soporte y formato que el sistema operativo

siendo necesario realizar procesos que permitan automatizar la instalación y desinstalación de

las mismas, como por ejemplo la herramienta Autoit[23]. En este sentido también podemos

utilizar una aplicación llamada WinstallLE [39] que permite realizar un análisis diferencial

del estado de disco duro y registro de Windows y generar una imagen instalable de forma

automática.

Tampoco está optimizado el uso de recursos en red en Windows, dado que la mayoría de

las aplicaciones requieren estar instaladas en local (en el disco duro del ordenador que las pre-

tende utilizar) en lugar de ser posible instalarlas en sistemas remotos que permitan el acceso

concurrente, a través de la red, al código de las aplicaciones.

También hay que añadir al capítulo de problemas de este tipo de sistemas operativos, que la

instalación de los mismos requiere que el núcleo del sistema operativo se almacene localmente

y esté disponible de forma permanente a través de un dispositivo de almacenamiento no volátil

(como por ejemplo un disco duro), no siendo posible la carga del mismo desde la red de forma

nativa. Además, el núcleo del sistema operativo tiene una gran cantidad de requerimientos tales

como que el sistema de almacenamiento ha de tener un formato determinado (NTFS) si quere-

mos utilizar las características de gestión de permisos de acceso entre usuarios o como que el

sistema de almacenamiento ha de ser de lectura y escritura.

No hay que olvidar mencionar que también hay otras herramientas de Microsoft que per-

miten automatizar la instalación del sistema operativo de forma desatendida, tal y como es el

Setup Manager Wizard o que permiten la clonación de las instalaciones de servidores Windows,

como viene a ser el IntelliMirror para Windows XP que dispone de una herramienta llamada

RIS (acrónimo inglés de Remote Installation Services).

También hay otros proyectos que pretenden implementar sistemas de instalación desatendi-

da de sistemas Windows desde servidor. Así, podemos mencionar Unattended [32] y Realmen

[33]. También hay gran número de páginas dedicadas a la recopilación de información y artícu-

los que versan sobre el tema en Labmice.net [34] y en Willowhayes [35].

Uno de los sistemas de administración automática más divulgados para gestionar máquinas

Windows es Rembo Auto-Deploy [28], un sistema a su vez basado en Windows NT/2000. Tam-

1. Introducción 9

bién ofrece la posibilidad de gestionar máquinas GNU/Linux, pero, al igual que con Windows,

siempre se basa en la regeneración local de una imagen de disco creada a partir de una insta-

lación nueva en un sistema cliente idéntico, no permitiendo realizar instalaciones automáticas

de sistemas Windows desde la red, lo que puede ser una exigencia demasiado fuerte cuando se

trata de automatizar la instalación de un conjunto de servidores suficientemente diverso, ya que

cada imagen ha de corresponder estrictamente con el hardware del PC. Aunque integra la últi-

ma tecnología en protocolos de gestión de red (PXE, DHCP y Multicast) otro posible problema

que podemos mencionar es que está pensado para concentrar en un sólo servidor la gestión

de múltiples clientes pero no para permitir la gestión simultánea de las imágenes desde diver-

sos sub-servidores de imágenes, lo que obliga a que todos los clientes tengan acceso directo al

servidor de administración.

Para realizar imágenes de disco capaces de iniciar el ordenador hay muchas aplicaciones

que permiten automatizar la creación de las mismas y gestionarlas a través de la red. Así, están

Norton Ghost[37], PQDI (Power Quest Drive Image [36]) para Windows XP y Partimage [38]

para Linux.

Antes de poder recuperar las imágenes o instalar el sistema es conveniente utilizar alguna

aplicación de gestión de particiones de forma automática para el sistema que estemos arrancan-

do. Además de las de Linux, podemos utilizar Partition Magic [36] para Windows y el aefdisk

[40] para MS-DOS.

Capítulo 2

Objetivos

2.1. Problemas que se pretenden resolver

Son muchos y muy variados los problemas que se pretenden resolver con este proyecto:

desde el usuario poco experto que necesita reinstalar su equipo de trabajo hasta la actualización

del sistema, pasando por la configuración del hardware o la creación de servicios distribuidos

de forma sencilla. A continuación se describen algunos de los problemas más relevantes.

1. Problemas de seguridad: Ordenadores que están conectados a Internet o utilizan alguno de

sus servicios (correo electrónico, navegación Web, etc) y están expuestos a diversos pro-

blemas de seguridad (virus, troyanos, gusanos, puertas traseras, etc) que son más graves

cuanto menos experto en informática es el usuario del sistema.

2. Problemas de Repetibilidad de las pruebas: ordenadores en que uno o varios adminis-

tradores realizan pruebas en entornos de red o de programación, que pueden llegar a

comprometer la estabilidad del sistema operativo. Además tienen la necesidad de partir

de un entorno conocido y estable para que sus trabajos tengan validez.

3. Granjas de servidores, en las que se pretende tener una cantidad tan grande de ordenadores

interconectados entre sí, que sólo la gestión automática de sus servicios e interconexiones

permite utilizarlos con la estabilidad y fiabilidad necesarias.

4. Salas de ordenadores (laboratorios, cibercafés y centros de trabajo): conjuntos de orde-

nadores interconectados en red que se utilizan para dar servicio al usuario en entornos

ofimáticos, de acceso a Internet, de juegos o de aplicaciones específicas.

5. Salas de videoconferencia: redes de ordenadores con unas características específicas que

permiten el intercambio de contenidos multimedia a través de redes de datos de propósito

10

2. Objetivos 11

general (normalmente Internet). Estas redes normalmente tienen unas necesidades especí-

ficas y muy exigentes en cuanto a la configuración software y hardware, lo que hace que

sean candidatos claros para la gestión automática de las mismas.

6. Redes corporativas: Es el caso de grandes organizaciones de carácter profesional, en las

que la falta de disponibilidad del ordenador de sus trabajadores puede costarle no sólo

retrasos, sino también fallos de servicio y pérdidas de dinero.

7. Instalaciones desatendidas: Pretenden resolver el problema que plantean los usuarios sin

conocimientos de administración, que no está capacitados para realizar la instalación de

sus propios ordenadores, necesitando que alguien le proporcione este servicio.

8. Fallos de estabilidad de los sistemas operativos: problemas causados por la incompatibili-

dad entre programas instalados que provocan una gran pérdida de tiempo en identificación

y búsqueda de soluciones, ya que a menudo estos fallos son difícilmente repetibles y están

interrelacionados entre sí. Además, los usuarios que los padecen no suelen ser capaces de

describirlos adecuadamente, lo que impide la ayuda remota y requiere la presencia física

del administrador en el ordenador afectado. Si a esto le unimos que normalmente la solu-

ción pasa por la reinstalación del ordenador, hemos encontrado un candidato más a los

sistemas de administración centralizada.

9. Problemas de actualización del sistema operativo: las políticas de seguridad más exigentes

requieren la actualización diaria de los ordenadores que están expuestos a los ataques

desde Internet. Esta tarea no suele ser sencilla y es una candidata perfecta a los sistemas

de gestión mediante procedimientos automatizados.

2.2. Requisitos generales

Para resolver algunos de los problemas anteriormente descritos pueden adoptarse diversas

soluciones, algunas de las cuales nosotros hemos decidido no contemplar por el elevado con-

sumo de recursos y la poca sostenibilidad del servicio que conllevan. Los que se muestran a

continuación son los requisitos mínimos de nuestro sistema de administración centralizada.

1. No requerir más personal cualificado cuando aumenta el número de ordenadores adminis-

trados: Normalmente el personal técnico asignado a un determinado servicio está limitado

por razones de presupuesto. Si la administración de ordenadores se realiza del modo

tradicional, el personal encargado debería crecer proporcionalmente con el número de

ordenadores.

2. Objetivos 12

2. No invertir tiempo en la detección de problemas: La reparación de los sistemas requeriría

una fuerte inversión en formación del personal encargado, dado que éste debería tener

amplios conocimientos para realizar las tareas de identificación de problemas y búsqueda

de soluciones. También sería conveniente contratar algún servicio externo que permitiese

resolver los problemas que el personal del servicio no fuese capaz de manejar, con el

consiguiente coste adicional. Por eso, desde nuestro punto de vista, el sistema debe ser

concebido como una solución de rescate que nos lleve de nuevo a una situación estable

del computador, en la que todos los elementos y comportamientos sean conocidos.

3. No necesitar personal altamente especializado para instalar o reinstalar un ordenador:

Es necesario que el propio usuario del ordenador pueda tomar la decisión de realizar la

reinstalación cuando lo crea conveniente sin necesitar permiso ni consejo. Además esta

reinstalación debe ser capaz de realizarla cuantas veces lo necesite, sin limitación de

horarios o disponibilidad del personal (por ejemplo, en días festivos o durante sus horas

extras).

4. No necesitar nada instalado previamente en el ordenador, salvo la propia conexión de red.

En nuestro sistema, los parámetros de configuración de un ordenador específico estarán

almacenados en el propio sistema de administración centralizada.

5. El usuario no tendrá que responder a ninguna pregunta una vez que ha elegido realizar la

reinstalación del sistema.

6. La reinstalación del sistema debe tardar en el peor de los casos, menos de un tercio del

tiempo que se tardaría en realizar la instalación de forma manual ya que invertir más

tiempo en el proceso empezaría a dejar de ser una ventaja competitiva con respecto a

otras soluciones. Además, la realización de las pruebas de funcionamiento empezaría a

ser demasiado costosa en tiempo, lo que dificultaría gravemente la tarea de puesta en

marcha de nuevas instalaciones automatizadas.

7. Tanto el sistema operativo como las aplicaciones software se deben instalar en el mismo

proceso: De esta forma, el usuario utilizará el servicio siempre que lo necesite. Si sólo se

instalase el sistema operativo, el esfuerzo que el usuario tendría que realizar para dejarlo

en condiciones de uso sería mayor y esto sería una barrera a la hora de tomar la decisión

de reinstalarlo. Lo mismo ocurriría si el proceso automatizado sólo se utilizase para la

instalación de aplicaciones.

8. El sistema de reinstalación centralizada debe permitir la reinstalación simultánea de un

gran número de ordenadores. Para ello se recurrirá a la gestión de cachés locales que

mediante procedimientos de verificación de integridad permitirán regenerar el sistema sin

2. Objetivos 13

malgastar recursos de red. Además, habrá que redimensionar adecuadamente las redes

locales para garantizar una buena calidad del servicio.

9. El sistema de administración centralizada no debe necesitar ningún sistema adicional que

cuestione la disponibilidad temporal del mismo: El esfuerzo a realizar será lo suficiente-

mente importante como para que se pretenda que tenga una vida útil mayor de 10 años.

Para ello será necesario que no sea dependiente de terceras partes que puedan dejar de

proporcionar sus servicios interrumpiendo así la continuidad del proyecto.

10. Ha de ser posible instalar cualquier sistema operativo, con cualquier programa de usuario

incluido o no en la distribución del mismo, de tal forma que, una vez finalizada la tarea de

reinstalación, el usuario tenga todos los recursos necesarios disponibles y pueda comenzar

a trabajar desde ese mismo instante.

2.3. Requisitos del entorno

El entorno en que se ha creado este proyecto es muy específico y bastante común en círculos

académicos, pero puede que desconocido para la persona ajena al mismo. En la universidad en

la que se ha realizado este proyecto, no se da soporte informático al personal de la misma,

sino que a través del departamento de Servicios Centrales se provee de ciertas herramientas a

los usuarios. Estas herramientas son: la conectividad electrónica entre las distintas escuelas e

Internet y la gestión de los recursos que la hacen posible; la compra de ordenadores y material

para la realización de las tareas docentes y la compra de licencias de productos software de uso

general, como pueden ser sistemas operativos o aplicaciones de prevención y limpieza de virus

informáticos.

Son el personal de administración y el personal docente encargado de cada asignatura

quienes deben administrar (gestionar, instalar, actualizar, etc) los equipos informáticos que se

hayan destinado a la realización de las asignaturas prácticas del departamento concreto al que

pertenezca el laboratorio. Esto puede no ser un gran problema en un laboratorio pequeño con

un par de ordenadores, pero en el DIT hay más de 1500 alumnos anuales a los cuales se les han

de ofrecer cientos de equipos informáticos para realizar sus prácticas.

Por eso, el primer problema a resolver para la generación de este sistema de administración

centralizada fue determinar qué tipo de soporte queríamos dar a nuestros usuarios (entendiendo

por soporte las tareas que el personal asignado estaría dispuesto a realizar con el fin de resolver

cada problema concreto del ordenador utilizado por el alumnado). La decisión tomada consis-

tió en un firme compromiso en proporcionar a los alumnos un ordenador recién instalado en

un breve espacio de tiempo y siempre que fuese necesario. La resolución de las cuestiones y

problemas se haría solamente si el sistema sigue fallando después de recién instalado. Con esto,

2. Objetivos 14

se ha conseguido una alta estabilidad y una gran facilidad de restauración de los entornos de

pruebas propios de un laboratorio universitario de redes, programación y servicios telemáticos.

Al analizar los equipos informáticos de los que disponía el laboratorio, nos dimos cuenta de

que, si bien estaban agrupados en conjuntos de máquinas exactamente iguales, la mayor parte

de ellos carecía de un dispositivo fundamental para la instalación de los sistemas operativos de

hoy en día: el lector de CDs. La única solución que no pasaba por instalarle previamente un

lector de CDs a cada uno, era la utilización del sistema de interconexión de todos ellos: la red.

A través de ésta, podrían compartirse los recursos necesarios para que todos los ordenadores

tuviesen los mismos sistemas operativos y aplicaciones instaladas.

2.4. Objetivos

El análisis de la problemática y los requisitos que se nos plantean, nos permite llegar a la

especificación de los objetivos finales del proyecto, que son los que se indican a continuación.

Instalación y/o regeneración desatendida: Dada la diversidad de sistemas operativos y

aplicaciones que queremos incluir en nuestro sistema de administración centralizada, en

algunas ocasiones será más aconsejable (por la naturaleza de la instalación o por el tiempo

invertido en el mismo) crear imágenes del sistema operativo a partir de las cuales sea

posible regenerarlo. En otras ocasiones la reinstalación desatendida será suficiente, pues

el sistema operativo nos provee en muchos casos de las herramientas necesarias para

realizar la tarea en pocos pasos. En cualquier caso, será el administrador del sistema

quien deberá investigar cuál de las opciones resulta ser la más efectiva para cada caso

concreto.

Administración cero: Aunque en la bibliografía disponible se pueden encontrar distintas

definiciones de administración cero, nosotros entendemos por administración cero aquel

conjunto de procesos que nos permite gestionar los recursos tanto hardware como soft-

ware de un grupo de ordenadores de tal forma que se reducen al mínimo las tareas de

administración de éstos.

De hecho, algunas de las tareas que más tiempo consumen se eliminan de forma com-

pleta. Así, podemos mencionar que se pretende que el administrador no realice ninguna

reparación software de ninguno de los servidores que administra ya que la mayoría de las

veces los problemas vienen derivados de la instalación de dos aplicaciones conflictivas

o de la sustitución de controladores. Por ejemplo, si un computador de tipo cliente deja

de funcionar total o parcialmente, en lugar de invertir una gran cantidad de tiempo en

averiguar el problema y tratar de solucionarlo, se recurre a la reinstalación o a la regene-

2. Objetivos 15

ración de su sistema completo y, en caso de que no sea suficiente, se buscará el problema

en profundidad.

Especialización de los recursos humanos: Después de la implantación de este sistema,

habrá dos tipos de personal: administrador y operador. La diferencia entre ellos está en

que si el administrador es quien ha diseñado el sistema y resuelve sus problemas, el

operador es quien lo manipula, quien utiliza las herramientas que éste le proporciona

(para gestionar la red de servidores y clientes) y quien detecta los problemas (aparte del

propio usuario). Además, dado que es muy sencillo partir de una base estable, sólo en

caso de que un posible problema se repita después de la reinstalación o regeneración, se

debe invertir tiempo en la clasificación y resolución del mismo.

Este sistema tiene una ventaja crucial que resulta de la división del trabajo: de esta forma,

el que reinstala o regenera de forma automática y desatendida ya no tiene por qué ser

quien crea los procesos de reinstalación o quien está especializado en la resolución de los

problemas que pueden surgir después de aplicar los procesos de administración cero.

Además, en caso de que el grupo de trabajo no sea lo suficientemente grande como para

estar muy especializado, la parte monótona y rutinaria de las tareas del administrador

se ve ampliamente recortada, permitiéndole a éste invertir más tiempo en la mejora del

sistema de gestión centralizada.

Tan es así, que sería posible que el propio usuario del ordenador realizase las tareas de

regeneración o reinstalación por sí mismo y sin depender de nadie más. Esto requeriría

un control de acceso al sistema de regeneración o reinstalación automática cuya imple-

mentación es posible con la tecnología de que disponemos.

Repetibilidad del proceso de instalación o regeneración: Hay básicamente dos soluciones

posibles para la gestión de sistemas operativos en un sistema de administración centra-

lizada. O utilizamos una imagen del sistema operativo que queremos instalar (proceso

que llamamos regeneración), o utilizamos un instalador automático basado en un fichero

de configuración (proceso que llamamos instalación automática). Más adelante, en el

capítulo 3, se discutirán las diferencias, ventajas e inconvenientes de cada uno de estos

métodos, pero cabe mencionar que este objetivo es clave en la gestión del sistema, ya

que sin repetibilidad del proceso no tendremos capacidad de depuración de los errores ni

conseguiremos la estabilidad del mismo. La repetibilidad del proceso es muy importante

para asegurar que éste no es degenerativo (como lo sería si se realizase una instalación

encima de otra). Para ello, es necesario partir de un punto inicial lo más seguro posible

en la cadena de administración, como, por ejemplo, empezar el proceso dando formato y

detectando errores en la unidad de disco duro que albergará el sistema operativo.

2. Objetivos 16

Reproducción de estado: El proceso ha de ser de tal forma que asegure que siempre que

se realiza la instalación o regeneración de un sistema el estado final es exactamente el

mismo, independientemente de que el hardware disponible sea ligeramente diferente. Esta

característica permitirá el uso del sistema de gestión centralizado en entornos de pruebas

que aumentan ampliamente la inestabilidad del sistema operativo en cuestión, sea éste

cual sea.

Flexibilidad: Si diseñamos los procesos con suficiente amplitud de miras, será posible

utilizarlos para gestionar más sistemas operativos y aplicaciones. Y lo que es más impor-

tante, será posible adaptarse a los cambios de entorno producidos por las actualizaciones

del software del que se pretende dar soporte.

Rapidez del proceso: El sistema ha de ser suficientemente ágil como para que sea sus-

tancialmente más rápido que la instalación manual del mismo. De esta forma no sólo se

ahorra trabajo rutinario, sino también tiempo. Es más, en un entorno de trabajo con un

gran número de ordenadores administrados, debería ser posible la regeneración o reinsta-

lación de la gran mayoría de ellos en paralelo, partiendo de los mismos datos iniciales de

regeneración y utilizando para la regeneración de todos el mismo tiempo que se emplearía

para la regeneración de uno.

Gestión de desastres: Este sistema debe permitir la reinstalación de todos los ordenadores

administrados en caso de problemas generalizados en el conjunto de ellos (como sería

por ejemplo un ataque masivo por virus) evitando que nuestros servicios estuvieran inac-

tivos más tiempo del necesario y aumentando así de forma drástica su capacidad de auto-

regeneración. Para que esta objetivo se cumpla realmente, será necesaria la realización de

pruebas exhaustivas e incluso el plantearse la regeneración diaria del sistema.

Independencia: El sistema debe ser totalmente independiente, de tal forma que los cam-

bios en los sistemas operativos o en las aplicaciones no nos obliguen a replantearnos el

diseño del mismo. Para ello hay que pensar en una gran diversidad de posibilidades y hay

que conseguir una arquitectura modular que haga uso de las diferentes herramientas que

tenemos a nuestro alcance y que podremos actualizar, modificar o sustituir por otras cuan-

do lo creamos necesario. Además, desde otro punto de vista, los sistemas administrados

deben ser independientes entre sí y funcionar tal y como lo haría un sistema administra-

do manualmente. Será una decisión de diseño el permitir que los sistemas administrados

sean independientes también del sistema de administración o no.

Autonomía: El sistema de administración centralizada ha de ser autónomo de tal forma

que integre todos los servicios necesarios en la administración, permitiendo así que no

dependa de otros sistemas ajenos a él mismo para realizar sus tareas, aunque por supuesto

2. Objetivos 17

dependerá de ciertos medios que habrán de estar disponibles para la llevar a cabo las

mismas.

Sostenibilidad: Esta característica nos permitirá aumentar el conjunto de ordenadores ad-

ministrados sin necesidad de introducir cambios drásticos en nuestro sistema. Así por

ejemplo, será posible aumentar la capacidad del sistema mediante la introducción de un

servidor más de administración. Estos servidores de administración deberán ser muy pare-

cidos entre sí de tal forma que su replicación sea tan sencilla como la de cualquiera de los

ordenadores administrados.

Eficiencia: Mediante este sistema deberá ser posible el ahorro de tiempo (de instalación,

de reparación, de configuración y de actualización de los ordenadores administrados)

y el ahorro de recursos humanos. Además, la homogeneización del hardware también

contribuirá a la eficiencia del sistema ya que cuantos más equipos iguales se compren,

menos tiempo habrá que invertir en conocer sus problemas. Si las economías de escala

funcionan como deben, también será más sencillo obtener descuentos importantes a la

hora de la compra de los equipos, lo que redundará en un doble beneficio.

Gestión de los datos personales: Dado que el sistema completo podría ser regenerado en

cualquier momento, es necesario contemplar procesos que permitan regenerar el sistema

sin perder los datos de los usuarios. Para ello, se pueden utilizar diversas técnicas que

discutiremos más adelante (backups incrementales basados en fecha y/o en firma, espacio

de usuario en red, marcas de fichero, bases de datos, etc).

Capítulo 3

Discusiones de diseño

3.1. Introducción

Desde un punto de vista tecnológico, se pueden entrever muchas posibilidades diferentes a la

hora de plantearse la solución técnica de las necesidades de este proyecto. En este apartado pre-

tendemos realizar una breve discusión de las mismas apuntando sus ventajas e inconvenientes

más importantes. Explicaremos primero los procesos de instalación plenamente funcional del

sistema operativo, que siempre son previos a la regeneración del mismo. Tanto los procesos de

regeneración como los de instalación pueden ser de tipo manual o de tipo automático, depen-

diendo de si es necesario que una persona interactúe directamente o no con el procedimiento

respondiendo a las preguntas de configuración que sea necesario. Hemos llamado procedimien-

tos desatendidos a aquellos que permiten la gestión de un ordenador sin ninguna intervención

del usuario. La distinción entre desatendido y automático viene a ser que mientras que para un

procedimiento desatendido no hace falta nadie delante del ordenador, para un proceso automáti-

co necesitamos al menos alguien que decida qué tarea es la que se tiene que realizar y que esté

delante del ordenador para llevarla a cabo.

3.2. Instalación automática

Los sistemas de instalación automática son muy dependientes del sistema operativo que se

desea instalar. Aunque en el pasado no era común encontrar sistemas operativos capaces de

gestionar su propia instalación sin la necesidad de tener un administrador que respondiese a las

preguntas, esta tendencia se invirtió hace pocos años al crecer la necesidad de administrar de

forma más barata los ordenadores de grandes corporaciones y grupos de usuarios.

Aunque esto es así, por desgracia, este tipo de procedimientos no se han desarrollado para

todos los sistemas operativos que podemos encontrar en el mercado y será necesario crearlos

en los casos menos afortunados. Este tipo de trabajo (creación de sistemas de instalación au-

18


tomática) suele requerir un gran esfuerzo, están muy vinculados con el sistema operativo objeto

de la instalación y, a parte de ser poco exportables, difícilmente serán capaces de adaptarse a los

posibles cambios en los procedimientos de instalación del sistema operativo en cuestión. Por

todo esto, en la mayoría de los casos parece más recomendable acudir a procedimientos de rege-

neración en lugar de reinstalación, de tal forma que aunque se tenga que realizar manualmente

una de las instalaciones el resto puedan partir de la imagen generada.

Este tipo de sistemas utilizan las configuraciones almacenadas en algún lugar conocido para

inicializar los sistemas de instalación y proporcionarles las respuestas a las preguntas que el

usuario o administrador habría de contestar de forma manual.

Hay diferentes lugares posibles para guardar estas configuraciones de instalación. Los más

comunes son los que se muestran a continuación (en la sección 3.4.2 se dan amplios detalles de

la fase de arranque del ordenador PC):

En un disquete. Normalmente los ficheros de configuración suelen ser lo suficientemente

pequeños como para que quepan perfectamente en un disco pequeño. En este disquete se

almacena también un pequeño sistema operativo que utiliza los ficheros de configuración

para iniciar el ordenador y buscar otros medios de instalación subsiguientes (CDROM,

red, etc). Dado que esta opción no es autosuficiente en sí misma, es cada vez menos

utilizada. También tiene el problema de baja capacidad de transferencia de datos de este

dispositivo, así como la baja confiabilidad del mismo.

En un CDROM o DVDROM. Este tipo de soporte, al tener mayor capacidad, puede in-

cluso contener el sistema operativo completo, de tal forma que no sea necesario utilizar

ningún otro medio para finalizar la instalación.

En un ordenador remoto y accesible a través de la red de datos. Para que este procedimien-

to sea efectivo, será necesario proporcionar previamente al ordenador alguna herramienta

para que sea capaz de averiguar sus parámetros de conexión a la red de datos.

La instalación automática del sistema operativo tiene una ventaja importante en la instalación de

grandes redes y es que si disponemos de un procedimiento automático para instalar un sistema

operativo en un ordenador concreto, debería ser sencillo modificar ese procedimiento para que

nos permita instalar ese mismo sistema operativo en todos los ordenadores que lo necesiten.

Si el procedimiento está bien diseñado, no será necesario modificar el propio programa sino

modificar los ficheros de configuración que éste necesita para realizar la instalación de cada

ordenador particularizándola al mínimo detalle.

De esta forma, en caso de utilizar en nuestro grupo de ordenadores un sólo tipo de sistema

operativo, podríamos reinstalar todos y cada uno de ellos en un breve espacio de tiempo, lo que

nos permitiría gestionar granjas de ordenadores con una gran facilidad.


Uno de los grandes inconvenientes de los sistemas de instalación automática es la hetero-

geneidad del hardware que utilizan los ordenadores que pretendemos instalar. También está el

problema de la instalación automática de las aplicaciones, ya que éstas pueden venir separadas

del sistema operativo. Por último hay que contar con la problemática de la recuperación de los

datos del ordenador previos a la instalación automática, que suele ser necesario mantener.

3.3. Regeneración cruda

Tipos de regeneración:

1. Clonación de discos duros: Como sabemos, el disco duro es la parte del ordenador encar-

gada del almacenamiento permanente del sistema operativo y sus aplicaciones software.

Este procedimiento se basa en la copia cruda (bit a bit) de un disco duro a otro, después de

la primera instalación y mediante él es posible regenerar el disco por completo. Al disco

del ordenador que pretendemos clonar le llamaremos disco origen o inicial, mientras que

al disco utilizado para realizar la clonación le llamaremos disco imagen o clónico.

Ventajas:

a) Es muy rápido en los ordenadores actuales, dado que para la copia de disco

a disco se pueden utilizar procedimientos automatizados de transferencia de

datos (como por ejemplo el DMA).

b) Es muy sencillo, habiendo una gran variedad de programas para todos los sis-

temas operativos que son capaces de realizar este tipo de operación.

c) Si la copia cruda se realiza adecuadamente, se podría utilizar el propio disco

duro para que el ordenador volviese a su estado inicial (inmediatamente pos-

terior a la primera instalación) lo que significaría una vuelta al trabajo casi

inmediata.

d) Si hubiera muchos ordenadores exactamente iguales en el sistema y se sofistica

ligeramente el proceso, se podría pensar en generar nuevos discos duros a partir

de los discos imagen que permitiesen reinstalar todas las máquinas en un breve

espacio de tiempo.

Inconvenientes:

a) Cualquier pequeña modificación de la configuración del sistema supone la nece-

sidad de una nueva generación completa de la imagen del mismo. La primera

imagen, generalmente, se hace a mano, y se requerirá una imagen de cada sis-

tema a gestionar, sobre todo si los ordenadores no son todos idénticos en hard-

ware y software, lo que supone una gran cantidad de trabajo.


b) El usuario puede realizar la tarea de recuperación sólo si tiene a su alcance el

medio de almacenamiento utilizado y el programa que ha permitido realizar la

imagen.

c) Normalmente la recuperación del sistema requiere un sistema operativo con una

funcionalidad mínima, que será necesario proveer en forma de soporte magnéti-

co temporal (disquete) u óptico (CDROM o DVDROM). La gestión de estos

soportes suele ser engorrosa cuando el número de sistemas soportados crece,

y en muchos casos también es dependiente del hardware que el ordenador a

regenerar tenga instalado.

d) La utilización de un disco duro para hacer una copia cruda requiere una inver-

sión considerable, teniendo en cuenta que su precio (aunque cada vez menor)

es bastante alto.

e) Los discos duros están expuestos a la pérdida de datos en caso de avería. Inclu-

so, al ser un soporte magnético, pueden ser afectados por campos eléctricos o

magnéticos del medio ambiente.

2. Clonación de particiones de disco duro: Teniendo en cuenta que un disco duro se puede

dividir en varias particiones, el sistema de clonación de particiones es muy similar al de

clonación de discos duros, pero introduce algunas características específicas que conviene

resaltar.

Ventajas (con respecto a la clonación de discos duros):

a) No se requiere inversión en la compra de hardware extra.

b) No se requiere la gestión del almacenamiento del hardware extra, ya que la

copia de seguridad está siempre disponible en el ordenador.

Inconvenientes (con respecto a la clonación de discos duros):

a) Al estar disponible la partición de resguardo para el sistema operativo en to-

do momento, cabe la posibilidad de que los mismos procesos que provocan la

necesidad de regenerarlo dañen la propia copia de seguridad.

b) Al realizarse la copia cruda de particiones se evita la realización de copia de

seguridad de las zonas del disco duro que se utilizan para el inicio del sis-

tema operativo (normalmente los primeros sectores del disco), lo que obligaría

a gestionar éstas aparte o depender de software extra que se encargue de su

regeneración.


3. Clonación de particiones de disco duro a disco(s) ópticos:


a) Realizar la copia a un soporte óptico (CDROM o DVDROM) puede resultar

mucho más barato en costes.

b) Puede ser bastante más duradero en el tiempo.


a) Dado el tamaño actual de los discos duros y de la cantidad de software instalable

en ellos, es muy probable que la imagen no quepa en un solo disco óptico,

lo que obligaría a manejar múltiples volúmenes en CDROM o discos de tipo

DVDROM, resultando ser bastante más lento y un poco más caro.

b) Este tipo de soportes son muy sensibles a los cambios de temperatura, lo que

puede comprometer la fiabilidad del sistema de recuperación.

c) Si la copia se realiza en formato CDROM, resulta muy conveniente realizar una

compresión sin pérdidas de la imagen de disco que se quiere clonar para evitar

la creación de muchos discos. En estos casos, si se produce algún daño al disco

durante su manipulación, aunque los daños en el soporte óptico sean mínimos,

la recuperación será imposible.

d) El proceso será sensiblemente más lento y complejo tanto a la hora de la gene-

ración de la imagen como a la de la recuperación de la misma.

4. Clonación de disco duro a disco de red:


a) Si se tiene una buena infraestructura de red y una buena cantidad de disco libre,

puede resultar un método más eficiente.

b) Si se combina con otros métodos de red que permitan gestionar el arranque

puede ser mucho más cómodo ya que se evita la necesidad de gestionar otros

soportes físicos con las imágenes, almacenarlos y mantenerlos.

c) Este método es ampliable con facilidades que permitan gestionar la primera ins-

talación del sistema, lo que permitiría mejorar sensiblemente las prestaciones

del proceso.


a) Si se pretenden gestionar muchos sistemas operativos diferentes, puede resul-

tar un método muy complejo, dado que la gestión de otros nuevos introducirá

cambios en el sistema que habrán de permitir mantener los servicios ofrecidos

a los antiguos (compatibilidad hacia atrás).


b) Cuando se gestionan redes de área local o de área extensa con una gran cantidad

de ordenadores, ya sean de tipo servidor o de tipo cliente, el espacio requerido

para el almacenamiento de imágenes se hace muy grande y resulta necesario

utilizar técnicas de compresión de datos y de firmado de archivos, lo que ralen-

tizará el proceso de regeneración.

c) Los discos de almacenamiento en red suelen tener un coste elevado y requieren

planificar el posible crecimiento del servicio con bastante exactitud para evitar

la saturación del mismo.

3.4. Procedimientos desatendidos

Para que la regeneración o la instalación de un sistema operativo pueda no requerir la aten-

ción del usuario que pretende realizar la tarea, es necesario que el sistema sea capaz de auto-

configurarse. Ésto se hace normalmente gracias a la información contenida en algún soporte

alternativo que permite obtener la información que el propio usuario proporcionaría de forma

manual. En esta sección se describirán algunos de los métodos más extendidos a la hora de

implementar este tipo de soluciones. Algunas implementaciones posibles son las que se men-

cionan a continuación en sus diferentes estados y fases. En este apartado nos referiremos a las

tareas de regeneración exclusivamente, pero el lector habrá de tener en cuenta que estos proce-

dimientos también se pueden aplicar a la instalación indistintamente, así pues, lo que digamos

del uno en este apartado será válido de forma general para el otro.

3.4.1. Estado inicial

Como en todo sistema de tipo secuencial y automatizable, es muy conveniente partir de un

estado estable y conocido a partir del cual realizar la implementación del sistema que gestione

el resto de las fases. Nosotros consideramos que el estado inicial ideal para este sistema de

recuperación desatendida es el de que el ordenador que se pretende regenerar esté apagado.

Esta consideración no es trivial, aunque pudiera parecerlo. Todo sistema de regeneración

que se precie de serlo, debe regenerar la parte permanente de datos del ordenador sin necesitar

ningún requisito previo para realizar las tareas de regeneración automática, salvo, claro está, los

mínimos imprescindibles (acceso a los recursos físicos necesarios).

Hay sistemas de recuperación automática que están basados en tener un sistema operativo y

una aplicación instalados que permitan gestionar el proceso de recuperación de datos, aunque

éste sea de tipo automático y/o desatendido, pero éstos vendrían a ser más parecidos a sistemas

de backup que sistemas de regeneración.

Partamos, por tanto, de que el ordenador de tipo PC a regenerar está debidamente configura-


do para que la BIOS detecte las unidades de arranque configuradas para iniciar el sistema opera-

tivo desde ellas. Será necesario que el usuario del sistema de regeneración inicie la computadora

desde cero. Para ello, sería necesario apagarla -si está encendida- y volver a encenderla.

Para que la regeneración sea totalmente desatendida, realmente no debería ser necesario que

nadie tuviese que pulsar el botón de encendido del PC. Por ello, se han desarrollado sistemas

de arranque remoto que permiten iniciar un ordenador sin más que tener acceso a alguno de sus

recursos de la forma adecuada y que ésta opción esté previamente soportada y configurada en

el sistema (BIOS).

Por supuesto, para que el ordenador pueda iniciarse a la llegada de una determinada señal

externa, ha de permanecer encendido al menos un pequeño subsistema de gestión de arranque

que permitirá el arranque del ordenador completo. Eso supone que cuando el usuario apague

el computador realmente sólo apagará la parte principal del mismo, quedando este subsistema

encendido y alerta a la espera de la señal o señales que está preparado para detectar.

Los subsistemas de arranque remoto tienen diferentes nombres dependiendo del tipo de

señal que el ordenador espere recibir para iniciarse. Así, podemos mencionar, entre otros:

WOR, iniciales de Wake On Ring, que permite iniciar un ordenador si se recibe una

llamada a la linea a la que está conectado el módem del sistema.

WOL, acrónimo de Wake On Lan, que permite iniciar un PC si recibe un paquete espe-

cialmente formado a través de la red a la que esté conectado.

WOT (Wake On Time) que permite iniciar un computador a una hora determinada de una

fecha determinada, normalmente con algún parámetro de repetición programada.

Cabe decir como resumen que mediante estos subsistemas de arranque remoto será posible

iniciar el proceso de regeneración desatendida sin necesitar la presencia del usuario, lo que

permitirá no sólo automatizar mucho más el sistema, sino también realizar las tareas del mismo

en períodos en los que nadie lo está usando (normalmente durante la noche), lo que dará al

proceso desde el punto de vista de la eficiencia un gran valor añadido.

3.4.2. Fase de arranque

La siguiente tarea que es necesario realizar en un sistema de tipo PC es gestionar el arranque

o inicialización del mismo. Este proceso, es el que lleva al ordenador a cargar un sistema operati-

vo en memoria, y por lo tanto el que inicializa los recursos disponibles del sistema (CPU, memo-

ria, adaptadores, etc). Para hacerlo hay diferentes opciones a disposición del administrador. Las

analizaremos para ver qué opciones nos ofrecen.


1. Sistemas de arranque basados en soporte magnético y/o óptico:

En este caso, el ordenador PC al inicializarse tiene disponible, a través de alguna de las

unidades de datos extraíbles (como vienen a ser la disquetera o el lector de CDs o DVDs),

un disco que contiene un pequeño sistema operativo y (normalmente) el programa que

se utilizaría para regenerar el disco duro del ordenador. El ordenador, al arrancar, dará

control a este pequeño sistema operativo.

En algunas ocasiones, el disco extraíble utilizado para la recuperación podría incluso

contener la información que deseamos volcar sobre el disco duro del ordenador lo que

resultaría muy cómodo y eficiente.

2. Sistemas de arranque basados en memoria no volátil (NVRAM)

Son sistemas que utilizan un dispositivo hardware extra, normalmente diseñado expresa-

mente para este tipo de sistemas, cuya misión es la de gestionar el arranque del ordenador

desde una imagen almacenada en el mismo y que está configurada para permitir la copia

de los datos que se desean recuperar bien desde un servidor de red que se la proporcione

o bien desde algún otro dispositivo extraíble o no del ordenador.

Este tipo de sistemas suelen ser de tipo propietario y más recomendables en entornos de

aplicación específica. Su hardware constituye un gasto extra ineludible y no suele tener

capacidad de expansión. La memoria que utilizan es de tipo no volátil, lo que permite el

acceso aleatorio a las posiciones de la misma. Para el ordenador que la alberga aparece

como un disco duro o como un programa en memoria que recibe control de la BIOS y

en fase de arranque suele ser de sólo lectura, de tal forma que un fallo en el proceso o la

interrupción del fluido eléctrico no deterioren la información que contiene.

3. Sistemas de arranque basados en servicios de red:

Todos utilizan una pequeña memoria no volátil de almacenamiento tipo EPROM o FLASH

que contiene un programa de arranque de red que, mediante la utilización de unos proto-

colos de red expresamente diseñados para la configuración de sistemas y la descarga de

datos, permite:

a) Configurar el dispositivo de red y enviar a través del mismo una petición de infor-

mación.

En los sistemas de los que disponemos, la información, que está inicialmente al

alcance del programa de arranque que utiliza los servicios de red, sólo le permite

establecer conexiones de red a un nivel muy bajo en la pila de protocolos. Este nivel

es el llamado nivel de enlace en el modelo de comunicación OSI y sólo le permite

comunicarse con otros equipos que estén en su misma subred local.


Por lo tanto, esta petición se hace únicamente a nivel del protocolo de enlace, lo que

obliga a que:

la subred disponga de un sistema capaz de dar una respuesta de forma local, o

que

la subred disponga de un sistema capaz de escuchar la petición, buscar en otras

subredes una respuesta válida y reenviársela al ordenador como si fuese suya,

realizando lo que viene a ser la función de un proxy del protocolo.

Hay diferentes soluciones posibles para la configuración del sistema de red local en

los ordenadores PC. Baste mencionar los nombres de los protocolos más extendidos

para redes TCP/IP: PXE, DHCP, BOOTP, RARP.

b) Extrayendo la información de la respuesta, configurar la parte de la pila de proto-

colos de transmisión de datos a nivel de red, lo que permitiría al equipo establecer

conexiones de datos más allá de su subred local.

c) Descargar del servidor especificado (que ya no tiene por qué estar en la subred local)

los datos necesarios para el arranque de el sistema operativo que permita iniciar el

computador. Es necesario matizar que no todos los sistemas operativos permiten su

descarga inicial desde la red, aunque la mayoría de ellos disponen de cargadores que

llegarían a conseguir este fin utilizando fases intermedias de carga y descarga.

También es interesante comentar que los datos traídos del servidor pueden utilizarse

para presentar un menú al usuario y permitirle elegir entre varias opciones de arran-

que, algunas de las cuales llevarían a la instalación o regeneración del sistema, mien-

tras que otras llevarían al arranque normal del sistema a partir de su propio disco

duro o cualquier otro dispositivo. Este tipo de menús suelen tener configurada una

opción de arranque por defecto que arranca el sistema de forma automática en caso

de que se cumpla un tiempo de espera determinado.

En estos casos, el arranque se realiza en dos pasos intermedios: en uno se traen los

datos de un menú y en el siguiente se carga o descarga la imagen seleccionada, a

partir de la que se iniciará el sistema.

3.4.3. Fase de comprobación

Resulta fundamental que el sistema operativo iniciado sea capaz de comprobar el estado

y configuración de los diferentes dispositivos de que dispone. Con ello, se conseguirá que el

sistema de regeneración disponga de un listado de características que permitan obtener los

parámetros necesarios para realizar la autoconfiguración de la aplicación de regeneración desa-

tendida. Así, por ejemplo, se podría elegir la imagen de regeneración en función de la dirección


IP de la máquina a regenerar. Esta fase es sencilla de implementar y permite también evitar

errores básicos en los procesos de regeneración posteriores.

3.4.4. Fase de instalación automática o regeneración cruda

Normalmente se basa en la ejecución de forma automática de un programa específicamente

dedicado a la regeneración o instalación del sistema. Este programa utiliza los parámetros

obtenidos en la fase anterior y puede ser diferente en función del sistema operativo que se

vaya a regenerar o instalar. También puede ser diferente en función del tipo de medio a partir

del cual se vaya a realizar. Más detalles sobre estos procedimientos se pueden encontrar en la

sección 3.2 y en la sección 3.3.

3.4.5. Fase de rearranque

Aunque no siempre tiene que ser así, normalmente la regeneración de un sistema le permite

volver a funcionar de forma autónoma dentro de su red. En esta fase se da control al sistema

recién regenerado para que actualice la información interna del sistema operativo y pase a ser

un sistema totalmente independiente. El proceso comienza con un apagado del ordenador y un

reinicio del mismo, esta vez sin utilizar los procedimientos de regeneración. Para ello, habrá que

configurar el sistema central de administración y cambiar el estatus de la máquina de forma que

no entre en un bucle de regeneración en el caso de que realice una nueva petición de arranque

de red. Igualmente, habrá que quitar el disco de arranque si es que la regeneración no se hizo a

través de la red.

3.4.6. Fase de finalización

En esta fase, se configuran los servicios y se realizan las actualizaciones del sistema opera-

tivo. Una vez hecho esto, se comprueba el funcionamiento del sistema y se da por terminado el

proceso de regeneración.

3.4.7. Estado final

El estado final es dependiente del tipo de ordenador que hemos regenerado. En nuestro caso

hemos contemplado dos tipos de ordenadores: servidores y clientes. Si el ordenador regenerado

es del primer grupo, parece conveniente que permanezca encendido después del proceso, para

así continuar dando servicio a través de la red de aquello para lo que esté configurado. En caso

de pertenecer al segundo grupo, es decir, si el ordenador es un sistema cliente, probablemente

resulte más conveniente apagarlo hasta que algún usuario decida utilizarlo.

Capítulo 4

Arquitectura

4.1. Gestión de red local (nivel de enlace)

Dada la gran cantidad de datos que se necesitan para realizar la instalación del sistema

operativo y sus aplicaciones, esta red local ha de tener un ancho de banda suficientemente alto.

Además, resulta ser muy recomendable que todos los ordenadores tengan la misma tecnología

de acceso a la red, ya que si unos acceden de forma más rápida que otros a la red, los más lentos

se podrían ver desfavorecidos. Este es el caso de las redes Ethernet (802.3) en las que puede

haber equipos conectados a 10, 100 o 1000 Mbps conviviendo en la misma red local.

La decisión tomada por el equipo de trabajo para la implantación de la red que daría servicio

al nuevo laboratorio integrado en el sistema de administración centralizada fue la de utilizar la

mejor tecnología disponible del momento, dentro del segmento de redes de área local, la norma

Fast-Ethernet o también llamada 100baseTX. La red que se desarrolló se basó en una red de

cableado estructurado de categoría 6 (capaz de permitir la interconexión de equipos a 1Gbps)

dado que se preveía el posible futuro cambio de tecnología a 1000baseTX. Se han evitado en la

medida de lo posible los equipos repetidores (Hubs) con el fin de dar el mejor acceso al equipo

final y tener un mejor nivel de seguridad. Por eso, los equipos de interconexión utilizados para

la mayoría de los equipos de usuario son conmutadores ethernet que están interconectados entre

sí a través de un backbone de 1Gbps también basado en tecnología Ethernet.

Todos los servidores están conectados entre sí como mínimo a 100Mbps en un sólo con-

mutador de alta capacidad, para mejorar la velocidad de interconexión entre ellos. Incluso,

dependiendo de la carga de red que soporten cada uno de ellos, es posible mejorar su servicio

conectándolos al backbone a 1Gbps. Esto puede resultar necesario para servidores compartidos

por todos los clientes (como por ejemplo los servidores de disco en red) o para servidores que

requieran un gran ancho de banda (por ejemplo para poder hacer backups de forma rápida o

para aplicaciones multimedia).

Para poder aislar grupos de ordenadores del laboratorio con el fin de hacer ciertas prácticas

28

4. Arquitectura 29

de administración de equipos sin interferir con el resto, también se ha dotado al laboratorio de

sistemas de conmutación de ethernet capaces de gestionar redes virtuales o VLAN [48] (véase

la especificación 802.1Q para más información). Esta tecnología también se puede utilizar para

hacer prácticas de gestión de routers en equipos que tienen un sólo interfaz de red, para eso los

routers han de ser capaces de acceder a varias VLAN a través de él.

Para poder hacer una monitorización a nivel de trama ethernet de algún equipo concreto en

caso de problemas, también debe ser posible configurar el conmutador ethernet para que repita

en uno de sus puertos todo lo que reciba del puerto conflictivo.

4.2. Gestión de red de acceso (nivel de red)

La red que hemos implementado para interconectar los equipos es una red estándar IPv4,

aunque en el futuro se prevé la necesidad de crear redes de tipo IPv6 y proveerlas de los mismos

servicios de que disponen las actuales. La red principalmente hace uso de servicios unicast

aunque, para poder realizar determinadas prácticas de protocolos, también están configuradas

rutas multicast locales.

La red de un laboratorio debe ser siempre considerada una red de pruebas y, como tal,

también puede ser una red insegura (resulta fácil imaginar que algún alumno apurado de tiempo

pretenda copiar prácticas o conseguir claves de acceso a través de la red).

La red de los laboratorios está dividida en dos subredes IP diferentes separadas por un

router. La red más externa (y más próxima a Internet) es la que alberga los servidores públicos

del laboratorio (DNS, HTTP, HTTPS, SMTP, etc). La red más interna, por otra parte, es la que

utilizan los ordenadores del laboratorio propiamente dicho.

A su vez, la red más externa está conectada a Internet a través de un cortafuegos. El router

hace forwarding a nivel IP entre las dos redes y también permite (a través de un proxy) que las

máquinas de la subred interna del laboratorio tengan acceso a los servidores HTTP, HTTPS,

FTP y GOPHER de Internet, del laboratorio y del DIT.

Todos los servidores mencionados están basados en sistemas GNU/Linux RedHat 7.3. El

proxy está configurado mediante Squid [44], mientras que la administración del cortafuegos se

realiza con el sistema Iptables [45] y Fwbuilder [46].

4.3. Gestión de equipos

Para la realización de este proyecto no sólo es necesario crear buenos procedimientos de

automatización de las configuraciones e integrarlos entre sí para permitir el máximo rendimien-

to (como iremos contando en este capítulo), sino que también juegan un papel importante las

características de las máquinas que se pretenden administrar. De este modo, será fundamental

4. Arquitectura 30

(para evitar tener que hacer trabajos extra) que los ordenadores cliente del sistema de adminis-

tración centralizada sean máquinas compatibles con el estándar PXE [11]. Hoy en día la práctica

totalidad de los ordenadores con la tarjeta de red integrada (sobre todo en equipos de la marca

Intel, que fue uno de los principales impulsores de la especificación) tienen la ROM de la tarjeta

de red preconfigurada y accesible para gestionar el arranque mediante PXE. Si no se dispone de

equipos de estas características, habrá que instalarles el hardware y el software necesarios para

que dispongan de ellas (como pueden ser las propias ROM o los programas de las mismas).

Además, para la gestión de equipos que están en sitios públicos y expuestos al robo eventual,

también será necesario que los ordenadores tengan algún tipo de elemento antirrobo que permita

introducir un candado o una cadena de seguridad para anclarlos físicamente al laboratorio.

Otro consejo fundamental para la administración de este tipo de redes, es asegurarse en

la compra una garantía del fabricante suficientemente amplia para que el personal técnico no

tenga que realizar reparaciones de hardware en estos equipos al menos en los primeros 3 años

de funcionamiento. Hoy en día, este tipo de garantías suelen ser in-situ y cubrir el 100 % de los

dispositivos del ordenador, lo que evita pérdidas de tiempo del personal técnico en la detección

de problemas en la mayor parte del tiempo de vida útil del ordenador cliente.

En cuanto a estas reparaciones locales, aunque no serán necesarias si se negocian buenas

garantías, siempre hay que tener algunos repuestos disponibles para los equipos más críticos.

Así, por ejemplo, resulta conveniente tener algunas fuentes de alimentación, ventiladores y

disipadores, lectores de CD, discos duros y disqueteras, además de personal experto en hardware

de PC.

También por estar en lugar público, resulta necesario inhabilitar el acceso del usuario a la

BIOS del sistema mediante la configuración de una clave de acceso para la administración. Sólo

usando esta clave, se podrán configurar los parámetros de arranque del ordenador, y evitar que

éste arranque desde otro medio que no sea la red (disquete, lector de CD-ROM o disco duro).

Así, disminuirán los intentos de ataque al sistema o captura de claves mediante la instalación

sin consentimiento de algún sistema operativo capaz de realizar estas tareas.

Por todo esto, será necesario tener personal preparado para ser capaz de configurar ade-

cuadamente las BIOS de los ordenadores, administrar las claves de acceso y actualizar el

firmware de las ROM de las tarjetas cuando sea necesario, ya que puede haber diferencias

importantes en el tiempo y la funcionalidad de arranque entre dos versiones diferentes del mis-

mo.

4.4. Gestión de arranque de red

El sistema de arranque de red debe estar accesible en el momento justo posterior a la fase

de la BIOS y se debe configurar manualmente la primera vez que se pone en funcionamiento el

4. Arquitectura 31

ordenador.

Una vez que el computador ha pasado la fase de inicialización hardware de la BIOS, éste

comienza la fase de arranque. Si la hemos configurado adecuadamente, se accederá al programa

almacenado en la ROM de la tarjeta de red para realizar a través de ésta una petición de tipo

PXE. Para que esto funcione así, la tarjeta de red ha de estar conectada a un equipo repetidor de

red (hub o switch en caso de ethernet) y tener el LED de enlace activado, indicando que pueden

enviar y recibir tramas por ese interfaz.

El programa de la ROM de la tarjeta de red realizará primeramente una petición de tipo PXE

(que debería ser respondida por un servidor de PXE). Si esta petición no es respondida después

de un cierto tiempo, se efectúa de nuevo hasta un máximo de 3 veces. Si sigue sin ser respondida,

a continuación, se realiza una petición DHCP (que puede responder tanto un servidor de DHCP

como uno de BOOTP ya que los protocolos si bien son distintos, son compatibles entre sí). Sólo

si esta petición (repetida también hasta 3 veces) no es respondida adecuadamente, se continúa

el arranque a través del siguiente dispositivo de arranque configurado, ya sea éste el disquete,

lector de CD-ROM o el disco duro. En caso de no haber ningún otro dispositivo configurado

para continuar el arranque, se reiniciaría el proceso de arranque desde la ROM auxiliar del

sistema. Si el proceso de arranque de red falla un número determinado de veces, el ordenador

finalmente cesa en el intento y queda a la espera de un reinicio físico o un comando manual.

Actualmente, en los laboratorios docentes del DIT se utilizan 6 servidores de arranque.

Están configurados para servir DHCP [12] mediante el software de ISC [47] y dan servicio de

forma concurrente, compitiendo entre sí por responder al cliente sus peticiones de arranque de

red. Una vez que el cliente obtiene una respuesta, utiliza el servidor que le ha respondido (o

en casos específicos el que está configurado) para descargar mediante protocolo TFTP [21] un

fichero que permita gestionar el inicio de la máquina local (normalmente mediante un menú de

opciones que se ofrecen al usuario). Esta configuración del servicio, aunque obliga a que todos

los servidores intenten responder a cada cliente que hace una petición DHCP, ha resultado ser

muy conveniente, puesto que el cliente elige al servidor que más rápidamente le proporciona la

respuesta, equilibrándose de forma automática la carga de los servidores y permitiendo manejar

adecuadamente posibles problemas de congestión en servidores puntuales, ya que todos los

servidores pueden dar servicio a cualquier cliente.

La configuración de cada uno de estos servidores DHCP es realizada por el sistema de

administración centralizada y permite personalizar la configuración de cada servidor para que

redirijan al cliente al fichero de arranque adecuado. Para ello, se parte de la base de un fichero de

configuración común para todos ellos, que en lugar de apuntar a servidores concretos contiene

ciertas palabras clave que son sustituidas por el nombre del servidor que se quiera configurar

mediante una herramienta estándar de Unix (sed [49]), gestionándose todo el conjunto con la

herramienta make [50].

4. Arquitectura 32

Las imágenes y los menús que se descarga el cliente a través de TFTP también están en cada

uno de los servidores y son exactamente iguales en todos ellos. La distribución y sincronización

del árbol de directorios de los servidores TFTP se realiza mediante rdist [51]. Aunque se podría

haber utilizado para este caso rsync [52], rdist resulta más útil puesto que permite ejecutar en el

servidor remoto (al que se ha distribuído el árbol) un scripta de configuración, que por ejemplo

reiniciaría el servidor TFTP.

La imagen de inicio que el ordenador cliente descarga por TFTP, para nuestra configu-

ración particular, puede ser la proviniente de dos sistemas software de arranque de los que

hemos comentado algo previamente: GRUB [29] o Pxelinux [10]. Si bien GRUB ha sido uno

de los pioneros en gestionar el arranque a través de la red de ordenadores PC basándose en

el estándar PXE, tenemos que decir que tiene un problema importante: sólo permite gestionar

imágenes PXE para las tarjetas específicas que es capaz de soportar y cuyos driversb hereda de

otro proyecto (Etherboot [8]). Por eso, cuando se usa GRUB y se quiere permitir el arranque

de equipos PXE, es necesario utilizar de forma exclusiva las tarjetas soportadas. Por lo demás,

GRUB es un gestor de arranque muy versátil y potente que permite la especificación del menú

en un fichero también descargado por TFTP y especificado a través de una opción especial en

el registro DHCP del cliente.

Las características de Pxelinux son bastante más potentes en este sentido, ya que permite

gestionar (mediante la imagen descargada al ordenador cliente) la tarjeta de red, gracias a la

utilización del driver de la misma que incluye el fabricante en la propia ROM, cumpliendo así,

el estándar PXE. Para ello, el driver contenido en la ROM de la tarjeta de red ha de imple-

mentar una interfaz común, llamada UNDI (siglas de Universal Network Driver Interface). Con

Pxelinux también es posible descargar un menú (aunque quizá menos potente y más difícil de

configurar que el de GRUB) que permite mostrar al usuario las opciones de arranque de una

forma clara y sencilla.

4.5. Gestión de disco local

Dada la necesidad de múltiples sistemas operativos en los ordenadores cliente de los labo-

ratorios docentes del DIT (Windows XP y GNU/Linux), hemos tenido que permitir en los or-

denadores cliente el arranque desde el disco duro local. Ya explicamos con anterioridad que no

es posible, hoy por hoy, descargar el núcleo de Windows XP desde la red y darle control, por lo

que este sistema operativo ha de quedar instalado en el disco duro del ordenador.

Sin embargo, con el sistema operativo GNU/Linux sí es posible descargar el núcleo a través

de la red y por lo tanto no resulta necesario tenerlo instalado en el disco local (más que las partes

ascript: conjunto de comandos agrupados en un fichero y ejecutados de forma secuencialbdriver: código específico que gestiona un dispositivo de un sistema

4. Arquitectura 33

que consideremos necesarias para evitar el uso excesivo de la red). El problema de ubicación del

Windows XP es una pega importante, ya que no permite gestionar íntegramente el ordenador

desde la red, pero también tiene una pequeña ventaja y es que en caso de no funcionar los

servidores de arranque de red (por cambio, fallo o actualización de los mismos) el sistema

podría arrancar de disco local y seguir dando servicio al usuario de la máquina cliente.

Si vamos a la gestión física del disco duro del sistema, ésta se compone de 3 fases: parti-

cionado, formateo e instalación del sistema operativo. Estas tareas se pueden realizar de forma

automática en GNU/Linux pero no resulta tan sencillo en Windows XP. Por eso hemos adop-

tado una solución mixta que resuelve el problema y que consiste en la utilización del sistema

operativo GNU/Linux para realizar la mayor parte de las tareas de particionado y formato de

disco. En concreto se usarán fdisk [41] para particionar los discos de forma automática,mke2fs

para formatear las particiones de GNU/Linux (ext2 y ext3) ypartimage [38] para regenerar

tanto el formato como los datos de las particiones de Windows XP (NTFS).

4.6. Gestión de instalaciones

Hay varios tipos de instalación que han sido integradas en el sistema de administración

centralizada y para cada uno de ellos, dedicaremos una subsección en este apartado. La clase

de instalación que se pretende gestionar es aquella que se puede realizar de forma automática

y desatendida, sin requerir la presencia de un administrador para la realización de la tarea. Hay

que recalcar que el sistema diseñado está configurado para realizar las instalaciones de ciertos

sistemas operativos (Windows XP y GNU/Linux) y que cambiarlos puede suponer cambiar en

parte los detalles, pero se mantendría en todo caso la filosofía general del procedimiento.

Para independizar las funciones y aumentar el rendimiento, se han creado tres niveles jerár-

quicos diferentes:

Servidor principal o maestro de administración centralizada. Pertenece al nivel superior.

Desde él se configura todo lo que luego se distribuye o gestiona desde los servidores

esclavos.

Servidor secundario o esclavo de administración centralizada (intermediario entre el sis-

tema maestro y el sistema cliente). Desde él se distribuyen todos los servicios de los que

dispone un cliente. A los servidores secundarios que permiten el arranque de los clientes,

les llamamos también binarios, mientras que el resto son servidores secundarios de servi-

cios comunes.

Servidor terciario o cliente. Utiliza los servicios proporcionados tanto por los servidores

de jerarquía inmediatamente superior, como por otros servidores accesibles. Su función

principal es dar servicio al usuario final.

4. Arquitectura 34

El sistema está pensado para poder gestionar tanto instalaciones como regeneraciones, según

resulte más conveniente.

Figura 4.1: Esquema de la jerarquía de servidores

El servidor principal está diseñado de tal modo que es el servidor desde el que se instalan y

se administran los servidores secundarios (exactamente igual que se instalan los clientes desde

los servidores secundarios). Por eso, la distribución jerárquica de funcionalidades permite con-

seguir una ventaja añadida: desde el sistema maestro es posible regenerar todos los servidores

y clientes en caso de catástrofe general, lo que aporta una gran robustez y fiabilidad.

4.6.1. Instalación automática de servidores GNU/Linux

Para realizar la tarea de instalar de forma desatendida un servidor GNU/Linux es muy con-

veniente basarse en la utilización de las herramientas de autoinstalación que el proveedor (de

la distribución concreta que queramos instalar) suele proporcionar. De esta forma, se ahorra

una buena cantidad de trabajo. Aún así, estas herramientas no son todo lo completas que re-

sulta necesario ya que no se encargan de realizar más que una configuración muy básica de las

aplicaciones instaladas en el servidor y además no son capaces de instalar aplicaciones que no

pertenecen a la distribución.

Para obtener un servidor GNU/Linux completamente instalado y configurado será necesaria

la utilización de otras herramientas (que en este caso se han desarrollado expresamente para

este proyecto) que permitan automatizar la creación de los ficheros de configuración utiliza-

dos por los autoinstaladores y para configurar y añadir aplicaciones (ajenas o no a la propia

distribución).

4. Arquitectura 35

Los servidores RedHat GNU/Linux instalados, usan la versión 7.3 de la distribución Red-

Hat Linux y, por tanto, las herramientas creadas están particularizadas para este sistema ope-

rativo, aunque se prevé la generalización de las mismas para otras distribuciones también de

GNU/Linux.

El requisito inicial para la generación de un fichero de configuración de la herramienta

Kickstart (el autoinstalador de sistemas de RedHat) es disponer de los detalles de configuración

del hardware del servidor (relativos a los dispositivos físicos) y la lista de paquetes a instalar

dentro de los disponibles en la propia distribución RedHat. Por detalles hardware se entiende

la especificación del tipo de tarjeta de vídeo, tipo de disco y particiones, tarjeta de red, etc.

La lista de paquetes predefine el software que se instalará en el servidor GNU/Linux mediante

Kickstart.

Esta lista de paquetes puede contener identificadores de grupos de paquetes (que ya vienen

predefinidos en la instalación) o bien paquetes individuales. Los grupos de paquetes predefinidos

suelen ser de propósito general y por tanto, poco apropiados para nuestro entorno, lo que nos

obliga a generar nuestros propios grupos de paquetes para la instalación de nuestros servidores.

Esta tarea deberá realizarse una única vez y habrá de ser llevada a cabo por el administrador

teniendo en cuenta las necesidades comunes de la red de servidores que pretende administrar.

En el caso de RedHat, la gestión de grupos de paquetes se realiza a través del ficherocomps que

aparece bajo el directorio/RedHat/base dentro del primer CD de instalación. En nuestro caso,

podemos modificar este archivo según nuestras necesidades puesto que reside en un dispositivo

de lectura y escritura que exportaremos por NFS para dar el servicio de instalación.

Aunque el proceso de instalación habitual utiliza un disquete o CD para gestionar el arran-

que de la máquina y comenzar la instalación desatendida, la opción más deseable para nuestro

sistema es la utilización de la propia tarjeta de red para descargar los archivos de arranque e

instalación. Para ello, habrá que administrar los diferentes servidores a partir de los cuales se

gestionará el proceso.

Los posibles medios de instalación por red para el caso de RedHat son: servidor Web

(HTTP), servidor FTP y servidor NFS. También cabe la posibilidad de utilizar un proxy para

acceder a estos servicios, lo que permite el acceso desde redes aisladas o parcialmente aisladas,

siendo necesario modificar la configuración adecuadamente.

El arranque de las máquinas se hará según se describe en la sección 4.4, pasando como

parámetro al núcleo de Linux (vmlinuz) el tipo de instalación y la localización en la red

del fichero de configuración de la instalación desatendida (ks=nfs:AC_IP_DEL_SERVIDOR:-

/kickstart/ks.cfg, donde habría que sustituirAC_IP_DEL_SERVIDOR por la dirección IP

física del servidor que contiene el archivoks.cfg).

Mediante Kickstart también es posible configurar la ejecución de tareas en la fase inmedia-

tamente anterior y posterior a la fase de instalación, lo que proporciona ciertas facilidades de

4. Arquitectura 36

configuración fuera de las estrictamente contempladas (como por ejemplo, el enviar un correo

al administrador).

Dada la cantidad de factores modificadores, la tarea de generación del fichero de configu-

ración de Kickstart para cada uno de los servidores ha de ser asumida por nuestro sistema de

gestión centralizada. Para ello, se partirá de una base de datos que deberá estar disponible y que

deberá contener las características particulares de cada servidor. Por eso, para complementar

las tareas de instalación que automatiza el Kickstart, han de desarrollarse algunas herramientas

que permitan realizar en el sistema recién instalado el resto de tareas de administración. Tam-

bién será necesario crear ciertas infraestructuras que puedan ser utilizadas para el resto de los

servicios de administración.

Se enumeran a continuación las tareas más importantes a desarrollar por el sistema de ad-

ministración centralizada, dentro de las que implican la instalación automática y desatendida de

nuevos servidores GNU/Linux:

Creación y gestión de una base de datos de administración que incluya el perfil concreto

de cada servidor. Esta base de datos ha de contener, no sólo las características hardware

del servidor a instalar, sino también sus características software, proporcionando al sis-

tema de administración una visión completa de los parámetros necesarios en el proceso

de instalación.

Generación automática del fichero de configuración de Kickstart (ks.cfg) para cada

servidor, a partir del perfil almacenado en la base de datos de administración. Para ello,

se ha diseñado una herramienta que hemos llamadomkdist.

Generación de imágenes de disco de arranque (tanto en formato disquete como en formato

CD). El disquete es necesario para iniciar los servidores que no tengan ROM de arranque

en su tarjeta de red. El CDROM, además de eso, permite instalar desde el propio CD las

aplicaciones que estén contenidas en él. Esta tarea también la realizamkdist.

Gestión automática de los servidores DHCP y DNS, modificando su configuración cuan-

do se crean o se eliminan clientes de sus servicios, y reiniciándolos para que incluyan

los cambios. De esta tarea se encarga una herramienta creada específicamente y fuera del

marco de este proyecto, que hemos llamadoinstall.hosts.

Gestión de servidores de ficheros (TFTP, NFS, FTP y HTTP) para que sean capaces de

exportarlos a los clientes que los necesitan. Normalmente, esta tarea debería requerir poco

tiempo y ser suficientemente estable como para no necesitar automatizarla.

Gestión automática de las claves SSH, para evitar que se pida la intervención del admi-

nistrador para aceptar la clave la primera vez que se ejecuta un comando remoto desde el

servidor de administración. Esta tarea se puede realizar mediante el scriptssh-keyscan.

4. Arquitectura 37

Configuración del software instalado, instalación de aplicaciones no estándar, actuali-

zación automática del software y realización de otras tareas automatizables. Para ello,

hemos desarrollado la herramientaautoactualiza.

Administración automática de usuarios, grupos, cuotas de disco, listas de correo y alias

de usuarios (en los servidores instalados de forma automática). Para ello, usamos varias

herramientas creadas especialmente por nosotros:labadmin y mkcuentas.

Los detalles de implementación de la solución adoptada para manejar la problemática de esta

sección, se detallan en el punto 5.2.2.

4.6.2. Instalación automática de clientes GNU/Linux

Hemos llamado clientes GNU/Linux a los ordenadores con sistema operativo GNU/Linux

que se utilizan en el laboratorio para realizar las prácticas docentes, para evitar la ambigüedad

con los servidores instalados de forma automática de la sección 4.6.1. Por motivos de rendimien-

to y aprovechando que todos los clientes GNU/Linux del laboratorio son prácticamente iguales

entre sí, salvo en detalles de configuración del hardware, decidimos evitar los procesos de ins-

talación automática como los descritos para servidores GNU/Linux y realizar una instalación

a medida para ellos, que está a medio camino entre la gestión de imágenes y la instalación de

servidores.

El proceso fundamental se basa en crear un fichero comprimido que agrupa los archivos

existentes en un servidor GNU/Linux previamente instalado con los requisitos necesarios. Este

archivo se genera en el servidor de administración de forma automática a partir de una lista de

archivos requeridos. Después, este fichero se transmite por la red, se descomprime en el disco

duro y se le cambian los parámetros necesarios para que el cliente pueda iniciar sus dispositivos

particulares.

Los detalles de implementación de la solución adoptada para manejar la problemática de

esta sección, se detallan en el punto 5.2.3.

4.6.3. Regeneración automática de clientes Windows XP

Mientras que para GNU/Linux todos los clientes eran iguales de forma casi total porque se

puede instalar en todos ellos prácticamente el mismo núcleo del sistema operativo (diferencian-

do entre ellos la CPU), en el caso de Windows XP nos encontramos con que es necesaria una

imagen diferente por cada uno de los ordenadores con placa base diferente.

Esto significa, que vamos a necesitar agrupar nuestros ordenadores en función de su placa

base y crear una imagen de regeneración para cada uno de esos tipos. En nuestro laboratorio,

debido a la política de compra de ordenadores, tenemos grupos lo bastante amplios como para

4. Arquitectura 38

gestionarlos todos con sólo dos imágenes diferentes. Si esto no fuese así, la tarea de adminis-

tración de este tipo de regeneraciones podría llegar a ser demasiado costosa.

La gestión de regeneraciones es una técnica que, en nuestro caso, sólo hemos decidido

utilizar para reinstalar particiones con el sistema operativo Windows XP y formato NTFS, pero

es lo suficientemente general como para poder ser aplicada a cualquier otro sistema operativo

y tipo de formato de disco duro dentro de los que soporta la aplicación principal utilizada ello,

partimage [38].

El proceso concreto se basa en el utilizado para la gestión de instalaciones para clientes

GNU/Linux, pero usando una aplicación que es capaz de realizar la regeneración cruda de

particiones de disco, regenerando a la vez formato (en el caso de Windows XP, NTFS) y datos

de las mismas (árbol de directorios, archivos y ficheros) bit a bit. Esta aplicación es ejecutable

en Linux desde la imagen de disco virtual descargada inicialmente de la red y permite regenerar

la partición deseada desde un fichero que puede ser local o estar accesible a través de la red.

Los detalles de implementación se facilitan en la sección 5.2.4.

4.6.4. Instalación automática de clientes Windows XP

La instalación automática de clientes Windows XP es una técnica basada en las facilidades

proporcionadas por el fabricante del sistema operativo (Microsoft [18]), para la instalación desa-

tendida de las estaciones. Aunque hay varios documentos ([14, 15]) que describen los esfuerzos

realizados por esta compañía por facilitar la gestión de las tareas de instalación en entornos de

grandes redes corporativas, la verdad es que no se han podido llevar a la práctica por diversos

problemas de compatibilidad y rendimiento que hasta hace relativamente poco no se han llegado

a resolver.

La solución adoptada por nuestro sistema de gestión se basa en la utilización de ciertas

aplicaciones que permiten configurar los dispositivos locales (disco duro y tarjeta de red, prin-

cipalmente) y obtener las configuraciones y los archivos de instalación a través de la red. Luego

se efectúa una instalación desatendida también a través de la red y en una fase de postinsta-

lación se generan los usuarios y se instalan las aplicaciones extra (no incluidas con el sistema

operativo).

Los detalles sobre la implementación de este proceso para el sistema de administración

centralizada se pueden consultar en la sección 5.2.5 y también a través de la documentación

proporcionada por Pedro J. Pérez [62] y por Karl Bernard [61]. Sobre la generación de insta-

laciones de aplicaciones automatizables para Windows hay más información en las páginas de

Autoit [23] y WinstallLE [39] de Veritas, así como en Microsoft [18].

4. Arquitectura 39

4.7. Gestión de servicios generales

En esta sección, se pretenden agrupar aquellos servicios que son de carácter general y sue-

len ser, si no estrictamente necesarios, muy comunes no sólo en el entorno de aplicación de

este proyecto sino en cualquier entorno moderno de trabajo cooperativo en Internet. Aunque la

práctica totalidad de los servicios que se mencionan están basados en servidores implementados

en el sistema operativo GNU/Linux, hay que tener presente que los ordenadores que los utilicen

pueden utilizar cualquier otro sistema operativo, dado que los servicios que proporcionan son

de uso común y su objetivo final es la interoperabilidad de sus clientes. Los servidores que ofre-

cen los servicios que se mencionan a continuación también están integrados en el sistema de

administración centralizada, realizando el papel de servidores secundarios y por tanto estando

directamente administrados desde el servidor principal de administración.

4.7.1. Gestión de usuarios

Es importante resaltar que en el modelo de sistema que hemos diseñado, los usuarios sólo

tienen cuenta en los clientes del laboratorio, de tal forma que no se ejecutan sus tareas en

ninguno de los servidores que gestionan su arranque o configuración. La gestión de usuarios se

realiza siempre en el servidor principal de administración, que es quien se encarga de distribuir

las configuraciones adecuadas a cada servidor.

En el sistema de gestión de usuarios hay varios aspectos importantes implicados. A saber:

gestión de nombres de usuario,

gestión de grupos de usuarios,

gestión de números de identificación de usuarios y grupos,

gestión de cuotas de disco,

gestión de la configuración de usuarios de correo electrónico (aliases),

gestión de permisos de acceso de usuarios y grupos,

gestión de claves de acceso (Unix y Samba),

distribución de las cuentas a los servidores de configuración y

exportación de disco de red para los usuarios en los servidores de disco de red.

Para la realización de todas estas tareas se han realizado varias aplicaciones que trabajan en

conjunto. Los nombres que les hemos dado son:labadmin, mkcuentas y mkcuota.

4. Arquitectura 40

La distribución de las configuraciones y la ejecución de alguna de estas aplicaciones, se

realiza de forma periódica a través de un sistema llamadocron en los sistemas GNU/Linux,

que no es más que un gestor de tareas a partir de patrones temporales (scheduler).

4.7.2. Gestión de impresoras

La gestión de impresoras es una de las tareas más complicadas de realizar desde servidores

GNU/Linux. Si bien, la exportación a través de red de impresoras y la gestión de usuarios que las

comparten es relativamente sencillo utilizando el sistema Samba, hay un problema fundamental

que dificulta la gestión de las mismas: hoy por hoy, los fabricantes no realizan drivers para

gestionar los trabajos enviados a sus impresoras para el sistema operativo GNU/Linux.

Este problema tiene dos consecuencias fundamentales: 1) no es posible generar los traba-

jos de impresión en el formato genuino de las impresoras, y 2) no hay drivers de control de

impresora que permitan realizar la contabilidad de los gastos de cada trabajo impreso (papel,

tóner/tinta, número de hojas, etc). Aunque hay varios proyectos que pretenden realizar estas

tareas, normalmente el resultado es peor de lo que cabría esperar, siendo ésto especialmente

cierto para las impresoras que soportan formatos obsoletos (tales como el formato PostScript de

nivel 2 en lugar del más potente y moderno, de nivel 3).

Tampoco desde GNU/Linux se gestionan bien las fuentes de impresora o las fuentes True

Type del documento, lo que muchas veces da problemas de calidad en los trabajos. Además, al

no haber un sistema unificado de impresión en Linux, es cada aplicación la que se encarga de

generar su propio fichero PS, que después habrá que traducir al nativo de la impresora, lo que

aún crea más problemas.

Otro de los problemas de gestión, es el del control de las cuotas de impresión de los usuarios,

difícilmente solucionable vistos los problemas anteriores y que se viene a añadir a los problemas

típicos de este tipo de dispositivos: atascos, rellenado de papel y bloqueos de la impresora.

Dadas todas estas circunstancias, hay varias formas de acometer la problemática:

1. Realizar un control personal de la impresora y los trabajos que se envían. Esta opción es

la que mejor servicio proporciona al usuario, pero también la que más esfuerzo requiere.

2. Utilizar las herramientas disponibles para GNU/Linux y realizar un control laxo de las

impresoras. Es un ejemplo de este tipo la utilidadprintquota [59].

3. Utilizar sistemas soportados por el fabricante para la gestión de la impresora: en nuestro

caso, implicaría restringir a Windows los sistemas operativos que pueden hacer uso de la

impresora.

4. Utilizar sistemas mixtos que recojan los trabajos de impresión desde cualquier sistema

operativo y luego lo reprocesen (traduciéndolo al formato nativo de la impresora) dentro

4. Arquitectura 41

de un sistema soportado por el fabricante. Para hacer las pruebas de esta configuración,

hemos utilizado las siguientes aplicaciones: Samba (para recoger el trabajo del usuario

en formato PDF y guardarlo en un disco de red que a su vez controlaba el servidor de

impresión), Acrobat Distiller (para traducir de PDF a PS) y una aplicación de impresión

automática en Windows (para recoger el trabajo en formato PS e imprimirlo en el formato

nativo de la impresora). Aunque este sistema es el que ofrece más ventajas, también es el

más complicado de gestionar, por culpa de las pocas facilidades de gestión remota de los

sistemas Windows y la inestabilidad de los mismos.

Después de probar todas las opciones, y a pesar de todos los esfuerzos, la opción aplicada fi-

nalmente para la gestión de las impresoras del laboratorio fue la de realizar un control personal.

La motivación principal viene de que las impresoras de las que disponemos sólo tienen so-

porte para PostScript de nivel 2, con lo que las aplicaciones actuales que generan PostScript de

nivel 3 necesitan algún tipo de traducción, que no siempre es realizable correctamente con las

herramientas software estándar en GNU/Linux.

4.7.3. Gestión de sistema de nombres

En nuestro diseño, en lo relativo al DNS se ha contemplado la existencia de un servidor se-

cundario de dominio para gestionar las direcciones internas del laboratorio y permitir el acceso

al servicio de resolución de nombres sin necesitar acceder al exterior del mismo.

Tener un servidor de nombres dentro de la red del laboratorio es muy conveniente para

agilizar otros servicios, como el de proxy o el de correo electrónico. Este servidor de nombres,

se gestiona mediante la aplicaciónbind de ISC [47] que es uno de los más estables y potentes

entre los disponibles. Este servidor utiliza la misma máquina que hace de router y proxy del

laboratorio, dada su posición estratégica en la red.

Para minimizar el uso de este servicio a lo estrictamente necesario, también se distribuyen a

los clientes GNU/Linux ficheros con el direccionamiento interno del laboratorio (/etc/hosts).

4.7.4. Gestión de correo electrónico

El sistema de correo electrónico se ha dividido en dos partes. En una máquina, situada en

la red pública de acceso, se recibe y transmite el correo de o hacia el exterior y se gestiona el

correo de los profesores del laboratorio. En la otra, situada en la red privada del laboratorio,

se gestiona el correo de los alumnos y se les da servicio a través de protocolo IMAP, IMAPS,

POP3 y POP3S. Las listas de correo del laboratorio también están en este servidor.

La gestión del correo implica crear las listas de correo que agrupan usuarios del mismo

laboratorio de forma automática, así como crear las tablas de aliases de los servidores SMTP.

4. Arquitectura 42

Estas tareas son realizadas por un conjunto de scripts de distribución y gestión situados en el

directoriocuentas del usuario operador en el servidor central de administración.

Para facilitar la gestión del correo por parte del usuario, se le proporcionan dos servicios

extra, como son la posibilidad de reenviar todo el correo que reciba a algún servidor del exterior

(técnica llamada forwarding de correo) y filtrar el correo en función del asunto, contenido,

tamaño o remitente, entre otros.

4.7.5. Gestión de web

El web es el procedimiento principal a través del que se difunde la documentación de las

prácticas a realizar en el laboratorio. Ha de tener la máxima disponibilidad para posibilitar

que los alumnos tengan acceso a ella al mismo tiempo que realizan las pruebas de laboratorio,

sirviéndoles así de guía y de ayuda.

También se utiliza el servidor web para permitir al usuario cambiar su contraseña de acceso.

Este servidor web, específicamente configurado para ser sólo accesible desde el interior del

laboratorio, ejecuta un CGI (siglas de Common Gateway Interface, formato de archivo para la

ejecución de programas en los servidores web) que permite cambiar tanto la clave de acceso

para los clientes GNU/Linux, como la clave de acceso a los clientes Windows XP a través de

Samba. Los scripts implicados en esta tarea llevan por nombrepasswd.html y comprueba.cgi

y están preparados para facilitarles la nueva información a los scripts que se ocupan de las tareas

de gestión de usuarios.

4.7.6. Gestión de disco de red

Hay una máquina en el laboratorio expresamente configurada para dar servicio de disco

remoto a los clientes tanto de sistemas Windows como de Linux. Para los primeros tiene con-

figurado un servidor Samba, del que hemos hablado anteriormente. Para los segundos se utiliza

NFS. Ambos servidores son capaces de gestionar los permisos del usuario, impidiendo que unos

usuarios tengan acceso a la información de otros sin autorización, lo que garantiza el aislamien-

to seguro de las prácticas entre los alumnos.

Además, este servidor gestiona una cuota de disco para cada alumno, realizando un control

de las mismas de forma periódica y enviando un correo electrónico al usuario en caso de que

esté llegando al límite de uso. El programa que realiza esta tarea, también ha sido diseñado

expresamente y recibe el nombre deckquota.

También hemos decidido incluir en el sistema de cuotas el directorio en el que se almacena

el correo del usuario (/var/spool/mail) para así gestionar de forma conjunta el disco total uti-

lizado por cada alumno. Esto es particularmente crítico hoy en día, dada la tendencia expansiva

del correo electrónico no solicitado o abusivo (spam).

4. Arquitectura 43

4.7.7. Gestión de dispositivos especiales

Para ciertas prácticas de red, ha resultado necesario utilizar núcleos de GNU/Linux especí-

ficamente compilados para gestionar interfaces especiales de red. Dichos núcleos ofrecen las

mismas posibilidades de acceso al resto de los dispositivos pero, por ser menos estables que los

modernos, no se utilizan más que para las prácticas en las que el alumno lo requiere. También

hay componentes hardware que, por no estar soportados en Linux por el fabricante, hay que

instalar sus drivers en las máquinas Windows XP. Para permitir que el alumno gestione el hard-

ware y pueda realizar las prácticas docentes, hay que dotarle de mecanismos de autenticación

que le permitan hacer los cambios con privilegios de administrador. En GNU/Linux utilizamos

sudo [54], mientras que en Windows tienen que utilizar una cuenta de administrador local para

poder configurar el hardware.

4.7.8. Gestión de reserva de equipos

En un entorno compartido en el que conviven muchas asignaturas prácticas resulta ex-

tremadamente conveniente proporcionar al usuario un sistema de reserva de puestos que le

permita garantizar el acceso a un ordenador del laboratorio en una fecha y hora concretas y

durante un turno completo. Esto es particularmente importante en las ocasiones en que sólo se

puede realizar la práctica desde un ordenador concreto, siendo el caso de ciertas prácticas del

laboratorio de Redes y Servicios Telemáticos, en las que se ha de configurar el equipamiento

remoto que está únicamente conectado a éste a través de una red privada.

Este servicio ha sido desarrollado a partir de un proyecto [6] realizado en el marco de estos

laboratorios en Diciembre de 2000. Las mejoras introducidas han permitido gestionar las reser-

vas de forma sencilla a través del web. Mediante un sistema de autenticación local y un mapa

de los recursos del laboratorio se permite al propio alumno elegir el próximo turno en el que

realizará las prácticas, así como los equipos que utilizará para ello.

4.7.9. Gestión de actualizaciones

Las actualizaciones de los servidores GNU/Linux se basan en la instalación de los paquetes

de actualización medianteautoupdate [56], que es una aplicación de gestión automática de las

mismas. Estas actualizaciones se propagan a los clientes cuando se rehace la imagen del sistema

raíz (root.tgz) o cuando se utilizan las aplicaciones y librerías actualizados desde el servidor

a través de NFS.

Para la actualización de los clientes de Windows XP, hay que recurrir a la aplicación previa

de los parches disponibles en uno de los clientes antes de la generación de la imagen cruda con

partimage. Aunque se podría realizar la actualización automatizada con el sistema Windows

Update, esto sería poco eficiente y obligaría a realizar todas las actualizaciones cada vez que

4. Arquitectura 44

se regenerase el sistema y, lo que es peor, cambiaría el estatus estabilidad y repetibilidad que

hemos procurado para las máquinas del laboratorio.

4.7.10. Gestión de copias de seguridad. Plan de contingencia.

En cualquier sistema informático complejo en el que hay multitud de servidores y clientes,

cabe pensar en la necesidad de la creación de un plan de contingencia, es decir, en definir

una serie de procedimientos que permitan recuperar la información del sistema completo en

diferentes supuestos, a saber:

1. En caso de fallo de un equipo terminal o cliente.

2. En caso de fallo de un servidor secundario.

3. En caso de fallo del servidor principal.

4. En caso de pérdida de archivos individuales de usuario.

Tal y como se ha comentado anteriormente y se profundizará en el capítulo 5, el diseño del

sistema de administración centralizada tiene en cuenta la recuperación de todos los servidores

secundarios y los equipos cliente de forma automática, con lo que la problemática de los puntos

1 y 2 queda resuelta de forma muy sencilla mediante los procedimientos de reinstalación y/o

regeneración implementados.

También se ha contemplado la posibilidad de generar imágenes de reinstalación del servidor

principal tanto a disco óptico de arranque (herramientahazcd) como a fichero (herramienta

mkmaestro). A partir de estas imágenes, se puede recuperar el sistema de gestión centralizada

con todas sus aplicaciones y datos en pocos minutos. Sin embargo, aunque puede ser muy

práctico para generar nuevos dominios de administración (otros laboratorios o redes con gestión

independiente), mantener estas imágenes actualizadas en todo momento suele resultar poco

viable.

En caso de pérdida de datos, para resolver el problema de la gestión de los datos de usuario,

así como para permitir la regeneración del sistema principal completo, es fundamental integrar

en el sistema de administración centralizada una buena planificación de backupsc.

En el sistema, se han contemplado dos métodos de backup. El primero de ellos consiste

en guardar en cintas de backup todos los datos de cada sistema (hay varios tipos de cintas de

backup, siendo la tecnología DAT una de las más baratas y extendidas). A este tipo de backup se

le denomina de nivel 0, indicando que es de tipo general y guarda todos los datos que haya en el

sistema de ficheros en cuestión. Para realizar este tipo de salvaguardas, utilizamos un dispositivo

específico que es capaz de utilizar 6 cintas DAT de forma secuencial, permitiendo enlazar el

cbackup: palabra inglesa que se utiliza en informática para referirse a la salvaguarda de datos

4. Arquitectura 45

backup y pasar de una de ellas a la otra. La capacidad de las cintas es variable, dependiendo

de la densidad de la cinta empleada, pero resulta recomendable utilizar dispositivos capaces de

almacenar al menos 12GB sin comprimir.

El segundo de los métodos consiste en realizar comprobación periódica de los datos (archivos,

carpetas, etc) que han cambiado en el sistema de ficheros durante ese período y almacenarlos

en un disco duro de una máquina remota. A esta técnica le hemos llamado realización de back-

ups incrementales a disco. Este tipo de backups son de lo más versátil y útil, ya que unen la

sencillez y rapidez de la copia de datos a través de la red con la comodidad de tener los datos

almacenados en un dispositivo de acceso aleatorio, como el disco duro (en comparación con la

utilización de un dispositivo de acceso secuencial, como viene a ser una cinta de backup).

La planificación del sistema de backup es una de las tareas más importantes, dado que debe

haber siempre una forma de regenerar los datos del día anterior a la pérdida. Para ello, ambos

tipos de backup, los completos y los incrementales, habrán de ser combinados adecuadamente

para realizar sus tareas de forma coordinada. Dependiendo de la cantidad de cintas que quer-

amos utilizar y de la cantidad de disco duro para backups de que dispongamos podremos tener

más o menos días de salvaguarda.

Los programas utilizados para realizar los backups completos en el laboratorio ha sidodump,

mientras que para la realización de los incrementales utilizamostar. Los ordenadores más

críticos para la realización de backups, son aquellos en los que hay usuarios o datos de usuario,

dado que la información de las máquinas donde no los hay suele ser menos sensible a pérdidas.

Por ejemplo, este es el caso de las máquinas de cuentas (donde se guardan los datos de los

alumnos y de las cuentas de prueba de los profesores) y de web (donde se guardan los datos de

las cuentas de los profesores y la información consultada por los alumnos para la realización de

las prácticas).

4.7.11. Gestión de las caídas de tensión

Cuando se produce una caída de tensión eléctrica en un ordenador que estaba accediendo

al disco para grabar datos, se produce una situación de la que puede resultar una pérdida de

los datos que se pretendían grabar, inconsistencia de los mismos en el sistema de ficheros y

otros problemas relacionados. Por ello es fundamental dotar a los servidores principales de este

sistema de algún tipo de mecanismo que les proteja de este tipo de caídas, de los picos de tensión

y de otras fluctuaciones indeseables en el suministro eléctrico.

Este equipo es lo que llamamos un SAI (sistema de alimentación ininterrumpida). Normal-

mente tiene un puerto serie de control, a través del cual se le pueden enviar comandos o recibir

información sobre el estado de las baterías, la carga del sistema y otros datos. Pues bien, este

puerto de control ha de estar conectado a un servidor capaz de enviar al resto una orden de

apagado o de cancelar dicha orden, en caso de caída del fluido eléctrico o de su vuelta a la

4. Arquitectura 46

normalidad. Este tipo de sistemas permiten mantener la tensión eléctrica durante unos cuantos

minutos, tiempo suficiente para que los servidores guarden sus datos correctamente a disco y se

apaguen.

4.7.12. Gestión de estadísticas

Es fundamental para comprobar y planificar el uso de los recursos del laboratorio. Para sacar

las estadísticas se usan los registros de acceso tanto de los clientes Windows XP como de los

clientes GNU/Linux. En el caso de los clientes Linux, se les configura para enviar a su servidor

de arranque los logs (registros) de acceso. Las estadísticas, una vez agrupadas y reformateadas

(para adecuarse al formato necesario) se procesan conanalog, un programa especializado en

contabilizar los accesos a servidores web, que se puede adaptar para realizar la tarea.

Mediante este método, se extraen las siguientes estadísticas:

Porcentaje de ocupación en el período

Valores max/min/avg de logines y usuarios en el período

Relación usuarios/turnos en el período

Relación logins/usuarios/turno en el período especificado

Número de usuarios y puestos ocupados durante el período

Usuarios que más utilizan el laboratorio

Turnos más utilizados

Puestos más utilizados

Método de login más utilizado

Número de logins/usuarios en función de la asignatura

Número de logins/usuarios contabilizados

Número de entradas de root

Listado detallado de entradas de root

4. Arquitectura 47

4.7.13. Chequeo automático de servicios

Para comprobar el funcionamiento de los servicios de forma periódica es conveniente rea-

lizar una exploración y un análisis de sus características, su alcanzabilidad y su carga. De esto se

encarga un programa también desarrollado localmente llamadolab_servers_info, que me-

diante la herramientanmap [58] permite conectarse al puerto de cada servidor con el fin de ver si

responde. Es importante reseñar que lo único que se hace es comprobar la respuesta del servidor,

sin intercambiar ningún tipo de mensajes ni utilizar el protocolo en cuestión, por lo que la

comprobación no da la certeza absoluta al administrador de que el sistema esté funcionando co-

rrectamente. Para comprobar la carga del servidor, y la cantidad de disco utilizado y disponible,

se realiza un comando remoto conssh.

Según va recibiendo los resultados, el programa los analiza, estableciendo niveles de alar-

ma si un servicio no está disponible, si la carga es superior a un límite o si la cantidad libre

de disco duro no sobrepasa de lo establecido, por ejemplo. Finalmente, se envía un correo al

administrador indicando si han detectado o no problemas en el sistema.

Esta utilidad ha demostrado ser más útil que aquellas que utilizan los ficheros de registro

(logs) del sistema para comprobar lo que pueda estar sucediendo, debido a que hay muchos

problemas que no es posible detectar con este método y a que hay muchos tipos de error dife-

rentes como para gestionarlos todos. Otros problemas añadidos a ese tipo de aplicaciones sería

la posibilidad de cambio de los mensajes sin previo aviso y la falta de comprobación de la

funcionalidad real del sistema remoto.

Capítulo 5

Implementación

5.1. Infraestructura de comunicaciones

En este apartado se pretende ofrecer una visión general sobre las infraestructuras utilizadas

para la implementación real del laboratorio y de la configuración empleada para la distribución

de los servicios gestionados mediante este proyecto.

5.1.1. Nivel físico

Los laboratorios docentes del DIT tienen dos características diferenciales que le han condi-

cionado a la hora del despliegue de infraestructuras de nivel físico (entendiendo por éste, el

cableado de comunicaciones utilizado para la implementación de la red de datos). La primera

de ellas es que es un laboratorio multipropósito y multisistema, lo que implica que ha de dar

servicio a asignaturas muy diferentes y por tanto con necesidades diferentes. La segunda es

que el servicio se ha de proporcionar en múltiples aulas de la Escuela Superior de Ingenieros

Técnicos de Telecomunicación (ETSIT).

Figura 5.1: Vista del laboratorio A.127-2

48


Al darse diferentes necesidades en la actualidad y posiblemente también en el futuro, la

infraestructura de red ha de ser correctamente dimensionada ya que, por ejemplo, han de con-

vivir asignaturas que requieren una gran cantidad de recursos a nivel de red (como puede ser

el laboratorio de Redes y Servicios Telemáticos) con otras que requieren una gran cantidad de

recursos a nivel gráfico, de memoria, de potencia de cálculo, de ancho de banda o de compati-

bilidad (como podrían ser asignaturas de temática multimedia, de simulación, de bases de datos,

de programación avanzada, de sistemas inteligentes o de medidas de eficiencia de red, por citar

algunas).

Por todo esto y porque el coste de las infraestructuras a nivel físico no es despreciable con

respecto al resto de las inversiones, ha de tenerse en cuenta la capacidad de las mismas y las

posibles necesidades en un futuro próximo, a la hora de realizar el despliegue. En el caso de los

laboratorios del DIT, debido a la existencia de dos aulas diferentes, se ha decidido utilizar una

de ellas para las asignaturas con bajas necesidades a nivel de cableado (laboratorio A.127-2) y

la otra para aquellas que requieren altas inversiones en este campo (laboratorio B.123).

Figura 5.2: Vista del laboratorio B.123

Así, el aula B.123 dispone de todo el equipamiento necesario para realizar las asignaturas

prácticas que tienen grandes necesidades de infraestructura. Es capaz de funcionar indepen-

dientemente del otro laboratorio (el A.127-2) y todos sus ordenadores pueden utilizarse tanto

en Windows XP como en GNU/Linux, dependiendo de la asignatura y de la práctica que el

alumno pretenda realizar. Cada ordenador cliente tiene acceso al menos a 3 redes diferentes

mediante cableado estructurado, que en su totalidad es de alta capacidad de transmisión de datos

(categoría 6+ o Gigaspeed) pudiendo ofrecer servicios de hasta 1 Gbps. Este cableado se utiliza

específicamente en los laboratorios de redes, permitiendo realizar múltiples configuraciones en

todos los niveles de comunicación. En la figura 5.3 se muestra la estructura general de este

laboratorio.

Hay que mencionar también que debido a las características especiales de la instalación eléc-

trica de los diferentes edificios en los que se tienen aulas de laboratorio (por estar suministrados


Figura 5.3: Mapa de red del laboratorio de Redes y Servicios Telemáticos (curso 01-02)

por compañías eléctricas diferentes), es necesario interconectarlos mediante fibra óptica, tal y

como se indicará en la sección 5.1.2. Además, para el mantenimiento, gestión y rendimiento del

cableado es necesario realizar una buena administración del cableado horizontal, siguiendo una

norma estandarizada (en nuestro caso, la EIA-568-B) para la conectorización y distribución del

cableado, la utilización de patch panelsa y la asignación de ubicaciones específicas para estas

tareas. Para ello no sólo es imprescindible el conocimiento de la normativa y las caracterís-

ticas del cableado sino también el disponer de personal capacitado para realizar las tareas de

administración, configuración, pruebas y mantenimiento del mismo.

5.1.2. Nivel de enlace

El nivel de enlace se ha construido mediante el despliegue de una red Ethernet interconecta-

da mediante enlaces de gigabit-ethernet. Es muy conveniente utilizar como mínimo este ancho

de banda para asegurar que hay ancho de banda disponible suficiente como para satisfacer

las necesidades de comunicación de todos los servicios desplegados de forma simultánea. La

apatch panel: distribuidor intermedio que permite independizar el cableado vertical del horizontal


solución está basada en equipos conmutadores ethernet de alta velocidad de conmutación, con

múltiples velocidades por puerto, con puertos de interfaz física diferente (fibra óptica monomo-

do, fibra óptica multimodo y par trenzado no apantallado) y con capacidad de gestión de redes

virtuales de área local.

Estos conmutadores, están configurados de tal modo que todos los puertos de una misma

red IP comparten una misma red virtual de área local (o VLAN [48]) lo que significa que a nivel

de enlace usan un único dominio de broadcast. Además, todos los puertos de los conmutadores

son full-duplex, lo que implica que todos los ordenadores conectados a conmutadores tienen la

posibilidad de transmitir y recibir datos a la vez, por dos canales independientes y sin posibilidad

de colisiones. Esta característica nos permite hacer la red del laboratorio tan grande como sea

necesario y además dar un servicio ethernet de gran capacidad a los clientes.

Esta tecnología, además permite configurar un ordenador en varias VLAN (si son capaces

de utilizar el protocolo 802.1Q) realizando lo que se llama ”multihoming”, de tal forma que

podría hacer routing entre ellas sin necesidad de utilizar varias tarjetas de red. También es

posible cambiar un servidor de VLAN (incluso de forma automática) sin necesidad de tocar el

cableado, lo que aparte de ser mucho más cómodo resulta también mucho más fiable, puesto

que la manipulación física del conexionado suele ser la que más problemas provoca en este tipo

de entornos.

Figura 5.4: Mapa de Conmutadores Ethernet del Laboratorio


Como se ve en la figura 5.4 los servidores están directamente conectados al conmutador

central y situados en el Centro de Cálculo del DIT (CDC). Cada uno de ellos se conecta me-

diante enlaces de 100 Mbps full-duplex de par trenzado sin apantallar, aunque está planificado

aumentar el ancho de banda de algunos de los servidores a 1 Gbps en un futuro próximo para

aumentar el rendimiento (como puede ser en el caso del servidor de disco de red).

Figura 5.5: Imagen del rack de distribución de cableado y equipamiento en el aula A.127-2

5.1.3. Nivel de red

A nivel de red, el laboratorio está dividido en dos redes IP independientes, unidas entre sí

por un router/proxy y llamadas LABnet (la interna) y ADMnet (la externa). Además de estas dos

redes, que a nivel físico son Fast-Ethernet, también se han creado otras redes basadas en otras

tecnologías (Frame Relay, Ethernet, ATM o RDSI) que, con un direccionamiento IP privado

(192.168.0.0/16) permiten la realización de las prácticas de Redes y Servicios Telemáticos.

Como se puede observar en la figura 5.6, la red interna (LABnet) es la red del laboratorio

donde están situados:

La máquinacuentas(servidor de disco, de impresoras, gestor de cuotas y servidor prin-

cipal de correo electrónico),

Los múltiplesbinarios (o servidores secundarios que gestionan el arranque, exportan

los ficheros de aplicación que los clientes necesitan y compiten entre sí para ofrecer sus

servicios). En la imagen se pueden ver binario0, binario1 y binario2.

Los servidores específicosde asignaturas del laboratorio, como orion, lubina, rape o

dorada que tienen software y/o hardware especialmente configurado.

Los clientesdel laboratorio que dan servicio a los alumnos y profesores para realizar las

prácticas. A través de ellos acceden al resto de los servicios. Para nombrar los distintos

clientes se ha elegido una nomenclatura sencilla, basada en utilizar la letra ”l” seguida del


Figura 5.6: Mapa general de la infraestructura de red del laboratorio

número de ordenador, que a su vez coincide con el último campo de la dirección IP que

se le asigna.

Las impresoras, que están distribuidas por cada aula del laboratorio y es en ellas donde

los alumnos pueden imprimir sus resultados y memorias.

El router permite la conectividad entre LABnet y ADMnet (hace forwarding de paquetes

IP) sin permitir que LABnet pueda llegar a Internet más que a través del servicio de proxy

web que tiene configurado (ya que intencionadamente no se han creado rutas estáticas ni

dinámicas que redirijan el tráfico hacia o desde LABnet por el router del laboratorio).

Otro servicio que proporciona el router es el de DNS, debido a su posición privilegiada

con acceso directo a las dos redes. También es proxy de DHCP para permitir que maestro

sea capaz de responder peticiones de DHCP de los servidores secundarios (ya que el

DHCP es un protocolo no encaminable).

En ADMnet se han situado los servidores públicos del laboratorio, que gestionan los ser-

vicios que el laboratorio ofrece a través de Internet, como son el web, el correo electrónico, el

DNS, etc. En la figura 5.6 se puede ver que en ella están:

El servidormaestro, servidor principal del sistema de administración centralizada. Aunque

específicamente no ofrece ningún servicio público, está en la red externa porque ha de te-


Figura 5.7: Imagen del rack de servidores del laboratorio en el CDC

ner acceso a otros servidores del DIT a los que llega a través de la máquina firewall (y

para ello ha de tener ruta hacia Internet).

El servidor de web (www) que se encarga de albergar las cuentas de laboratorio de los

profesores, así como la información de las prácticas. También es el servidor secundario de

correo del laboratorio, y a través de él llega o sale todo el correo externo del laboratorio.

El firewall , que es la máquina encargada de filtrar aquellos protocolos y puertos a los que

no está permitido el acceso, restringiendo así los posibles problemas de seguridad que

puede provocar la conexión a Internet.

La máquinabesugo, que se utiliza para permitir la gestión remota de los servidores Win-

dows que hay en el interior del laboratorio (mediante las facilidades de Terminal Server).

El nivel de red es totalmente configurable desde los equipos de prácticas del laboratorio, bien

a través de consolas virtuales de equipos de comunicaciones, bien a través de la configuración

de sus propios clientes, por lo que es posible realizar prácticas de configuración de redes tan

grandes y complejas como las que los alumnos se encontrarían en un entorno real y utilizando

tecnologías como ATM, Frame Relay, Ethernet o RDSI. Véanse las figuras 5.3 y 5.8.

5.2. Sistema de administración centralizada

El sistema de administración centralizada ha de solventar los diversos problemas de gestión

que se han planteado y discutido en los anteriores capítulos. Aunque la solución para cada

uno de ellos puede ser diferente en muchos aspectos, este proyecto ha extrapolado las partes

comunes y pretende ofrecer un punto de vista integrador a partir del cual desarrollarse de forma


Figura 5.8: Rack de equipos de comunicaciones en el aula B.123

sostenible. Así, se ha hecho hincapié en la utilización de las facilidades de conectividad en red

de los equipos administrados y en gestionarlos con procedimientos automáticos y desatendidos

en la medida de lo posible.

En lo que queda de capítulo, se pretende ofrecer al administrador y al evaluador de este

sistema un punto de vista mucho más detallado de las vías de resolución adoptadas, para que sea

posible, no sólo compararlo con otros sistemas similares, sino también para que sea más sencilla

la adaptación al mismo de nuevos los usuarios o administradores y para facilitar la integración

de este proyecto con otros futuros que puedan ampliarlo, modificarlo o simplemente utilizarlo.

5.2.1. La jerarquía de servidores

Como se ha comentado anteriormente (sección 4.6), el sistema de administración centra-

lizada está dividido jerárquicamente en tres niveles, siendo el nivel superior (servidor principal

o maestro) el que implementa el sistema de administración centralizada propiamente dicho,

delegando las subtareas básicas al nivel inmediatamente inferior (servidores secundarios). En

el último nivel jerárquico están los clientes de laboratorio que son el punto de acceso a los

servicios del laboratorio y donde el usuario final accede y se autentica.

5.2.1.1. Servidor principal

El servidor principal del sistema de administración centralizada del laboratorio (maestro)

tiene la función primordial de ser el gestor del resto de los servidores del laboratorio, que se


Figura 5.9: Esquema de la distribución jerárquica servicios para las instalaciones

instalan a partir de las configuraciones y servicios que él proporciona. También es el ordenador

donde el operador y el administrador realizan sus tareas de configuración y administración, no

dando servicio a ningún otro usuario del laboratorio de forma directa.

Los servidores que se ejecutan en maestro son:

DHCP (para configurar las tarjetas de red de los servidores que administra)

TFTP (para enviarles los menús y archivos de arranque)

NFS (para exportar los archivos de instalación de GNU/Linux)

NETBEUI (para exportar los archivos de instalación a los servidores Windows XP)

HTTPS (para gestionar el cambio de claves de los usuarios)

Las tareas que se realizan en maestro son a dos niveles: tareas de administrador y tareas de

operador. Las de administrador son aquellas que se utilizan para gestionar la instalación de otros

servidores y clientes, y son llevadas a cabo por personal muy especializado, mientras que las de

operador son aquellas que permiten realizar procesos de mantenimiento y configuración básicos

-como puede ser crear nuevas cuentas de usuarios, comprobar la utilización de los sistemas y el

reparto de carga, etc- y pueden ser realizadas por personal mucho menos especializado.

5.2.1.2. Servidores secundarios

Los servidores secundarios de arranque (también llamados binarios) están integrados en el

sistema de administración centralizada y hacen uso de las facilidades creadas para la instalación,


gestión y actualización de servidores GNU/Linux. Estos servidores tienen como tarea principal

permitir el arranque y la configuración de los clientes del laboratorio que hacen uso de sus

diferentes servicios:

Servicio de DHCP (para la configuración remota de las tarjetas de red de los clientes)

Servicio de TFTP (complementario al de DHCP y destinado a la transmisión de las imá-

genes en período de arranque de los clientes)

Servicio de NFS (mediante el que se exportan a los clientes no sólo las bases de datos de

acceso, las configuraciones, las aplicaciones y las librerías, sino también las imágenes de

reinstalación de GNU/Linux y de regeneración de Windows XP).

Servicio de Registro Remoto (mediante el que se importan de los clientes los registros de

entrada y de salida a los mismos, así como de los posibles problemas que surjan en ellos).

Estos servidores están específicamente pensados para dar servicio a los clientes GNU/Linux

del laboratorio, pero también permiten la regeneración de Windows XP ya que este proceso

se realiza mediante el uso de una imagen de GNU/Linux específicamente configurada para la

realización de esta tarea.

Tanto los binarios como el resto de los servidores secundarios son máquinas que el admi-

nistrador no ha de gestionar manualmente, puesto que esa labor la realiza el sistema de admin-

istración centralizada implementado. Así, por ejemplo mediante éste se programa el servicio de

cron para realizar las actualizaciones automáticamente o para reiniciar el sistema de forma pe-

riódica. También está programado el rotado de los ficheros de registro para evitar una utilización

excesiva del disco duro.

Mientras que las necesidades de los servidores secundarios multipropósito dependen del

servicio o servicios que proporcionen a la red, los requisitos de los ordenadores que se quieran

utilizar como binarios se pueden concretar en los siguientes:

Gran cantidad de memoria RAM, para no tener que realizar consultas al disco duro con

demasiada frecuencia

Buena conexión de red. El full-duplex y un ancho de banda igual o superior a 100 Mbps

son imprescindibles.

Procesador suficientemente rápido, ya que esto agiliza mucho la gestión de disco y la

transmisión de archivos en la arquitectura PC.

Discos duros de gran ancho de banda, con memoria caché (cuanta más, mejor) y de bajo

tiempo medio de acceso.


Fuentes de alimentación de gran calidad, para permitir un rendimiento más estable del

servidor ya que gran parte de los problemas de los PC tienen una componente hardware

derivada de las características de la fuente de alimentación (fallos de ventilación, espúreos

de tensión, caídas del sistema, etc).

5.2.1.3. Clientes

Son los ordenadores finales del laboratorio y por tanto los que dan servicio de forma di-

recta al usuario. En los laboratorios del DIT tienen dos posibles tipos de sistema operativo:

GNU/Linux y Windows XP Pro. La elección del sistema operativo se realiza a través de un

menú que se muestra al iniciarse el sistema. En él se le permite al usuario elegir entre:

Cargar GNU/Linux

Cargar XP

Regenerar XP

Dado que, en la mayoría de las asignaturas, el sistema operativo de trabajo es GNU/Linux, está

programado un temporizador de un minuto que, al llegar a cero, inicia la carga de GNU/Linux.

En el caso de la carga Linux, se hace la reinstalación cada vez que el usuario quiere utilizar-

lo, debido a que el proceso completo tarda muy poco tiempo y a que los sistemas de ficheros

utilizados (ext2) son muy sensibles al apagado brusco del ordenador. Por esta razón, los sistemas

de ficheros utilizados en Linux se formatean cada vez que se reinstala, con lo que conseguimos

un proceso de instalación muy estable. Esto nos da una ventaja añadida: tal y como está con-

cebido el sistema, no pasa nada si el ordenador se apaga sin sincronizar los discos (sin guardar

los datos que puedan estar en el caché), cosa que ocurre por ejemplo, cuando se corta de forma

súbita el suministro eléctrico del aula.

La regeneración de Windows XP no se puede realizar cada vez, ya que implica demasiado

tiempo de espera (en relación con el tiempo de un turno de trabajo, que es de dos horas), así

que hemos dejado que sea el propio usuario quien decida si necesita o no regenerar el Windows

XP del ordenador que está utilizando. Esta técnica suele ser bastante adecuada, debido a que no

sólo permite ahorrar tiempo, sino también recursos de red. En el caso de un apagado brusco del

sistema, el XP es bastante más sensible que Linux y puede obligar al usuario a la regeneración.

Sea cual sea el sistema operativo utilizado por el cliente, se utiliza un sistema de disco a

través de red para almacenar sus archivos (en Linux se usa NFS, mientras que en Windows

se usa NETBEUI). Esto asegura la integridad de la información del usuario del laboratorio

casi en cualquier circunstancia, ya que el ordenador de acceso no se utiliza más que como

mera herramienta de trabajo y para almacenar datos temporales. Como se ha mencionado con

anterioridad, el correo también reside en un servidor remoto, así como los perfiles de usuario.


Esto permite que la configuración de escritorio (o entorno de trabajo personal) de cada usuario

sea siempre la misma, independientemente del cliente en el que esté trabajando.

5.2.2. Sistema de instalación automática de servidores GNU/Linux

El sistema de administración centralizada consiste en un conjunto de utilidades que ges-

tionan la información de configuración almacenada en una base de datos. El sistema se puede

operar desde la línea de comandos, estando previamente registrado en el sistema como admin-

istrador o como operador (dado que ambos roles tienen funciones diferentes).

5.2.2.1. Modelos y patrones de estación

Aunque todas las estaciones de una red son diferentes entre sí en muchos aspectos (nombre,

dirección IP, dirección MAC, etc) también tienen entre ellas muchas cosas en común. Sobre

todo, cuando comparten el mismo sistema operativo, tienen el mismo hardware o realizan la

misma función. Para estos casos, la configuración de una estación es una instancia de un modelo.

Llamamos modelo a una lista ordenada de patrones, siendo los patrones un conjunto con-

creto de archivos y utilidades del sistema que están parametrizados con variables del sistema de

administración y que permiten configurar un servicio o una aplicación.

Así, por ejemplo, si una estación dispone de una tarjeta RDSI, se creará un patrón que

gestione su configuración a nivel de dispositivo, la instalación de las aplicaciones implicadas en

su funcionamiento y las configuraciones necesarias para éstas.

En cada patrón, se definen variables que permiten independizar la gestión de un servicio

de la máquina concreta a la que se aplica. Las variables de un patrón se introducen como

propiedades en la base de datos de configuraciones. Las estaciones que utilicen un modelo

que incluya un patrón determinado deben tener asignados valores concretos para esas variables

en la base de datos.

En la versión actual del sistema, los patrones son directorios, que reproducen a su vez la

estructura de directorios desde el raíz del sistema de ficheros de la estación que los utilizará. Es

decir, si en un patrón determinado, se quiere configurar un fichero que está debajo del directo-

rio etc (por ejemplo el/etc/resolv.conf), el directorio del patrón tendrá un subdirectorio

llamadoetc y, dentro, el fichero que se quiere configurar (resolv.conf).

search dit.upm.es lab.dit.upm.esnameserver 138.4.26.2

Figura 5.10: Ejemplo del fichero estándar/etc/resolv.conf

Este fichero podría estar almacenado en el patrón en formato final, es decir, tal y como sería


capaz de utilizarlo la estación que lo necesita, pero eso obligaría a tener un patrón por cada

estación que necesitase ese fichero con valores diferentes. Lo que le da valor añadido al sistema

de patrones es que en ese fichero, puede haber nombres de variables, que se sustituirán en el

proceso de configuración a partir de la información contenida en la base de datos.

Los patrones están pensados de tal forma que actúan como una transparencia sobre el sis-

tema de ficheros de la estación que los utiliza, permitiendo su superposición. De esta forma,

diferentes patrones pueden afectar a los mismos archivos de la estación a configurar, prevale-

ciendo los cambios que haya realizado el último de los patrones en aplicarse. Esta característica

permite realizar configuraciones complejas y muy versátiles, que pueden sacar el máximo par-

tido a la configuración de cada modelo de estación.

5.2.2.2. Transformación de patrones

Todas las estaciones de una red pueden clasificarse según su configuración. Esta caracterís-

tica es la que aprovecha el sistema de patrones, que permite catalogar en modelos de estación

las diferentes configuraciones de un modo extensible.

En resumen, los patrones son conjuntos de archivos parametrizados de un componente o

de una utilidad. La configuración que finalmente se instala en la estación es el resultado de

acumular todos los patrones del modelo elegido y sustituir los valores de las variables que

aparecen en los ficheros de configuración.

Así, para el caso anterior de la configuración del servicio de nombres de una estación par-

ticular a través del fichero/etc/resolv.conf, se podrían definir dos variables (o propiedades)

AC_NAMESERVER y AC_DNS_SEARCH que serían sustituidas por los valores almacenados en la

base de datos para esa estación en concreto (ver figura 5.11). Añadir el prefijoAC_ al nombre

de cada una de las variables, tiene como objetivo el diferenciarlas de otras posibles variables no

gestionadas con el sistema de Administración Centralizada.

search AC_DNS_SEARCHnameserver AC_NAMESERVER

Figura 5.11: Ejemplo de un fichero (/etc/resolv.conf ) pertenciente a un patrón

Cuando se construye la configuración de una estación determinada, se sustituyen las varia-

bles de cada fichero patrón por los valores definitivos para esa estación, según se indique en la

base de datos (ver figura 5.12). Para realizar esta operación de transformación, se han desarrolla-

do unos scripts basados en la utilidad m4 de GNU [16], disponible para todas las distribuciones

de GNU/Linux. m4 se invoca con dos parámetros principales: el archivo que contiene la defini-

ción de variables (que estará en la base de datos) y el archivo a transformar (que estará en


el directorio de patrones). El resultado es el archivo particularizado para una estación con los

valores de las variables sustituidos.

define(‘AC_DNS_SEARCH’,‘lab.dit.upm.es’)define(‘AC_NAMESERVER’,‘138.4.26.2’)

Figura 5.12:Fragmento del ficherobdm/net/admnet.m4 de la base de datos, que contiene la defini-ción de variables para DNS de una estación determinada

5.2.2.3. Organización de la base de datos

La base de datos está organizada en diversos ficheros de texto, cada uno de ellos con sus

definiciones de variables m4 (que también llamamos propiedades). A su vez, están distribuidos

en directorios, que los clasifican según el componente que definan, por debajo del directorio

bdm (acrónimo de ”base de datos de máquinas”).

Por ejemplo, si el componente es la tarjeta VGA, habrá diferentes ficheros con las defini-

ciones de variables para las diferentes tarjetas de ese tipo. Así, tendremos un ficheroati.m4

para las definiciones de variable correspondientes a la tarjeta de video ATI, y otro llama-

do s3.m4 para las definiciones de variable correspondientes a la tarjeta de vídeo S3. Ambos

archivos estarán bajo el subdirectoriovga del directoriobdm.

Figura 5.13: Esquema de directorios de la base de datos de máquinas (bdm)

El perfil de una máquina determinada, se genera a partir de los ficheros concretos de los

diferentes componentes que la forman (tarjeta vga, tarjeta de red, tarjeta de sonido, etc), me-

diante la inclusión de los archivos m4 correspondientes para cada uno. Por tanto, un perfil es un

conjunto de ficheros de definición de variables m4 agrupados mediante la técnica de inclusión,

en uno de mayor rango.


include(bdm/net/admnet.m4)include(bdm/vga/ati.m4)[...]

Figura 5.14: Ejemplo del perfil de una estación para la base de datos (bdm/nombremaq.m4 )

Los componentes de una estación no tienen porqué ser sólo definiciones de configuraciones

hardware, sino que también pueden consistir en la definición de las variables o propiedades del

software que se pretenda configurar en ella. Así, por ejemplo, se podría incluir en la definición

del perfil de una máquina el fichero de la base de datos que mostramos en la figura 5.12, que

quedaría tal y como se muestra en la figura 5.14.

Como cabe esperar, todos los componentes de un mismo tipo, han de definir las mismas

propiedades, aunque cada componente concreto pueda tener un valor distinto para cada una de

esas propiedades. Además, cada propiedad ha de tener el mismo nombre que la variable que

pretende sustituir en los patrones definidos, así, si hay una variable AC_NAMESERVER en

alguno de los ficheros de configuración de los patrones, debe existir una definición para esta

variable en alguno de los ficheros de componentes de la base de datos, y este fichero habrá de

ser incluido en el perfil de la máquina que lo pretende utilizar.

Por lo tanto, como resumen, podemos indicar que la base de datos de máquinas se basa en

tres conceptos diferentes: el de propiedad (como definición de una variable), el de componente

(como un conjunto de propiedades definidas de forma específica) y el de máquina o perfil de

máquina (como un conjunto de componentes integrados).

A diferencia de otros sistemas de administración, éste no establece ninguna propiedad por

defecto. El administrador define la lista de propiedades a medida que va genera los nuevos

patrones según sus necesidades. Por esta razón, el esfuerzo de despliegue de la red es mucho

mayor al principio que cuando la red ha crecido suficientemente.

La gestión de esta base de datos basada en ficheros, aunque ofrece una gran funcionalidad,

no es tan sencilla como sería conveniente, puesto que el administrador debe editar los ficheros

manualmente y puede cometer equivocaciones a la hora de nombrar o dar valores a variables

y ficheros. Por eso, están en desarrollo un interfaz gráfico y una base de datos relacional que

ayudarán al administrador a crear propiedades, componentes y perfiles nuevos y a modificar los

ya existentes.

5.2.2.4. Procedimiento de instalación desatendida

La herramienta del sistema de administración centralizada que generará elks.cfg en fun-

ción del perfil de cada máquina se llamamkdist. A mkdist se le pasa como parámetro el

nombre del perfil de la máquina (nombremaq.m4) con el que se genera el archivo de instalación


Figura 5.15: Esquema general de directorios del sistema de instalación para RedHat 7.3

desatendida (ks.cfg) y un fichero que incluye todas las propiedades de la máquina concreta

que se definieron en la base de datos. Este archivo que llevará el mismo nombre que el perfil,

se guardará localmente bajo el directoriodistrib/redhat-7.3/maquinas/nombremaq y se

transmitirá a la máquina para que, en un proceso posterior de configuración (autoactualiza),

disponga localmente de los valores de todas sus variables AC.

Tal y como se explicó en la sección 4.6.1, los servidores a instalar deberán estar configura-

dos para el arranque por red. Las configuraciones particulares para cada servicio implicado se

generarán también de forma automática a partir de la herramienta de gestión de DHCP y DNS

que forma parte del sistema central del DIT (install.hosts), para más detalles véase también

el punto 6.3.9.

En la fase de postinstalación del sistema operativo, se configura la estación para que en

su primer arranque ejecute la herramientaautoactualiza. Esta aplicación permite realizar

cambios genéricos de los archivos instalados localmente, según lo especificado en los patrones

del sistema de administración centralizada (previa transformación de los mismos en base al

perfil de la máquina concreta). Además, ejecuta procedimientos que, entre otras cosas, permiten

la instalación de paquetes no estándar y pueden programar a través delcron diversas tareas de

carácter periódico (como puede ser la actualización de los paquetes instalados, ejecución de

backups, rearranque, chequeo de cuotas, etc).

Como se puede intuir por la cantidad de cosas mencionadas, la herramientaautoactualiza

es la que más valor añadido proporciona al sistema de administración centralizada, ya que está

diseñada para permitir la gestión automática de cualquier parte del software del sistema admin-

istrado.

Este proceso en conjunto, aunque quizá resulte muy complejo de comprender, es sin embar-


Figura 5.16:Esquema del procedimiento de instalación desatendida para servidores GNU/Linux en suprimera fase

Figura 5.17:Esquema del procedimiento de instalación desatendida para servidores GNU/Linux en sufase final


go muy rápido, permitiendo instalar y configurar un servidor completo en muy pocos minutos.

5.2.3. Sistema de instalación automática de clientes GNU/Linux

En nuestro caso, el ficheroroot.tgz está generado contar y comprimido congzip. Para

gestionar este tipo de imágenes de forma automática, hemos creado un script llamadomkroot.

Una vez se ha creado el ficheroroot.tgz, hemos de distribuirlo a los servidores de arranque

de los clientes. Para realizar la tarea de distribución se ha configurado la herramientardist en

el directorioimagenes_rdist del servidor de administración.

El ficheroroot.tgz, base del sistema operativo local que se instala en el cliente, no contiene

todos los archivos necesarios para el sistema local. Esto es así para evitar que haya que transmitir

un archivoroot.tgz demasiado grande cada vez que se quiere instalar el ordenador. Podemos

decir que en el fichero mencionado se transmite únicamente la información básica, mientras

que el resto de la información, que será necesaria para el usuario, se comparte con el servidor

desde el que se realiza la instalación. En nuestro caso concreto, esta compartición se realiza

mediante protocolo NFS en modo de sólo lectura y da una ventaja añadida al sistema y es que

cuando se actualiza una aplicación que el cliente recibe por NFS, automáticamente el cliente

tiene disponible la versión actualizada.

Esta concepción de compartición de ficheros a través de la red la hemos utilizado no sólo

para los archivos de aplicación (normalmente debajo del directorio/usr), sino también para las

librerías dinámicas del sistema (/lib), y las aplicaciones generales y de administración (que

están en/bin y /sbin, respectivamente). Incluso los archivos de configuración del sistema

gráfico o de los usuarios y grupos del sistema se comparten de esta manera, de tal forma que no

es necesario reiniciar la máquina o realizar ningún proceso específico para permitir que en un

cliente del laboratorio haya una nueva cuenta de alumno disponible.

Las tareas previas a la de descompresión del ficheroroot.tgz incluyen la gestión del disco

duro donde se expandirá y otras pequeñas tareas que habrán de ser realizadas sin necesidad de

disco duro (como configurar el interfaz de red, por ejemplo). El núcleo de Linux nos ofrece

la posibilidad de crear un disco virtual a partir de la memoria RAM del sistema. Este disco se

transmite a través de la red en tiempo de arranque y de forma consecutiva a la del núcleo. Una

vez recibido en la máquina cliente, se pasa control al núcleo que a su vez es capaz de expandir

la imagen recibida (de tipo especial) y cargarla en memoria como un disco. Hecho esto, busca

en ese disco especial un programa de inicio (linuxrc) y lo ejecuta. A partir de aquí, el cliente

comienza a gestionarse a sí mismo gracias a la inteligencia dotada a los scripts incluidos en esa

imagen. La característica del núcleo capaz de gestionar estos discos virtuales se llamainitrd y

hay amplia información sobre ella en todo tipo de foros de administración de Linux en Internet.

La herramienta creada por nosotros para gestionar este tipo de imágenes se llamamkimagen y

permite actualizar los módulos del kernel de una imagen determinada, cambiar sus archivos,


redimensionarla y gestionar sus scripts de arranque con bastante sencillez.

Para minimizar el uso de la red en tiempo de arranque, hemos diseñado un programa (rc.-

checkfile_hda4) que es capaz de gestionar una partición del disco como caché, comprobar

si existe el archivo necesario (en este caso elroot.tgz), descargándolo en caso contrario, y

asegurarse de que la copia descargada es correcta mediante la utilización de un algoritmo de

firma de ficheros (md5sum).

Desde el punto de vista del usuario, la opción que ha de elegir para reinstalar el cliente con

GNU/Linux es la de ”Instalación y Arranque de GNU/Linux”. Describimos a continuación los

pasos intermedios realizados en el ordenador cliente cuando se ejecuta esta opción:

Se arranca el sistema operativo GNU/Linux mediante un núcleo y una imagen de disco

virtual (cargable en la RAM del sistema) transmitidos a través de la red.

Se particiona el disco duro en cuatro partes: una para albergar el GNU/Linux, otra que

se usará para almacenar el Windows XP, una partición que se usará como fichero de

intercambio de paginación (swap) y otra que se usará como caché de ficheros. Este parti-

cionado ha de ser exactamente igual que el que se realiza cuando se ejecuta la opción de

regeneración de Windows XP.

Se formatean las particiones de Linux destinadas a almacenamiento de archivos en local.

Para ello se utilizamk2fs.

Se formatea y activa la partición de memoria virtual (Linux swap). Conmkswap y swapon.

Se instalan los archivos de GNU/Linux que se desean tener en local, el resto se monta

a través de NFS desde el servidor que se configure (en nuestro caso el que haya dado el

menú de arranque). Para ello se utilizan las aplicacionestar y gzip, además demount.

Se regenera el Master Boot Record (MBR) con un gestor de arranque de disco local

(LILO [42]) para poder arrancar Windows XP desde el disco duro local. Esta tarea se

debe realizar siempre que se reparticiona el disco duro.

Se pasa control al nuevo sistema de ficheros raíz, desmontando también el disco virtual

de instalación y recuperándose la memoria RAM utilizada en el mismo.

Se inicia el proceso de arranque local, lo que permite arrancar los servicios del ordenador

tal y como se hace en un sistema instalado normalmente.

El acceso a la configuración de dispositivos locales para realizar prácticas de red (o de

otro tipo) se gestiona a través de la configuración del programa sudo [54], que permite

dar permisos de ejecución especiales a usuarios concretos.


Figura 5.18: Esquema del proceso de reinstalación de clientes GNU/Linux

Para hacer uso del ordenador, el usuario introduce su identificador y clave. La gestión

de usuarios se realiza utilizando los ficheros que proporciona el servidor de arranque por

NFS. El disco local tiene una parte de acceso público (directorio/tmp) y otra de acceso

privado. Para uso personal, se utiliza disco en red (en este caso, también por NFS) en

el cual se gestionan los permisos de acceso mediante los identificadores de usuario y

grupo. Igual que en el caso de otros sistemas operativos, es necesario administrar los

identificadores y las claves de cada usuario y también la cantidad permitida de uso del

disco de red (cuotas). En nuestro caso, el sistema de administración centralizada se hace

cargo también de estas gestiones (que se mencionan en la sección 4.7.1).

5.2.4. Sistema de regeneración automática de clientes Windows XP

La regeneración de Windows XP, desde el punto de vista del usuario, se realiza en dos

subfases: regeneración cruda y autoconfiguración. Los pasos intermedios son los que pasamos

a describir a través de las opciones que se le ofrecen al usuario mediante el menú descargado

de la red:

Regeneración de Windows XP: Mediante esta opción se realiza la subfase de regeneración

cruda de Windows XP.

• Se arranca el sistema operativo GNU/Linux mediante un núcleo y una imagen de

disco virtual (cargable en la RAM del sistema) transmitidos a través de la red.


• Se particiona el disco duro en cuatro partes: una para albergar el GNU/Linux, otra

que se usará para almacenar el Windows XP, una partición que se usará como fichero

de intercambio de paginación (swap) y otra que se usará como cachéb de ficheros.

Este particionado ha de ser exactamente igual que el que se realiza cuando se ejecuta

la opción de arranque de Linux.

• Se formatea la partición caché si es que no está formateada y se copia en ella la ima-

gen del Windows XP que está accesible desde la red (por NFS [26]). Se comprueba

que la copia es correcta utilizando un sistema de firma basado en el algoritmo MD5.

• Mediante un clonador de particiones (partimage [38]) se regenera la partición

NTFS que utilizará Windows XP para sus datos a partir del caché de disco local

(si es correcta la imagen en él almacenada). Mediante esta clonación también se re-

cupera el formato del disco, por lo que no resulta necesario realizar la tarea aparte.

El script de gestión del caché se ha configurado de tal forma que en caso de que la

imagen almacenada en el mismo no fuese correcta, se usará directamente la imagen

desde la red (esto permite regenerar la partición aunque se hayan producido errores

de disco en la partición y no la tengamos almacenada localmente).

• Se regenera el Master Boot Record (MBR) con un gestor de arranque de disco local

para poder arrancar Windows XP desde el disco duro. En nuestro caso, utilizamos

LILO [42] por su sencillez.

• Se modifica el fichero de configuración del Sysprep [24] (sysprep.inf) mediante

el montado de la partición NTFS en lectura/escritura, para cambiar los campos dife-

renciales de la nueva instalación (en concreto, el campo del nombre de máquina).

Para ello, el núcleo de Linux utilizado habrá de tener los drivers NTFS necesarios.

• Se reinicia el ordenador.

Arranque de Windows XP: En este caso, el gestor de arranque pasará control al disco

duro local, dado que este sistema operativo no puede arrancar de red. Se pueden dar dos

opciones:

• Que sea la primera vez que arranca el Windows XP después de una regeneración, ca-

so en el que la subfase a ejecutar será la de autoconfiguración (previamente prepara-

da a través del programasysprep durante la fase de creación de la imagen cruda).

Así, se realizará la gestión de la licencia, se creará el número identificador de equipo

(SID), se permitirá al sistema unirse al dominio y se iniciará la detección y configu-

ración de los dispositivos locales para que éstos estén disponibles para el usuario.

bcaché: lugar temporal de almacenamiento de datos de uso frecuente, con el fin de evitar malgastar tiempo oancho de banda


Figura 5.19: Esquema del proceso de regeneración de clientes Windows XP en su fase inicial

Terminado el proceso de autoconfiguración, se reiniciará automáticamente el sis-

tema. El proceso de reinicialización después de la autoconfiguración es inevitable

con este sistema operativo.

• Que ya se haya autoconfigurado el Windows XP (es decir, que no sea la primera

vez que arranca después de la regeneración). En este caso, el ordenador iniciará un

Windows XP desde el disco duro local y de forma totalmente independiente. Para

hacer uso del ordenador, el usuario introduce su identificador y clave, especificando

que el dominio al que se quiere unir es LABPDC.

En algunos entornos puede resultar conveniente que este sistema operativo esté con-

figurado para unirse a un dominio a través del cual gestionar los usuarios de forma

remota y también para permitirle la utilización de un disco de red. Tanto la gestión

del dominio como la del disco de red se realizan a través de un servidor GNU/Linux

que tiene debidamente configurado un servidor SAMBA [25] con SSL que permite

encriptar las conexiones de datos. Resulta necesario destacar que la interacción de

servidores GNU/Linux y Windows XP a través del protocolo NETBEUI es una tarea

no exenta de dificultades [27].

Además de la configuración mencionada es necesario administrar los identificadores

y las claves de cada usuario y también la cantidad permitida de uso del disco de red

(cuotas). En nuestro caso, el sistema de administración centralizada ha de encargarse

también de estas gestiones (que se mencionarán en la sección 4.7.1).


Figura 5.20: Esquema del proceso de regeneración de clientes Windows XP en su fase final

Desde el punto de vista del administrador, y dadas las características específicas de este

sistema operativo, será necesario crear una imagen particular para la regeneración de cada uno

de los tipos de cliente. La creación de la imagen de regeneración de Windows XP se realiza con

el mismo programa que se utiliza para la regeneración:partimage. Los detalles de esta tarea

se facilitan en la sección 6.2.6, dentro de la especificación de las funciones del administrador.

5.2.5. Sistema de instalación automática de clientes y servidores Windows

XP

La instalación de Windows XP de forma automática y desatendida se basa en la confi-

guración de un disquete de arranque que permite al ordenador iniciar su dispositivo de inter-

conexión a la red. El proceso está dividido en varias fases. Primero, se realizará un arranque

de disquete y una configuración del dispositivo de red, hecho esto, se montará el servidor de

red correspondiente. Luego, se realizará el particionado y la configuración del disco duro lo-

cal a partir de ciertos archivos de red. Hasta aquí la fase MS-DOS. Más tarde se realiza una

instalación desatendida de Windows XP a través de la red (fase Windows), y para finalizar, se

instalan las aplicaciones extra para el sistema operativo (fase Aplicaciones).

5.2.5.1. Estado inicial

Para iniciar este proceso necesitaremos un ordenador que cumpla los requisitos mínimos

para la instalación de Windows XP, requisito trivial pero no fácil de satisfacer, debido a la


Figura 5.21: Esquema general de directorios del sistema de instalación para Windows XP

gran cantidad de recursos necesarios en el PC (mínimo 256MB de RAM e Intel Pentium III

CPU) para la utilización satisfactoria de este sistema operativo. Además, la BIOS habrá de estar

configurada para ser capaz de iniciar la estación desde los archivos contenidos en un disquete de

arranque (o en un CD-ROM en su defecto, creado con las utilidadesisolinux y memdisk [9]).

Por sencillez, el proceso que se relatará en esta sección está referido únicamente a la utilización

de un disquete.

Como es obvio, el ordenador que se pretenda instalar habrá de tener espacio suficiente en

el disco duro para albergar el nuevo sistema operativo y sus aplicaciones. Además, este espacio

habrá de estar disponible de forma contigua.

5.2.5.2. Fase MS-DOS

Esta fase consta a su vez de dos partes. La primera permite el particionado del disco local,

mientras que en la segunda se inicia la instalación de Windows XP.

Mediante un disquete MS-DOS con soporte de red (creado con las utilidades proporcionadas

por Bart Lagerweij desde su página web [60]) se arranca el cliente. En el proceso de arranque,

este disquete analizará sus dispositivos, identificará su tarjeta de red, cargará sus drivers, utili-

zará DHCP para averiguar su dirección IP y nombre (nombremaq) y después montará mediante

protocolo NETBEUI un directorio de una máquina remota (el servidor principal o uno de los

servidores secundarios).


En ella (a esta unidad la hemos llamadoz:), estarán ubicados los comandos necesarios

para realizar las tareas de preparación del disco local (nosotros hemos llamado a este archivo

nombremaq.bat) y los archivos necesarios para la instalación de Windows XP. También se

monta otra unidad de red (con permiso de escritura) para guardar archivos temporales (a esta

unidad la hemos llamadoy:).

Hecho esto, se busca en la unidadz: el archivo de comandosnombremaq.bat y con él se

particiona y formatea en FAT-32 el disco duro a través de la aplicación aefdisk [40]. Hay dos

opciones: o que todo el disco duro esté disponible o que sólo lo esté una parte de él (en una

partición). En cualquier caso, el archivonombremaq.bat habrá de estar correctamente configu-

rado para gestionar la parte implicada. Al finalizar, se crea en el disco temporal un archivo con

el nombre de la máquina que servirá para indicar que ya se ha realizado la configuración del

disco local. Después, se reinicia el ordenador.

La segunda subfase arranca también con el disquete MS-DOS que hemos utilizado antes.

Esta vez, el archivo de ejecución por lotes (autoexec.bat) que se inicia al arrancar no sólo

configura la red y monta las unidades remotas, sino que comprueba si existe el fichero temporal

que indicaría que ya se ha realizado la primera subfase y que hay que proceder a realizar la

segunda. Ésta consiste en borrar el archivo de estado, ejecutar el comando de instalación de

Windows XP desde la unidad de red y finalizar el proceso con un nuevo rearranque.

Para llevar a cabo la instalación de Windows XP desde la unidad de red de forma desa-

tendida, es necesario ejecutar el comando de instalación pasándole como parámetro el fichero

de configuraciónnombremaq.txt que previamente habremos preparado. Este archivo, que Mi-

crosoft en su documentación denominaunattend.txt, se puede crear con una utilidad llama-

da setupmgr que encontramos en el disco de instalación de Windows XP dentro del fichero

support\tools\deploy.cab.

En nuestro caso,nombremaq.txt se encarga de indicar a la aplicación de instalación las

respuestas a las preguntas de la instalación. Las indicaciones son, por ejemplo, que queremos

convertir el sistema de ficheros a NTFS (para que se puedan gestionar permisos de acceso a

los ficheros), cuál será el identificador y la clave del administrador del sistema, la licencia de

producto, etc. Además, en este fichero también se especifica el nombre del script que permitirá

realizar la instalación de aplicaciones una vez se haya realizado la instalación del sistema ope-

rativo (en lo que es realmente la postinstalación). En nuestro caso, hemos llamado a este último

scriptnombremaq.cmd.

En concreto, el comando de instalación que se ejecuta esz:\winxp\i386\winnt /s:z:\-

winxp\i386 /u:z:\WINXP\MAQUINAS\nombremaq\nombremaq.txt. Este comando, al eje-

cutarse, realiza la preinstalación del sistema para que el disco duro sea capaz de iniciar la ins-

talación propiamente dicha, objeto de la siguiente fase. Durante la preinstalación, se copia el

contenido del directoriowinxp\i386 de la unidadz: a la unidad de disco formateada ante-


Figura 5.22: Esquema del proceso de instalación de sistemas Windows XP

riormente mediante el comandoaefdisk y que tomará como nombre unidadc:. Después, se

configura el sistema para continuar la instalación desde disco duro y se reinicia de nuevo.

5.2.5.3. Fase Windows

Para iniciar esta fase hay que quitar el disquete de arranque (o el CDROM en su caso) y dejar

que el ordenador arranque de disco duro, ya que el proceso de preinstalación de Windows XP

habrá configurado el sistema para el arranque local. Después de convertir la partición a formato

NTFS, se inicia la instalación propiamente dicha, ya con el interfaz gráfico estándar.

Este proceso, al haberlo indicado así en el fichero de configuraciónnombremaq.txt, será

totalmente desatendido, y por tanto no será necesario que permanezcamos delante de la pantalla

de instalación. También será capaz de instalar los controladores de dispositivo que no estén in-

cluidos en la distribución siempre que se lo hayamos indicado así en el ficheronombremaq.txt

y realizará de forma automática la detección y la configuración del hardware, así como la insta-

lación de la licencia y de todos los archivos y configuraciones del sistema operativo.

5.2.5.4. Fase Aplicaciones

Tras la instalación del sistema operativo, el ordenador vuelve a reiniciarse, manteniendo

montadas las unidades de red utilizadas en la preinstalación. La siguiente tarea, si así se le

indicó previamente, será ejecutar el scriptnombremaq.cmd (que tiene su propia nomenclatura)

como usuario administrador. Este archivo lo utilizamos para dar de alta los usuarios locales,

modificar el registro con los parámetros convenientes e instalar las aplicaciones a partir de


sus correspondientes ficheros de instalación (que también estarán en la red y habrán de ser

instalables de forma desatendida).

Para disponer de más información sobre el proceso, detalles y recomendaciones se puede

consultar la documentación preparada por Pedro J. Pérez [62] y la de Karl Bernard [61]. Tam-

bién se puede encontrar información sobre la generación de instalaciones de aplicaciones au-

tomatizables para Windows en las páginas de Autoit [23] y WinstallLE [39] de Veritas, así como

en Microsoft [18] (formato msi).

Capítulo 6

Guía de Administración

6.1. Generación de la plataforma de administración

El primer trabajo que habrá de afrontar el administrador será la instalación del servidor

principal y la implantación en el mismo del sistema de administración centralizada. Esta tarea

se realizará en varias fases, que describiremos a continuación.

1. Instalación del sistema operativo del servidor principal o maestro. Para llevar a cabo es-

ta tarea, se puede realizar una instalación manual o utilizar cualquiera de los posibles

métodos de instalación automática. El servidor habrá de tener al menos las herramientas

estándar Unix (grep, sed, awk, make, mtools, entre otras) y los servidores DHCP, TFTP,

NFS, SAMBA y HTTP.

2. Creación de los usuarios de administración del sistema: operador y admin con UIDa 500

y 501, respectivamente.

3. A partir de la imagen creada con la utilidadmkmaestro (sadmc20030721.tar.gz), se

regeneran los directorios home de cada uno de los usuarios de administración (admin

y operador). De esta forma se recuperarán tanto las herramientas como la información

administrativa del proyecto (bases de datos, perfiles y otros archivos de configuración).

4. Creación de los repositorios de las distribuciones. En esta etapa, el administrador habrá

de recopilar los archivos de instalación de cada sistema operativo, dejándolos accesibles

en los lugares predefinidos en el sistema de administración. Para el caso de RedHat Linux

7.3 y Windows XP, los directorios serán:

/home/admin/distrib/redhat-7.3: en este directorio se copiará el contenido de los

CDs de instalación de la distribución de GNU/Linux, respetando los subdirectorios del

aUID: número identificador de usuario utilizado en los sistemas Unix

75


sistema de administración particularizados para esta distribución que existan por debajo

del mismo.

/home/admin/distrib/redhat-7.3/updates: aquí se deben almacenar los paquetes

de actualización de la distribución.

/home/admin/distrib/winxp: aquí se guardará el contenido de los directoriosdocs,

I386, support y valueadd del disco de instalación de Windows XP Professional.

/home/admin/distrib/winapps: aquí se almacenan las diferentes aplicaciones con sus

instaladores automáticos y sus archivos de instalación, cada una en su propio directorio.

Entre ellas puede estar el Office XP, por ejemplo, en el subdirectorioofficexp. A estos

directorios accederá el archivo de ejecución de la postinstalación,nombremaq.cmd.

5. Una vez finalizadas estas fases, habrá que configurar los distintos servidores de ficheros

utilizados en maestro (NFS, SAMBA y HTTP) para que sea posible instalar y gestionar

los diferentes servidores secundarios y, a través de éstos, los clientes. Las configura-

ciones de DHCP y las imágenes estándar exportables por TFTP están bajo el directorio

servicios del usuario operador (en los subdirectoriosdhcpd y tftpboot, respectiva-

mente).

A partir del momento en que se finaliza la instalación y configuración del servidor principal (o

maestro) se podrán realizar las tareas de administrador del sistema, descritas en el capítulo 5 y

en el resto de secciones de este capítulo.

Entre otras cosas, habrá que generar los perfiles de instalación de los servidores secundarios

GNU/Linux (nombremaq.m4) y los archivos de configuración correspondientes para la insta-

lación de estaciones Windows XP (nombremaq.{bat, txt, cmd}), así como las imágenes de

reinstalación de los clientes GNU/Linux (root.tgz) y de regeneración de los clientes Win-

dows XP (xp.gz.000). Para ello, el administrador habrá de familiarizarse con las herramientas

implementadas y con la estructura de directorios del sistema que deberá manejar.

6.2. Tareas frecuentes del administrador

6.2.1. Creación y modificación de los perfiles para los servidores binarios

Como explicamos anteriormente, consideramos perfil de una máquina, a un fichero que

contiene la localización de los ficheros m4 en los que residen las variables necesarias para

su instalación y postinstalación. Para crear o modificar un perfil nuevo, el administrador del

sistema debe asegurarse de que existen en la base de datos los componentes particulares para el

hardware y software de la máquina en cuestión. En caso de no existir, habrá que añadirlos a la

base de datos.


Cuando el perfil está preparado, lo único que resta hacer es ejecutarmkdist, pasándole como

único parámetro el nombre del perfil en cuestión. Este comando genera el fichero de texto que

permite la ejecución de la instalación desatendida con Kickstart (ks.cfg), coloca este fichero

en un lugar de red accesible para el instalador y crea una imagen de disquete por si la estación

no puede arrancar de red. También prepara algunos ficheros que serán usados durante la fase de

postinstalación para ajustar detalles del sistema.

6.2.2. Creación de nuevos perfiles hardware para los clientes GNU/Linux

Los clientes GNU/Linux del laboratorio, una vez que cambian el sistema de ficheros raíz al

disco duro, comienzan a arrancar como un ordenador normal con RedHat 7.3. Inicializan los

servicios que estén configurados para el runlevel de inicio (actualmente el 5: registro en consola

gráfica) a través de lo extraído delroot.tgz, y por último ejecutan el script de inicialización

local (contenido en el archivo/etc/rc.d/rc.local).

Tal y como está configurado el cliente, el archivorc.local es un enlace al archivo/usr/-

local/local/clients_conf-1.1/etc/rc.d/rc.local del servidor binario que le ha pro-

porcionado el arranque. Con él, se analiza el archivodispositivos (también accesible por

NFS), se extrae el perfil concreto del cliente y se configuran con él las aplicaciones dependien-

tes de los mismos: el gestor de ratón (gpm) y el servidor gráfico (XFree [63]).

Para ver cómo modificar el archivodispositivos, se puede consultar el apartado 6.3.10.

Para modificar el ficherorc.local, aunque es necesario tener conocimientos de programación

en shellb, se debe utilizar exactamente el mismo procedimiento de distribución.

Todos los clientes GNU/Linux utilizan el mismo servidor gráfico y el mismo fichero de con-

figuración (/etc/X11/XF86Config-4, que también se obtiene por NFS), aunque sus disposi-

tivos sean diferentes. La distinción se realiza al ejecutar elrc.local, especificándole al sistema

gráfico el perfil concreto para la máquina en cuestión. Para ello, hay que utilizar el parámetro

-layout seguido del nombre que agrupa la configuración concreta del cliente y guardar esa in-

formación en el archivo de configuración del sistema gráfico/etc/X11/xdm/Xservers, tarea

que también realiza el propiorc.local.

Por eso, cuando se modifica el archivo/usr/local/local/clients_conf-1.1/lib/-

X11/XF86Config-4 de maestro y se distribuyen los cambios a los binarios, no se actualiza

automáticamente la configuración de los clientes hasta que se reinician o se ejecuta localmente

en cada uno de ellos el scriptrc.local.

Cuando se desee añadir un nuevo tipo de cliente GNU/Linux, la modificación del fichero

de configuración del servidor gráfico habrá de hacerla un administrador del sistema teniendo en

cuenta las capacidades físicas del monitor y la configuración del resto de los dispositivos.

bshell: nombre que recibe el intérprete de comandos en los sistemas operativos tipo Unix


Figura 6.1: Esquema general del directorio de servicios del usuario operador

6.2.3. Creación y actualización de las imágenes de arranque para los

clientes GNU/Linux

Como se ha explicado en la sección 5.2.3, los clientes de Linux utilizan un disco virtual en

memoria RAM (initrd) para las tareas de inicialización de sus dispositivos y configuración

del disco duro local con el fin de instalar en él el sistema operativo GNU/Linux. Dado que en el

initrd se almacenan los módulos del núcleo (vmlinuz) relativos a la gestión del hardware, y

que éstos son diferentes cuando cambia la versión, elinitrd habrá de modificarse siempre que

se decida actualizar la versión del núcleo.

Para una gestión más sencilla delinitrd de los clientes del laboratorio, se ha creado el

programamkimagen. Este script, se ejecuta en el servidor de administración y a través de él se

puede desempaquetar y volver a empaquetar de forma automática el archivoinitrd especifi-

cado.

Las tareas más comunes de gestión de este disco virtual consisten en la realización de los

cambios necesarios para actualizar la versión de algún módulo devmlinuz o para modificar

la configuración del sistema durante el arranque (a través del script/linuxrc del ramdisk).

Explicaremos brevemente la forma de proceder para la realización de estos cambios.

1. Entrar al directorio de operador donde están los scripts de gestión del arranque de los

clientes Linux:

cd /home/operador/administracion/servicios/arranque_maquinas

NOTA: Por abreviar, en esta sección, indicaremos el acceso a este directorio refiriéndonos

únicamente aarranque_maquinas.


2. Ejecutar el script de configuración de imágenes, con las opciones de edición (-e) e insta-

lación (-i):

./mkimagen -i -e linux-ntfs

En este caso, como deseamos modificar la imagen de disco RAM de Linux que se carga en

los clientes GNU/Linux, utilizamos el parámetrolinux-ntfs. Con este parámetro se le

dice al programa que utilice la imagen que recibe como nombre completoinitrd.img--

linux-ntfs.

Al arrancar el programa, éste muestra una serie de mensajes indicando que está de-

sempaquetando la imagen y muestra el directorio en que la pone accesible (arranque-

_maquinas/mount_points/nueva). Asimismo, queda a la espera de una pulsación de

[ENTER] para volver a empaquetarla desde ese mismo directorio.

Para cambiar un módulo:

a) Desde otra consola de maestro, entrar en el directorio donde están los módulos

del núcleo:

cd arranque_maquinas/mount_points/nueva/lib/modules/current

b) Cambiar los módulos necesarios simplemente reescribiendo el módulo exis-

tente con el que deseamos utilizar. Si por ejemplo, el módulo en cuestión fuese

el de la tarjeta de red Intel Pro 100+, hacer:

cp /lib/modules/<version>/kernel/drivers/net/eepro100.o .

Para cambiar el script de inicio:

a) Desde otra consola de maestro, cambiar al directorio / del ramdisk:

cd arranque_maquinas/mount_points/nueva

b) Editar el archivo de gestión de inicio:

vi linuxrc

c) Guardar los cambios en el directorio de backups:

cp linuxrc arranque_maquinas/scripts/linuxrc.<fecha>

Para seguir una norma, especificamos la<fecha> empezando por las dos úl-

timas cifras del año, siguiendo por el número del mes y terminando con el

número del día dentro del mes. Ejemplo: el 16 de Abril de 2003 se indicaría

como 030416. Este formato tiene una pequeña ventaja y es que la ordenación

numérica de los archivos coincidiría con la ordenación temporal.

3. Cerrar la consola nueva o cambiar a cualquier directorio por encima del punto de montaje

de la imagen:

cd arranque_maquinas


Figura 6.2: Esquema detalle del subdirectorioarranque_maquinas

4. Pulsar [ENTER] (en la consola donde se lanzómkimagen) para que el programa finalice

con el empaquetado de la nueva imagen.

5. Distribuir los cambios a los binarios:

cd arranque_maquinas/tftpboot

make rdist

6. Probar la nueva imagen en los clientes arrancando la opción adecuada (en este caso,

GNU/Linux).

Para minimizar la cantidad de imágenes necesarias para las diferentes configuraciones lo-

cales, se ha decidido configurar los menús para que, a través del núcleo, pasen parámetros a las

imágenes de disco RAM utilizadas. Estos parámetros se extraen en el programalinuxrc que

toma control al cargarse el disco RAM y que, a su vez, hace uso de otros scripts que están en

disco RAM:

rc.fdisk.<DISCO>, que se encarga de realizar el particionado del disco en función de la

variableDISCO que se le pase al núcleo a través del menú. La utilización de esta variable

permite dar formato a discos de diferentes tamaños de forma automática sin cambiar el

programalinuxrc. Los valores que puede tomar la variableDISCO son:mucho, poco o

muypoco.

rc.checkfile_hda4, que se encarga de gestionar la partición hda4 como caché. A este

programa se le pasa como parámetro el archivo del servidor que se quiere utilizar (que se

recibe como parámetro del núcleo en la variableREGENERA) y él se encarga de configurar


la partición caché si es que no está accesible, de comprobar si el archivo está ya en el

caché, de ver si es correcto y descargarlo del servidor si no lo es. Al finalizar devuelve

el camino completo al archivo que el programalinuxrc habrá de utilizar. Los valores

que la variable REGENERA puede tomar en la actualidad son:root.tgz, xp.gz.000 y

xp.nec.gz.000.

rc.bootp, que se encarga de realizar una petición de BOOTP (compatible con DHCP),

obtener la respuesta del servidor y configurar el interfaz de red para acceder a la red local.

6.2.4. Creación y modificación de la imagen de reinstalación de los clientes

GNU/Linux

Los clientes GNU/Linux utilizan elroot.tgz para reconstruir su sistema de ficheros raíz.

La gestión de este archivo se realiza mediante el scriptmkroot que utilizatar para generar el

ficheroroot.tgz.

La técnica utilizada se basa en generar el archivo partiendo de los directorios de una máquina

con la distribución de Linux que queremos reproducir en el cliente y de una lista de archivos a

excluir de entre todos ellos.

Luego a este archivo se le añaden o sustituyen los archivos que queramos, utilizando los que

se almacenan en el directorioarranque_maquinas/client_root, que reproduce la jerarquía

de directorios de un cliente.

Al final, el archivo root.tgz se distribuye a todos los binarios (desde el directorioarranque-

_maquinas/imagenes_rdist) ejecutandomake rdist.

Para generar unroot.tgz correspondiente a otra distribución, solamente habría que con-

figurar algunos binarios con nueva distribución, generar a través de ellos una nueva imagen de

reinstalación (otro fichero como elroot.tgz pero con otro nombre), configurarlos para que

diesen arranque a los clientes a través del menú de arranque y configurar elrc.local. Evi-

dentemente, donde el administrador habría de emplear más tiempo sería en conocer la nueva

distribución para que se adecue a los requisitos del laboratorio, modificando la lista de ficheros

a excluir y los contenidos del directorioclient_root.

6.2.5. Modificación del sistema para instalar de servidores GNU/Linux

con otras distribuciones

Los pasos que debe seguir el administrador para soportar la instalación de una nueva dis-

tribución son:

1. Volcar todos los CD de instalación en el servidor principal de instalaciones. Para ello,


cada distribución trae un archivo LEEME o similar en el raíz del primer CD en el que

explican lo que hay que hacer.

En el caso de RedHat 7.3, los pasos aconsejados son (el siguiente proceso configurará el

directorio /target/directory en el servidor):

1) Introducir el disco 1

2) mount /mnt/cdrom

3) cp -a /mnt/cdrom/RedHat /target/directory

4) umount /mnt/cdrom

5) Sustituir el disco 1 por el disco 2

6) mount /mnt/cdrom

7) cp -a /mnt/cdrom/RedHat /target/directory

8) umount /mnt/cdrom

9) Sustituir el disco 2 por el disco 3

10)mount /mnt/cdrom

11)cp -a /mnt/cdrom/RedHat /target/directory

12)umount /mnt/cdrom

2. Añadir a la base de datos las variables correspondientes a esta nueva instalación. Estas

variables son, por ejemplo, directorios que contienen la nueva distribución, puntos de

montaje de los binarios que se van a instalar con esta nueva distribución, etc.

El administrador tendrá que asegurarse de que el instalador de la nueva distribución no

necesita parámetros que no estén contemplados. En caso de que sí los necesite, los deberá

añadir como variables a la base de datos.

3. El administrador también deberá cerciorarse de que los procedimientos (confs) que se

llevan a cabo en la postinstalación se pueden ejecutar en la nueva distribución. En caso

que no sea así, deberá adaptarlos para que se soporten todas las distribuciones.

4. Deberá comprobar también quemkdist genera un fichero que el instalador entiende (para

RedHat,ks.cfg; para SuSE, XML) y si no lo hace, modificarmkdist para que genere

un fichero adecuado para cada distribución.

5. Por ultimo, el administrador debe hacer que el menú de arranque de los servidores, tenga

la opción de iniciar la instalación de ambas distribuciones.

Tras realizar estos pasos, se podrán instalar por el mismo procedimiento las diferentes distribu-

ciones GNU/Linux (véase el punto 6.3.4).


6.2.6. Creación de imágenes para la regeneración de Windows XP

La herramienta utilizada para la creación de las imágenes de disco de Windows XP es

partimage [38]. Tiene interfaz de linea y también interfaz gráfico tipo menú, lo cual lo hace

sencillo de manejar tanto en las fases de creación como en las de regeneración.

Las tareas de creación se han de realizar en el siguiente orden:

1. Se reinstala un Windows XP en uno de los ordenadores cliente.

2. Se utiliza el comandosysprep para dejar el sistema operativo configurado de tal for-

ma que la próxima vez que arranque se realice una reconfiguración de la parte soft-

ware del sistema, permitiéndonos cambiarle el nombre al equipo, gestionar la licencia

o crear un nuevo número SID. Todo esto se hace a través de un archivo de texto llamado

sysprep.inf que contiene los parámetros básicos de la reconfiguración.

3. Se reinicia el ordenador, pero esta vez con GNU/Linux (si por error, arranca de nuevo

Windows XP, habría que reiniciar el proceso desde el punto 2). Se entra como root y

se monta la partición caché. Comopartimage necesita espacio libre en el directorio

/tmp (tanto para crear imágenes como para restaurarlas) puede ser conveniente montar la

partición caché en el directorio mencionado. Para ello, ejecutarmount /dev/hda4 /tmp

desde la línea de comandos.

4. Se ejecutapartimage para generar una imagen de la partición que contiene el Windows

XP. Mediante las opciones del interfaz se elige crear una imagen de la partición NTFS de

Windows XP. El resultado se habrá de guardar en el directorio en el que hemos montado

la partición caché (/tmp). El nombre temporal de la imagen puede ser el que queramos.

5. Se copia esta imagen al servidor maestro de administración centralizada, desde el cual

se distribuirá a los demás servidores de administración. El directorio desde el que se

distribuye esta imagen esmaestro:/home/operador/administracion/servicios/-

arranque_maquinas/imagenes_rdist/lib, y el nombre del fichero que usa para guar-

dar la partición de Windows XP esxp.gz.000 (para el caso de los clientes Dell y Compaq

del laboratorio) oxp.nec.gz.000 (para el caso de los clientes NEC), por lo que habrá

que conservar el mismo nombre si se quiere sustituir la imagen de regeneración.

6. Se distribuye la imagen creada para que se puedan regenerar las máquinas con ella. Para

ello, entrar en el directorio/home/operador/administracion/servicios/arranque-

_maquinas/imagenes_rdist/ y ejecutarmake all. Este proceso puede tardar un rato,

debido a que las imágenes son de más de 700 MB y tienen que distribuirse a todos los

binarios.


7. Se regenera un cliente Windows XP del tipo modificado y se comprueba que el fun-

cionamiento es correcto.

Para más información, se pueden consultar las tareas de regeneración de la imagen en el cliente

que han sido descritas previamente en el punto 5.2.4.

6.3. Tareas frecuentes del operador

6.3.1. Configuración de la BIOS de los clientes del laboratorio

Cuando se dispone a añadir una máquina cliente del laboratorio, lo primero que debe hacer

el operador es configurar la BIOS, llevando a cabo las siguientes tareas:

Configurar una clave de administrador (ojo, no de usuario) para que los alumnos no

puedan modificar los parámetros.

Hacer que la máquina sea capaz de arrancar de la tarjeta de red.

Asegurarse de que la primera opción en la secuencia de arranque sea precisamente la red.

En ocasiones será necesario entrar en el menú de configuración de la ROM de la tarjeta

para indicarle que debe hacer una petición por PXE.

Para tarjetas de red antiguas, será necesario grabar la memoria ROM (véase 6.3.2).

6.3.2. Grabación y actualización de las ROM de las tarjetas de red de los

clientes

Habitualmente el fabricante de la tarjeta de red proporcionará un modo de grabar la ROM.

El método más común es grabar a un disquete una imagen que contiene un ejecutable para

hacerlo. Procedimiento:

El operador configurará la BIOS para que arranque de disquete.

El operador arrancará con un disco de arranque de MS-DOS, meterá el disquete con

la imagen y ejecutará el exe (archivo ejecutable) que contenga el disco (normalmente

llamadoflash.exe).

El programa le guiará paso a paso con unas instrucciones sencillas. Lo más normal es que

sean los siguientes:

1. Salvar el contenido actual de la memoria FLASH a un fichero del disquete.


2. Grabar la ROM con la imagen contenida en el programa.

3. Reiniciar el PC.

El operador probará la detección de la ROM en fase de arranque y quitará el disquete

como medio de arranque de la BIOS.

En caso de que el fabricante no de una solución para la grabación de la ROM, es aconsejable

consultar la información disponible en proyectos como ROM-O-MATIC [64] a través de los que

se ofrece la posibilidad de generar y descargar una imagen para muchas tarjetas no soportadas.

6.3.3. Regeneración de Windows XP en los clientes del laboratorio

Si por algún motivo (generación de nuevas imágenes de regeneración, instalación de apli-

caciones, actualización o problemas con el sistema operativo) es necesario que se reinstalen los

Windows XP del laboratorio, lo único que el operador debe hacer es:

1. Arrancar el cliente y esperar a que aparezca el menú de arranque

2. Seleccionar la opción "Regenerar Windows XP"

3. Esperar mientras se regenera la partición del disco duro. Cuando la máquina reinicie, ha

de seleccionar ”Cargar Windows XP” del menú.

4. Esperar mientras se autoconfigura el Windows. Cuando la máquina reinicie, ha de volver

a seleccionar ”Cargar Windows XP” del menú.

5. Iniciar la sesión en Windows XP, seleccionando el dominio LABPDC e introduciendo

usuario y clave.

6.3.4. Instalación y postinstalación de servidores secundarios GNU/Linux

Instalación: La instalación de un servidor secundario del laboratorio consiste en:

1. El operador se asegurará de que la máquina que quiere instalar esta conectada a la

red LABnet y que arranca de la FLASH de la tarjeta de red.

2. Presionar el botón de encendido y esperar a que aparezca un menú.

3. Seleccionar la opción de ”Instalación automática de RedHat 7.3”.

4. Esperar a que se reinicie el ordenador. Cuando vuelva a arrancar, al expirar el tempo-

rizador de un minuto, se iniciará de forma automática la opción del menú ”Arrancar

de Disco Duro”.


5. Al ser el primer arranque, la máquina está configurada para realizar su postinsta-

lación mediante la aplicaciónautoactualiza. Esta aplicación configura los servi-

dores, programa las actualizaciones de paquetes e instala todo lo que por estar en

otros formatos no haya podido instalarse mediante el instalador del sistema operati-

vo. Pasados unos minutos la máquina estará operativa y dando servicio a los clientes

del laboratorio.

Postinstalación: La postinstalación de un servidor del laboratorio se puede realizar inde-

pendientemente de la instalación en cualquier momento posterior. Se puede ordenar desde

el servidor principal o desde el servidor secundario concreto que deseamos actualizar:

• Desde el servidor principal: Ejecutaractualiza -m perfil , dondeperfil es el

nombre del perfil del servidor que se quiere actualizar. Normalmente, el nombre del

perfil coincidirá con el del servidor administrado. Es posible aplicar la orden a todos

los binarios al mismo tiempo mediante el parámetro-binarios.

• Desde el servidor que se quiera actualizar: Ejecutarautoactualiza. Podemos indi-

carle al programa de postinstalación si queremos que utilice todos los patrones que

tiene el servidor preparados para esta máquina (opción-f), o nos vale con que use

sólo los que se hallan modificado en el servidor principal desde la última vez que se

actualizó la máquina (opción por defecto).

Esta aplicación permite mantener el mismo estado de configuración e instalación en todos

los servidores secundarios, ayudando así a conseguir la igualdad de condiciones entre

ellos.

6.3.5. Comprobación del funcionamiento del laboratorio

Periódicamente, el servidor principal del laboratorio efectúa un chequeo de todos los servi-

cios que tienen que estar funcionando en los servidores del laboratorio. Esto lo hace mediante

la ejecución de diferentes comandos denmap [58] y el posterior análisis de sus resultados.

Tras efectuar las comprobaciones necesarias, envía un correo al operador(es) informando de

la situación y, en caso de haber detectado algún fallo en el sistema, lo especifica en el correo

electrónico para así agilizar la resolución del problema.

El modo de efectuar todas las comprobaciones necesarias, es mediante la ejecución de un

script (lab_servers_info) a través delcron, que cada dos horas chequea puertos abiertos y es-

pacio libre en los discos, entre otras cosas. El programa está situado en el directorio de servicios

del usuario operador de la máquina maestro (maestro:/home/operador/administracion/-

servicios/lab_servers_info) y se puede ejecutar directamente cada vez que se quiera rea-


lizar esta tarea. Los resultados, se pueden observar en los ficheros de registro de actividad que se

dejan en el directorio, o consultando el correo electrónico una vez que ha terminado el proceso.

6.3.6. Comprobar los clientes asignados a cada binario

Cuando el operador considere necesario, podrá efectuar una comprobación de qué clientes

hay funcionando, a qué binarios están conectados, y qué sistema operativo están utilizando.

Esta comprobación es, por supuesto, en tiempo real y se muestra directamente en el terminal de

ejecución.

Disponer de esta información es necesario para hacer estadísticas de uso o en ocasiones

en las que se necesite reiniciar un binario, para asegurar que no se queda sin servicio ningún

cliente Linux del laboratorio. El programa se llamabinarios_info y está situado en el direc-

torio de servicios del usuario operador de la máquina maestro (maestro:/home/operador/-

administracion/servicios/binarios_info). Para obtener la información, sólo hay que

ejecutarlo desde el directorio indicado (./binarios_info) y será mostrada en la misma con-

sola del usuario.

6.3.7. Comprobar y gestionar la cola de las impresoras

Cuando el operador necesite comprobar las colas de impresoras desde el servidor maestro,

podrá hacer uso de las herramientas estándar que se usan en GNU/Linux, dirigiendo la acción

al servidor de impresoras (cuentas). Algunas de las operaciones que puede efectuar son:

Comprobar si las impresoras de red están encendidas y funcionando:

ping impresoraA

ping impresoraB

Comprobar el estado de todas las colas:

ssh cuentas lpq -a

Eliminar un trabajo de la cola de impresora:

ssh cuentas lprm -PlpA <idTrabajo>

ssh cuentas lprm -PlpB <idTrabajo>

Eliminar los trabajos de la cola de impresora de un usuario concreto:

ssh cuentas lprm -PlpA -U<idUsuario>

ssh cuentas lprm -PlpB -U<idUsuario>


Eliminar todos los trabajos de la cola de impresora:

ssh cuentas lprm -PlpA all

ssh cuentas lprm -PlpB all

Reiniciar el servidor de impresoras:

ssh cuentas /etc/init.d/lpd restart

6.3.8. Comprobar y gestionar la cola de correo electrónico

Del mismo modo que el operador gestiona las colas de las impresoras, también puede ges-

tionar la cola de correo electrónico. Algunas operaciones que puede efectuar son:

Comprobar el estado de las colas:

ssh cuentas mailq

ssh www mailq

En caso de que haya muchos mensajes en la cola, habrá que mirar los archivos de registro

implicados, en cada uno de los servidores:

ssh cuentas less /var/log/maillog

ssh www less /var/log/maillog

En caso de que haya habido un corte temporal en el servicio y se quieran reprocesar las

colas de correo electrónico en los servidores, ejecutar:

ssh cuentas /usr/sbin/sendmail -v -qR

ssh www /usr/sbin/sendmail -v -qR

Hecho ésto, el servidor comenzará a procesar de nuevo todos los mensajes almacenados

en la cola, mostrando el registro de la conexión o el error que se produce si ésta no se

puede establecer con el servidor remoto.

Para reiniciar los servidores de correo:

ssh cuentas /etc/init.d/sendmail restart

ssh www /etc/init.d/sendmail restart


6.3.9. Dar de alta nuevos clientes y servidores

Aunque no es parte del trabajo desarrollado por este proyecto, cabe mencionar, por ser una

tarea propia de los laboratorios, que se ha preparado un modo de gestionar el alta en red de

los clientes y servidores de forma que sea lo más sencillo y rápido posible. Tiene dos fases

principales, una en el servidor central de administración del DIT y la otra en el servidor central

de administración del laboratorio (maestro):

Primera fase (a realizar en la máquina central de administración del DIT):

1. Se registra el operador en la máquina central de administración del DIT y se introducen

con el debido formato todos los datos necesarios (dirección IP, nombre, grupo de contabi-

lidad y dirección MAC) de la máquina en un fichero de texto (/etc/tabla.numeros).

NOTA: Habrá que tener en cuenta las cabeceras#+ correspondientes a la configuración

de los sistemas DHCP y TFTP.

2. Se ejecuta el scriptinstall.hosts que procesa este fichero y extrae toda la información

necesaria para la configuración del DNS, DHCP y TFTP de los servidores del laboratorio.

También ejecuta de forma automática la segunda fase (no se requiere que el operador la

realice de forma manual).

Segunda fase (a realizar de forma automática en la máquina central de administración del

laboratorio):

1. Se copia en el directorio adecuado de maestro el nuevo archivo de configuración del

servicio DHCP del laboratorio (dhcpd.conf.admin).

2. Se accede a maestro, se entra en el directorio de configuración de DHCP, que está situado

bajo el directorio servicios del usuario operador (maestro:/home/operador/adminis-

tracion/servicios/arranque_maquinas/dhcpd) y se ejecutamake install. Esto

permite personalizar la configuración del servicio para cada uno de los binarios (en fun-

ción de lo especificado en elMakefile local).

3. Generada la configuración, sólo falta distribuirla a los servidores, para ello hay que eje-

cutarmake rdist desde el mismo directorio.

Después de este proceso, la máquina tendrá acceso al menú de arranque del laboratorio pero

aún no estará configurada para gestionar sus dispositivos en GNU/Linux de forma correcta. La

explicación para esta tarea está en el punto 6.3.10.


6.3.10. Modificar la configuración de dispositivos de un cliente GNU/Linux

Dado que no nos interesa que GNU/Linux detecte la configuración del hardware de forma

automática, hemos de tener en algún tipo de base de datos la información necesaria para con-

figurarlo en cada cliente. El sistema de administración guarda esta información en un fichero

de texto llamadoclients_conf-1.1/lib/dispositivos, que está situado bajo el subdirec-

torio usrlocallocal del directorio de servicios del usuario operador en la máquina maestro

(maestro:/home/operador/administracion/servicios/usrlocallocal).

Para realizar la configuración sólo habrá que cambiar o añadir el campo correspondiente del

fichero y reiniciar el cliente. Un ejemplo de la línea de descripción del equipo l001, contenida

endispositivos se puede ver en la siguiente tabla, donde se indican (en este orden) el nombre

de la máquina, la localización, el módulo utilizado para el ratón, el dispositivo del ratón, el tipo

de tarjeta de vídeo y el tipo de monitor.

l001 B-123 imps2 /dev/psaux nvidia necl002 B-123 imps2 /dev/psaux ati zenith[...]

Tabla 6.1:Ejemplo de la línea de descripción de los equipos l001 y l002 en el archivodispositivos

Este archivo se distribuye automáticamente y de forma periódica a los binarios a través del

cron del sistema principal, pero si resulta necesario distribuirlo en un momento concreto se

puede hacer mediante la ordenmake rdist en el mismo directorio.

En arranque, el cliente analiza la línea correspondiente a su nombre de máquina y elige la

configuración preestablecida para cada uno de sus dispositivos, esta tarea se realiza a través del

script/etc/rc.d/rc.local (véase el punto 6.2.2). El nombre de máquina, igual que el resto

de los parámetros de red, el cliente los aprende a través del DHCP.

6.3.11. Dar de alta nuevos usuarios

Se dispone de una aplicación específica para dar de alta o de baja usuarios, y efectuar algún

cambio sobre las cuentas de dichos usuarios. Esta aplicación eslabadmin. Su interfaz es a base

de menús y el control se realiza a través de los cursores y la tecla [ENTER].

Crear una cuenta nueva:

1. Ejecutarlabadmin en la linea de comandos, entrando como operador en maestro.

2. Seleccionar opción: Operar sobre una cuenta concreta

3. Seleccionar opción: Dar de alta una cuenta


4. Seleccionar un grupo del laboratorio al que pertenecerá el usuario (se listan todos

los grupos posibles).

5. Rellenar información sobre nombre, apellidos y DNI. El login (identificador del

usuario) es asignado de forma automática. La clave de acceso al sistema se genera a

partir de una combinación estándar de los datos del usuario.

6. Aceptar los datos

7. Seleccionar opción: Salir

Borrar una cuenta existente:

1. Ejecutarlabadmin en la linea de comandos, entrando como operador en maestro.

2. Seleccionar opción: Operar sobre una cuenta concreta

3. Seleccionar opción: Borrar una cuenta

4. Especificar el login de la cuenta que se va a eliminar

5. Confirmar el borrado

6. Seleccionar opción: Salir

Capítulo 7

Casos de Aplicación

7.1. Los laboratorios del DIT

El caso de los laboratorios docentes del DIT tiene unas características particulares que im-

pulsaron con mayor energía el desarrollo de este proyecto. Los puestos de laboratorio son or-

denadores tipo PC, algunos de los cuales tienen instalado hardware adicional, con el fin de que

sea posible la realización de prácticas especiales (normalmente de redes de datos y comunica-

ciones). En la tabla 7.1, se muestran las necesidades específicas de los laboratorios de grado y

postgrado de los últimos años.

Asignatura Sistema(s) Operativo(s) Necesidades Extra

Programación GNU/Linux Entorno de programación JavaProgramación de Sistemas GNU/Linux Entorno de programación JavaTécnicas de Programación GNU/Linux Entorno de programación CSistemas de Tiempo Real Específico Sistema de tiempo realSoftware de Comunicaciones GNU/Linux Entorno de programación Java

MulticastRedes y Servicios Telemáticos GNU/Linux Simulador NS, conexión a routers

MS Windows y otros sistemas de comunicaciónIngeniería del Software GNU/Linux Herramientas CASE y ofimáticas

MS WindowsSistemas Inteligentes GNU/Linux Entorno de programación Java

MS WindowsAdministración de Sistemas GNU/Linux Posibilidad de instalar S.O.

en la máquina clienteTransmisión Digital GNU/Linux Entorno de programación CConmutación de Circuitos GNU/Linux Simulador NS

MS Windows

Tabla 7.1: Necesidades específicas de los laboratorios de grado por asignatura

Además, los laboratorios docentes del DIT son utilizados también por otros grupos de alum-

92


nos de la ETSIT y cuyas necesidades se basan en el acceso a Internet y la utilización de los

programas ofimáticos disponibles:

1. Monitores de Laboratorio

2. Alumnos Erasmus y de otros Programas de Intercambio

3. Alumnos de Proyecto Fin de Carrera

4. Alumnos de Doctorado

Mediante la infraestructura implementada, se da servicio a más de 1500 alumnos anuales, que se

reparten entre los diferentes cursos de grado que se imparten en la ETSIT. Los laboratorios están

repartidos en dos aulas diferentes que también se ubican en edificios diferentes, manteniéndose

la posibilidad de ampliación a otras aulas de forma flexible. El horario del laboratorio reparte

su tiempo en turnos que se pueden reservar por el alumno desde una aplicación web, de tal

forma que cada turno es de un máximo de 2 horas y cada día consta de un mínimo de 5 turnos

por cada ordenador disponible. También es posible la utilización de un ordenador por varias

personas en un mismo turno de forma secuencial, o incluso de forma simultánea, dependiendo

de las características del sistema operativo instalado.

En la actualidad el laboratorio consta de 138 ordenadores de los que 137 están disponibles

para los alumnos, el otro se utiliza para el acceso de profesores y personal de administración.

Las estadísticas de acceso nos indican que en las fechas de máxima ocupación, se producen unas

700 entradas diarias al laboratorio (que también llamamos “logins”) repartidas en los 680 turnos

disponibles. Mensualmente, el número de logins viene a ser de unos 10000 aproximadamente

(datos recogidos entre Marzo y Abril de 2003).

Todos estos datos, además de abrumar un tanto, permiten acotar perfectamente el entorno

en el que nos movemos: aquel en el que el funcionamiento de los ordenadores, las redes y los

servicios se ponen a prueba cada día y en el que la falta de disponibilidad de los mismos afecta a

un gran número de personas. Como apunte, baste decir que el personal asignado para gestionar

estos laboratorios es de 7 personas en la actualidad repartidas en dos turnos (mañana y tarde),

lo que, comparado con el número de alumnos, e incluso con el número de ordenadores cliente,

resulta en una desproporción considerable. Más aún, si consideramos que también han de ges-

tionar los servidores, los servicios y las redes que interconectan unos y otros, cabe considerar

que de no haberse realizado el diseño e implantación de este sistema de administración centra-

lizada no habría sido posible dar servicio con una calidad razonable a la cantidad de usuarios

de los laboratorios del DIT.

La idea desarrollada pretende dar la máxima independencia al alumno que utiliza los puestos

de laboratorio del DIT. La única forma de hacerlo es asegurándonos de que, siempre que lo

necesite, podrá partir de un sistema conocido y estable, a partir del cual será capaz de realizar las


tareas encomendadas en las prácticas. Nosotros hemos implementado esta solución basándonos

en la regeneración o la instalación del puesto de laboratorio desde los servidores de arranque de

la red local del mismo, dándole prioridad al rendimiento y usabilidad del método.

Dada la aplicación del laboratorio a la docencia sobre redes y servicios telemáticos, se ha

creado una gran infraestructura hardware que implica la asignación a cada ordenador del labo-

ratorio de infraestructura para tres redes independientes por lo menos, mediante cable de par

trenzado. Esto genera un volumen de trabajo de instalación y mantenimiento nada despreciable.

El esquema arquitectónico permite jerarquizar las funciones que puede realizar el operador

(tareas rutinarias y de bajo coste) que llamamos tareas de frontend, mientras que por debajo

están las tareas de administración que son realizadas por administradores altamente cualificados

y son tareas de alto coste agrupables en el concepto backend.

En cuanto a los tiempos de regeneración de los puestos de laboratorio, las pruebas realizadas

demuestran que se puede instalar un cliente GNU/Linux en menos de 2 minutos, a partir del

segundo arranque del sistema (en el primer arranque se guardaría la imagen en la caché ubicada

en una de las particiones del disco duro). Para regenerar un cliente de Windows XP se puede

tardar alrededor de 5 minutos en la regeneración de la partición NTFS (si el archivo de la

imagen ya está almacenado en la caché local), tardando en torno a 10 minutos el proceso de

autoconfiguración posterior al reinicio.

La instalación de un servidor GNU/Linux de los que sirven como secundarios de arranque

(también llamados en este texto binarios) viene a tardar en torno a 10 minutos la instalación

del mismo, mientras que el proceso de reconfiguración posterior (autoactualiza) viene a tardar

otros 10 minutos, en función del tamaño de las imágenes que el servidor maestro le tenga que

distribuir.

La instalación de un servidor Windows XP estándar con el procedimiento de instalación por

red de Microsoft, viene a durar unos 40 minutos, mientras que el proceso posterior al reinicio

utilizado para instalarle las aplicaciones puede tardar unos 20 minutos más. Este proceso es el

más largo de todos, debido a que es básicamente lo que se tardaría en una instalación manual

si no fuese necesario que interviniese el administrador para responder a ninguna pregunta de

forma interactiva.

7.2. La red de producción del DIT

La red de producción del DIT da servicio a más de 170 usuarios estables (entre profesores,

personal de administración, doctorandos, becarios y colaboradores), aunque dentro del departa-

mento, se administran más de 370 cuentas de usuario. La red de producción se caracteriza por

ser de carácter estable y ofrecer a través de ella los servicios necesarios para la gestión de la

información tanto interna como externa. En ella, se utilizan más de 700 direcciones IPv4, sin


contar de los laboratorios docentes.

Si tenemos en cuenta que -como media- habrá un reparto de 0.75 ordenadores de uso per-

sonal por cuenta, habrá cerca de 280 ordenadores de tipo cliente en el departamento, que son

en su gran mayoría instalados, mantenidos, administrados y actualizados por cada uno de los

usuarios del departamento.

Muchas veces, debido a las necesidades particulares de cada usuario, este tipo de gestión

resulta lo más conveniente, pero está claro que implica una gran inversión de tiempo de cada

uno de ellos para la realización de tareas que no aportan valor a su trabajo, lo que convierte

claramente este tipo de tareas en candidatas a ser realizadas centralizadamente.

En este tipo de red, tradicionalmente las tareas de administración se han concentrado en dar

los llamados servicios comunes a los usuarios, como pueden ser:

gestión de impresoras compartidas,

gestión de servidores de correo,

compartición de recursos con otros usuarios,

gestión del acceso a Internet,

administración de servicios para la navegación en Internet,

recuperación de datos destruidos o borrados,

gestión del acceso inalámbrico a la red,

seguridad en el uso de Internet (virus, gusanos, troyanos, puertas traseras, ataques, dene-

gación de servicio...),

gestión de actualizaciones,

y, en general, todos aquellos susceptibles de dar un servicio de red. Estas tareas de adminis-

tración, por ser rutinarias y repetitivas en muchas ocasiones, se enfrentan con problemas que,

en la mayoría de los casos y dependiendo de su naturaleza, sería más fácil gestionar centra-

lizadamente. Como dato, baste decir, que en la red de producción del DIT se instalan, ges-

tionan, mantienen y actualizan más de 30 servidores de todo tipo, principalmente basados en

GNU/Linux, que se encargan de ofrecer esos servicios comunes a los que hacíamos mención.

Otro factor que nos impulsa a generalizar el uso de la administración centralizada es el

aumento vertiginoso del número de PCs (tanto portátiles como de oficina) en los últimos años,

consecuencia del abaratamiento de costes y del gran número de capacidades de que disponen. A

esto se ha unido el progresivo aumento en la utilización de sistemas operativos de tipo servidor,


lo que ha obligado a una mayor necesidad de conocimientos y de consejo en las tareas de

administración, ya que no están específicamente orientados al usuario ofimático.

Por todo ello, desde el año 2002, se están aplicando los conocimientos desarrollados a través

del sistema de gestión centralizada de los laboratorios docentes para instalar y administrar tam-

bién los de la red de producción, estando actualmente integrados en él más de 10 servidores

GNU/Linux. También se ha realizado ya la instalación de más de 10 ordenadores personales

con sistema operativo Windows XP de forma automática y desatendida, estando en fase de

depuración y perfeccionamiento para permitir al usuario realizar el proceso por sí mismo sin

intervención del Centro de Cálculo.

Capítulo 8

Conclusiones y Trabajos Futuros

8.1. Análisis del cumplimiento de objetivos

Analizaremos en esta sección el grado de cumplimiento de los objetivos planteados para

este proyecto.

Instalación y/o regeneración desatendida: Hemos descrito en este proyecto varias formas

diferentes de realizar la reinstalación de servidores y clientes, tanto GNU/Linux como

Windows XP. También hemos gestionado la regeneración de clientes Windows XP en los

casos en los que la reinstalación del mismo era demasiado costosa en tiempo y en los que

había circunstancias especiales (gran similitud entre equipos) que le daban a esta técnica

una ventaja competitiva. La técnica de la generación de imágenes también es una buena

técnica para fines de recuperación global de sistemas (backups) con independencia del

sistema operativo del que se trate, especialmente en catástrofes (incendio, robo, fallos

eléctricos, etc). Este objetivo se ha cumplido al 100 % en los laboratorios del DIT.

Administración cero: Si entendemos por administración cero ”aquel conjunto de procesos

que nos permite gestionar los recursos tanto hardware como software de un grupo de

ordenadores de tal forma que se reducen al mínimo las tareas de administración de éstos”,

creo que podemos afirmar con tranquilidad que el objetivo se ha cumplido. La prueba más

evidente de ello, es la diferencia de tiempo y esfuerzo de administración que requiere

la gestión de los laboratorios docentes con respecto a la época en que se realizaba una

administración tradicional, permitiendo la creciente dedicación de ese tiempo y esfuerzo

a la realización de tareas de alto valor añadido, como pueden ser la mejor documentación

de procesos y la mejor atención a profesores y alumnos.

Especialización de los recursos humanos: Hoy por hoy, los laboratorios docentes del DIT

son gestionados en gran medida por los propios usuarios del mismo (profesores y alum-

nos), dado que es posible que el usuario inicie el proceso de reinstalación o regeneración

97


del sistema operativo por sí mismo, sin necesidad de pedir permiso y sin la posibilidad

de perjudicar en absoluto a ninguno de los otros usuarios del sistema. Esta gestión au-

tomatizada del equipo se le ofrece al usuario mediante el menú de arranque que se le

proporciona a través de la red.

Repetibilidad del proceso de instalación o regeneración: El sistema diseñado ha permitido

realizar la reinstalación o regeneración en su caso de todos los equipos de los laborato-

rios docentes un número muy elevado de veces. De hecho, cuando el alumno inicia un

ordenador y elige la opción de GNU/Linux, lo que está haciendo realmente es realizar

una reinstalación del mismo. La regeneración de Windows XP es una tarea realizada un

número menor de veces, debido a que el proceso de regeneración, aunque es mucho más

breve que el de instalación, es demasiado lento como para realizarlo siempre. Sin embar-

go, hay constancia de que es una tarea que se ha realizado innumerables veces debido a

los múltiples problemas de estabilidad, de seguridad y de administración que se dan en

este sistema operativo. En todos los casos, el sistema ha sido recuperado con total fiabil-

idad (salvo en los casos de fallo hardware, obviamente) por lo que podemos considerar

este objetivo como uno más de los cumplidos.

Reproducción de estado: El sistema de administración centralizada ha permitido ges-

tionar los ordenadores clientes que se usan para realizar tareas de programación avan-

zada, programación de entorno de red, configuración de redes y realización de simula-

ciones, entre otras muchas. Esto es una demostración en sí misma de que la gestión de

los equipos cliente es totalmente reproducible. Pero los beneficios del sistema van aún

más allá, porque al haber sido empleado también para llevar a cabo la gestión de los or-

denadores secundarios (ya que éstos participan del sistema de gestión tanto como clientes

como servidores del mismo) se ha conseguido un sistema de administración centralizada

altamente expansible y reproducible.

Flexibilidad: El sistema se diseñó con la base de la distribución de RedHat en su versión

7.3. En Julio de 2003 ya existen dos versiones posteriores a ésta (la 8.0 y la 9.0) que

ya están soportadas como base de sistema operativo para los servidores y clientes del

laboratorio. También se permite la actualización del software tanto a nivel de aplicación

como a nivel de núcleo y se están desarrollando otros proyectos que, basándose en los

conocimientos manejados en éste, buscan adaptar su funcionalidad a otras distribuciones

de GNU/Linux. Esto demuestra que el sistema diseñado es flexible y es capaz de adaptarse

a los cambios y a las necesidades de sus usuarios.

Rapidez del proceso: La gestión centralizada de los ordenadores del laboratorio ha per-

mitido la reinstalación de GNU/Linux desde la red en escasos minutos, un tiempo ex-

tremadamente breve en comparación con el tiempo de instalación manual del mismo. La


regeneración de Windows XP para un cliente del laboratorio también es mucho más breve

que su instalación manual, aunque debido a las limitaciones del propio sistema operati-

vo, no basta con la regeneración, sino que también hay que dedicar algún tiempo a la

autoconfiguración del mismo.

La reinstalación de servidores mediante el sistema de administración centralizada, en

comparación con lo anterior, es mucho más lento debido a la propia naturaleza secuencial

y el alto consumo de CPU en las tareas de descompresión de archivos y transferencia a

disco, pero también hay que decir que es mucho más rápida por ser desatendida y estar

totalmente automatizada.

Aunque en esta versión del sistema de gestión no se han incluido mecanismos de dis-

tribución multicast de archivos, la utilización de cachés de disco ha permitido minimizar

la utilización de la red para las tareas de regeneración y reinstalación de clientes, con lo

que la rapidez es máxima en la mayoría de los casos. Podemos por tanto dar por cumplido

este objetivo.

Gestión de desastres: La capacidad de auto-regeneración de este sistema es tal, que es

posible regenerar todos los ordenadores (tanto clientes como servidores) que intervienen

en el mismo a partir únicamente del backup del sistema maestro de administración, dado

que el sistema maestro permitiría regenerar todos los servidores secundarios y a partir

de ellos podrán regenerarse todos los ordenadores cliente del laboratorio. La única ex-

cepción a esto son los servidores del laboratorio que no forman parte del sistema de

administración centralizada porque su administración corre a cargo de los profesores de

algún laboratorio.

Independencia: El sistema de administración centralizada es, por su concepción y dise-

ño, independiente de los sistemas operativos que se pretendan administrar. Aunque será

más sencillo administrar servidores o clientes del mismo tipo que el elegido para realizar

la administración, es perfectamente posible administrar servidores o clientes totalmente

diferentes. La demostración es el caso de Windows XP, pero también podría ser el caso

de otras distribuciones GNU/Linux (SuSE, Debian, ...), u otros sistemas operativos para

PC, como podrían ser FreeBSD o Solaris. La dificultad de las nuevas administraciones

vendría directamente de la magnitud de los cambios necesarios pero no de que el sistema

esté directamente ligado a un sistema operativo concreto. De hecho, el sistema central

de administración podría perfectamente ser un ordenador con otro sistema operativo en

lugar de GNU/Linux, aunque necesitara utilizar otros con GNU/Linux que gestionar las

particularidades, ya que todas las herramientas utilizadas para la gestión son de código

abierto y de amplia difusión entre todos los sistemas operativos del momento.


Autonomía: El sistema de administración centralizada es tan autónomo, que permite la

utilización del laboratorio con todas sus características y servicios de forma independiente

de la conexión a Internet e incluso de la red de producción del DIT.

Sostenibilidad: Los clientes del laboratorio van aumentando paulatinamente en número

en los últimos años, así como las aulas dedicadas a éstos. Para la gestión de los mis-

mos es necesaria la utilización de un número determinado de servidores secundarios que

se reparten entre ellos la carga de trabajo. Los servidores de administración de tipo se-

cundario son replicables desde el sistema de administración primario. Esta característica

permite la ampliación de los servicios en una red dada mediante la ampliación en número

de los servidores secundarios y por eso decimos que el sistema de administración centra-

lizada es un sistema sostenible. Incluso, es posible la generación de dominios de apli-

cación como los que se han creado en el DIT, uno para los laboratorios docentes y otro

para la red de producción.

Eficiencia: Aunque resulta difícil medir el grado de eficiencia que ha introducido el sis-

tema de administración centralizada, podría decirse que supera con creces las expectativas

iniciales. Además, este sistema ha ahorrado tiempo no sólo al personal responsable del

servicio, sino también el propio usuario (tanto si es alumno como si es profesor) al pro-

porcionarle un entorno mucho más estable y fiable, evitándose así la mayor parte de los

antiguos problemas.

Gestión de los datos personales: Los datos de los usuarios son guardados de forma pe-

riódica en backups completos, siendo diario el backup incremental a disco. La planifi-

cación de backups incluye los ordenadores principales en los que hay datos de usuario y

aquellos que gestionan las tareas de administración centralizada. De los servidores secun-

darios de arranque o de los clientes del laboratorio no es necesario hacer backup, dado

que no se almacena en ellos información sensible a la pérdida. El cumplimiento de este

objetivo también es total.

8.2. Beneficios extra

Se mencionan a continuación los beneficios que ha proporcionado nuestro sistema fuera de

sus objetivos principales.

1. Desde el punto de vista del usuario, la pérdida de tiempo de la regeneración (que no es

instantánea) compensa con la garantía que ofrece el proceso, ya que en breve se dispone

de un sistema recién instalado y con mucha menor probabilidad de fallo software.


2. Gestionar la primera instalación del ordenador de tipo cliente. Esto permite la instalación

de grandes salas de ordenadores con sólo sacarlos de la caja y conectarlos a la red. Esta

característica requiere un estudio previo de las especificaciones y funcionalidades del

ordenador que se va a instalar e implicará gran parte de la inteligencia del sistema y del

esfuerzo del administrador.

3. Gestionar la primera instalación del ordenador de tipo servidor. Esta característica nos

permite instalar y administrar granjas de servidores y tiene los mismos beneficios que

para los ordenadores de tipo cliente, aunque necesita un estudio previo de requisitos aún

más exhaustivo que el descrito en el punto anterior.

4. Gestionar las actualizaciones de los sistemas y subsistemas software del ordenador (tan-

to de tipo cliente como de tipo servidor) de forma totalmente automática. Gracias a esta

característica, mejora drásticamente la seguridad y estabilidad de los ordenadores ges-

tionados.

5. Controlar el funcionamiento y la configuración de los servicios de forma centralizada, lo

que permitirá llevar un control mucho más íntimo de los sistemas administrados desde el

mismo momento de su instalación.

6. Mejorar drásticamente los costes de mantenimiento: Con este sistema, cuesta lo mismo

instalar una máquina que instalar veinte iguales a ella. El coste de mantenimiento per-

manece constante e independiente del número de ordenadores (siempre que éstos sean

iguales entre sí). Justo lo contrario ocurre, en caso de no utilizar este tipo de sistema de

administración. El coste de mantenimiento sólo aumenta, por tanto, con el número de

estaciones distintas que se quieran soportar.

8.3. Limitaciones

Dependencia del sistema con el fabricante del hardware (sobre todo si no está de acuerdo

con el fabricante del software que queremos instalar). Esto representa una de las princi-

pales limitaciones de los sistemas basados en GNU/Linux, y es que la mayor parte del

código utilizado para gestionar los diferentes dispositivos del PC no ha sido creado por

el fabricante del hardware, con lo que muchas facilidades no estarán implementadas. La

única solución para evitar este tipo de problemas sería concentrar la presión de los usua-

rios para la estandarización de las interfaces hardware, cosa harto difícil debido a las altas

tensiones que ya soporta este mercado.

Dependencia del sistema con el fabricante (o distribuidor) del sistema operativo, porque

cada uno tiene su propio modelo de implementación, e incluso varía entre versiones del


mismo fabricante.

Dependencia del sistema con las capacidades del equipo de administradores, ya que han

poder extraer puntos comunes entre los distintos sistemas que administren (ya sean hard-

ware o software) y de aprovecharlos en el beneficio del sistema.

8.4. Ampliaciones y Trabajos futuros

Hay varias cosas que se han planteado para realizar en un futuro y ampliar la capacidad,

gestionabilidad e inteligencia del sistema de administración centralizada. Se mencionan a con-

tinuación por orden de importancia, especificando brevemente ciertos detalles posibles de su

implementación.

1. Se podrían implementar sistemas más sofisticados para el balanceo de carga de los servi-

dores secundarios. Hoy por hoy, actúan como sistemas independientes, pero podrían lle-

gar a actuar como uno solo gracias a algún tipo de gestor intermedio de carga que repar-

tiese el trabajo uniformemente.

2. Implementación de redes de datos de tipo IPv6 (también llamada la Internet de nueva

generación). Para ello habrá que utilizar servidores que soporten este protocolo. Las dife-

rencias de funcionalidad serían mínimas, pero la capacidad de la red en cuanto a número

de dispositivos direccionables se ampliaría considerablemente.

3. Interfaz gráfico de gestión del laboratorio. Sería posible crear una aplicación basada en

web que permitiese realizar las tareas del operador de forma gráfica, de forma remota y

utilizando un navegador estándar. Esto permitiría que el operador no tuviese que utilizar

el interfaz de comandos del sistema y limitaría al mínimo la formación requerida para la

realización de sus tareas.

4. Servidores PXE para gestionar el arranque de los clientes. Dado que los ordenadores de

tipo cliente tienen la arquitectura PXE, están preparados para recibir la respuesta de un

servidor de protocolo PXE. Aunque, en principio no se obtendría ninguna funcionalidad

extra, el proceso de arranque sería más rápido, dado que los clientes con esta arquitectura

hacen antes las peticiones PXE que las de DHCP. Antes de la instalación definitiva, habría

que comprobar si la competición actual entre los servidores secundarios de arranque sería

tan buen mecanismo de balanceo de carga como lo ha sido en el caso del DHCP.

5. Instalaciones seguras. Cuando el control físico sobre los equipos administrados es total

(tenemos acceso a ellos y están en un entorno gestionado por nosotros) pueden no existir

grandes requisitos de seguridad. Pero cuando esos equipos están fuera de nuestro alcance,


surge la necesidad de asegurarse de que estamos instalando exactamente las máquinas

que queremos y no otras. Así, evitaremos instalar por error servidores no pertenecientes

al sistema y que terceras partes no autorizadas sean capaces de interceptar la información

transmitida para la administración.

En este entorno, también parece necesaria la implantación de una política de seguridad

que permita controlar no sólo la integridad del software instalado en servidores y clientes,

sino también otros parámetros de seguridad relativos a las restricciones de acceso a los

mismos y a la administración de los datos privados de los usuarios con respecto a la

normativa vigente en cada caso.

6. Reseteo automático de consolas de equipos. La idea se basa en tener una página web con

un formulario en el que el usuario elige la consola que quiere resetear y con un simple

click envía el comando, permitiéndole recuperar el control del equipo remoto que estaba

gestionando a través de la consola y que por alguna circunstancia había perdido. Esta sería

una utilidad particularmente interesante en los laboratorios en los que se utilizan equipos

remotos (routers, conmutadores, etc) y se gestionan mediante una consola de red.

7. Gestión automática de VLANes. Las redes virtuales a nivel de enlace son, cada vez más,

una tecnología muy útil, dado que permiten aislar muy fácilmente dominios de broad-

cast en los equipos conmutadores y vienen integradas con herramientas que permiten

gestionar los puertos de acceso de forma remota. Esto sería muy potente sobre todo en

entornos de red cambiantes, y permitiría realizar las prácticas del laboratorio de redes del

departamento con muchos entornos diferentes y con una alta sencillez de configuración

del entorno.

8. Utilización del protocolo multicast para la trasmisión de las imágenes de arranque. Para

ello, habría que integrar en el sistema servidores TFTP multicast. Para aumentar más

los beneficios de este sistema, se podrían transmitir las imágenes de regeneración y las

de instalación también por TFTP (en lugar del NFS que se usa actualmente) con lo que

mejoraría drásticamente la gestión de instalaciones y reinstalaciones de todo el laboratorio

en paralelo, como por ejemplo, cuando se instala una imagen por primera vez.

Bibliografía

[1] Replicator (conjunto de programas para automatizar la duplicación de un modelo de orde-

nador que ejecute Debian/GNU Linux).http://replicator.sourceforge.net/

[2] FAI (Fully Automatic Installation) para Debian GNU/Linux.http://www.informatik.

uni-koeln.de/fai/index.html

[3] Sistema de Arranque Remoto para Ordenadores IBM PC y Compatibles. Manuel J. Petit.

http://www.dit.upm.es/mpetit/boots/pfc.ps

[4] Implantación de un Laboratorio Docente para Redes de Comunicaciones. Francisco Javier

Ruiz, David Fernández, Ana B. García, Fernando Muñoz, Luis Bellido, Tomás de Miguel

(Departamento de Ingeniería de Sistemas Telemáticos. E.T.S.I. Telecomunicación. Uni-

versidad Politécnica de Madrid), José I. Moreno (Departamento de Ingeniería Telemática.

Universidad Carlos III de Madrid). Jornadas de Ingeniería Telemática - Jitel 2001 (Depar-

tament d’Enginyeria Telemática, Universidad Politècnica de Catalunya).

[5] Sistema automático de Administración Centralizada. Tomás de Miguel, Judith Álvarez,

Omar Walid, Eduardo Gómez (Departamento de Ingeniería de Sistemas Telemáticos.

E.T.S.I. Telecomunicación. Universidad Politécnica de Madrid), Antonio Beamud (Agora

Systems S.A.). Jornadas de Ingeniería Telemática - Jitel 2001 (Departament d’Enginyeria

Telemática, Universidad Politècnica de Catalunya).

[6] Proyecto Fin de Carrera: ”Desarrollo de un sistema distribuido de reserva de recursos de

laboratorio”. José Antonio Mendoza Lorente. ETSIT-UPM. 2000

[7] Netboothttp://netboot.sourceforge.net

[8] Etherboothttp://etherboot.sourceforge.net

[9] Syslinuxhttp://syslinux.zytor.com/

[10] Pxelinuxhttp://syslinux.zytor.com/pxe.php

104

BIBLIOGRAFÍA 105

[11] Preboot Execution Environment (PXE) Specification. Septiembre de 1999.ftp://

download.intel.com/labs/manage/wfm/download/pxespec.pdf

[12] Dynamic Host Configuration Protocol (DHCP)http://www.ietf.org/rfc/rfc2131.

txt

[13] RedHat Kickstart http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/

custom-guide/ch-kickstart2.html

[14] The ”Zero Administration” Initiative for Microsoft Windows.http://msdn.microsoft.

com/library/default.asp?url=/library/en-us/dnentdevgen/html/msdn_

zerowin.asp

[15] Network PCs - Reducing Total Cost of Ownership While Leveraging the Power and Com-

patibility of PC Computinghttp://msdn.microsoft.com/library/default.asp?

url=/library/en-us/dnentdevgen/html/msdn_netpc.asp

[16] Proyecto GNUhttp://www.gnu.org/

[17] Núcleo Linuxhttp://www.kernel.org/

[18] Microsofthttp://www.microsoft.com/

[19] Bootstrap Protocol (BOOTP)http://www.ietf.org/rfc/rfc951.txt

[20] A Reverse Address Resolution Protocol (RARP)http://www.ietf.org/rfc/rfc903.

txt

[21] Bootstrap loading using TFTPhttp://www.ietf.org/rfc/rfc783.txt, http://www.

ietf.org/rfc/rfc906.txt

[22] RedHathttp://www.redhat.com

[23] Autoit http://www.hiddensoft.com/autoit3/

[24] Microsoft System Preparation Tool (Sysprep)http://www.microsoft.com/technet/

treeview/default.asp?url=/TechNet/prodtechnol/windows2000pro/deploy/

depopt/sysprep.asp

[25] Sambahttp://www.samba.org/

[26] Network File System Protocol Specification (NFS)http://www.ietf.org/rfc/

rfc1094.txt

BIBLIOGRAFÍA 106

[27] Rembo Listserver Archives. Asunto del mensaje: Security. Fecha: Junio de 2003.http:

//listas.us.es/pipermail/rembo/2003-June/000218.html

[28] Rembo Auto-Deploy, Rembo Technology SaRLhttp://www.rembo.com

[29] GRand Unified Bootloaderhttp://www.gnu.org/software/grub/

[30] Linux Remote-Boot mini-HOWTO: Configuring Remote-Boot Workstations with Linux,

DOS, Windows 95/98 and Windows NT Marc Vuilleumier Stückelberg, David Clerc

v3.26, February 2000http://cui.unige.ch/info/pc/remote-boot/howto.html

[31] BP-Batchhttp://www.bpbatch.org/

[32] Unattendedhttp://unattended.sourceforge.net/

[33] Real Men Don’t Clickhttp://isg.ee.ethz.ch/tools/realmen/

[34] Labmice: Unattended, Automated, and Remote Installations of Windows 2000http://

www.labmice.net/Windows2000/install/unattend_install.htm

[35] Windows 2000 Unattended Installations and related utilitieshttp://www.willowhayes.

co.uk/

[36] Power Questhttp://www.powerquest.com/

[37] Norton Ghosthttp://www.symantec.com/sabu/ghost/ghost_personal/

[38] Partimagehttp://www.partimage.org/

[39] Windows WinInstall LE ("limited edition")http://ftp.support.veritas.com/pub/

support/products/WinINSTALL_LE/247602.pdf

[40] Aefdiskhttp://www.aefdisk.com/

[41] Fdiskhttp://cvs.kerneli.org/util-linux/fdisk/

[42] Linux Loader (LILO) http://brun.dyndns.org/http://www.advogato.org/proj/

lilo/

[43] Knoppix - Live Linux Debian CDhttp://www.knoppix.org/

[44] SQUID Web Proxy Cachehttp://www.squid-cache.org/

[45] Netfilter Iptableshttp://www.netfilter.org/

[46] Firewall Builderhttp://www.fwbuilder.org/

BIBLIOGRAFÍA 107

[47] Internet Software Consortiumhttp://www.isc.org

[48] ANSI/IEEE Standard 802.1Q, "IEEE Standards for Local and Metropolitan Area Net-

works: Virtual Bridged Local Area Networks", 1998. (VLAN 802.1q) ISBN: 0-7381-

3663-8.

[49] Sedhttp://www.gnu.org/directory/sed.html

[50] Makehttp://www.gnu.org/directory/make.html

[51] Rdisthttp://www.magnicomp.com/rdist/

[52] Rsynchttp://samba.anu.edu.au/rsync/index.html

[53] Network Interface Loader (NILO)http://www.nilo.org/

[54] Superuser Do (sudo)http://www.courtesan.com/sudo/

[55] Kickstart Toolshttp://kickstart-tools.sourceforge.net

[56] Autoupdatehttp://www.mat.univie.ac.at/~gerald/ftp/autoupdate/

[57] Analoghttp://www.analog.cx/

[58] Network Mapper (nmap)http://www.insecure.org/nmap/

[59] Printquotahttp://printquota.sourceforge.net/

[60] Bart’s Network Boot Diskhttp://www.nu2.nu/bootdisk/network/

[61] Unattended Install of Windows 2000. Karl Bernard, University of Houston, Information

Technology, Texas.http://www.uh.edu/windows2000/docs/Unattended_Install.

doc

[62] Autoinstalación de Windows XP. Pedro Jesús Pérez García. DIT-UPM.http://oasis.

dit.upm.es/~pjpg/autoinst/

[63] The XFree86 Project, Inc.http://www.xfree.org

[64] ROM-O-MATIC http://www.rom-o-matic.org/

Pliego de condiciones

Requisitos hardware

Al menos dos PCs Intel Pentium, conectados a través de routers y hubs, de tal forma que

uno haga de servidor maestro o principal, mientras que el otro tomará el papel de servidor

de arranque o binario. El ordenador cliente no es necesario para el desarrollo del proyecto

(dado que los binarios son a su vez clientes del maestro) aunque lo será en la fase de

despliegue.

Equipamiento de redes de área local: tarjetas de red Ethernet a 100Mbps (con ROM PXE

en cada uno de ellos) y un conmutador ethernet que les permita comunicarse.

Acceso a Internet

Requisitos software

Discos de instalación de Windows XP Professional y de RedHat 7.3 GNU/Linux. Licencia

de Windows XP.

Discos de instalación del software ofimático y de aplicación específica, así como de sus

licencias de utilización.

108

Presupuesto

Este proyecto se ha desarrollado dentro del Centro de Cálculo del Departamento de Inge-

niería de Sistemas Telemáticos de la Universidad Politécnica de Madrid.

Costes

A continuación se dividen los costes de ejecución material en costes de equipamiento (o

costes materiales) y costes de mano de obra.

Costes Materiales

El Centro de Cálculo del DIT cuenta ya con una serie de instalaciones y equipos que han sido

suficientes para la implementación de la arquitectura del sistema de administración centraliza-

da y la realización de las diferentes pruebas de funcionamiento del mismo. Para la valoración

del equipamiento utilizado se han considerado diferentes porcentajes según la utilización del

equipamiento en funciones correspondientes a este proyecto. Esos porcentajes han sido intro-

ducidos en el presupuesto de este proyecto para calcular la influencia del mismo en la inversión

total realizada. También se incluyen como costes generales el suministro eléctrico, el material

fungible y el gasto en comunicaciones.

En las siguientes tablas de coste se desglosan los costes por equipo.

Material Coste (euros)

24-port 10/100 Switch w/Two Module Slots 4.4002-port 100BaseFX ISL/802.1Q Switch Module 1.734

Total 6.134

Tabla 10.1: Conmutador Ethernet Cisco Catalyst 2900 (WS-C2924M-XL-EN)

109

Presupuesto 110

Material Coste (euros) Uso ( %) Coste final (euros)

2 PC Intel Pentium III 850MHz 1.800 100 1.8001 Licencia de Windows XP Professional 260 100 2601 Licencia de Office XP 340 100 3401 Conmutador Ethernet Cisco Catalyst 2900 6.134 5 306,70

Total 2.706,70

Tabla 10.2: Costes de Material Total

Costes de Mano de Obra

En el proyecto ha intervenido un Ingeniero Superior de Telecomunicación que es el que

se ha encargado del desarrollo de las diferentes tareas que engloba. En la siguiente tabla se

encuentra un desglose de tareas y la duración estimada de las mismas en horas de trabajo.

Tarea Duración (horas)

Estudio previo sobre sistemas de arranque remoto 120Estudio previo sobre implementaciones comerciales 70Instalación de sistemas finales 200Definición del modelo 30Implementación del escenario de pruebas 10Desarrollo de aplicaciones específicas 200Pruebas 100Elaboración de la memoria 300

Total 1.030

Tabla 10.3: Horas de Mano de Obra

Multiplicando por el sueldo por hora de un Ingeniero, se obtiene el coste total de la mano

de obra.

Responsable Tiempo Coste Total

Ingeniero Superior 1.030 horas 30 euros/hora 30.900 euros

Tabla 10.4: Costes de Mano de Obra

Gastos Generales

Se consideran gastos generales las amortizaciones, las cargas fiscales y jurídicas y gastos de

instalación, que se valoran en el 15 % del presupuesto de ejecución material.

Presupuesto 111

Presupuesto total

Concepto Coste (euros)

Coste material 2.706,70Coste de mano de obra 30.900Presupuesto de ejecución material 33.606,70

Gastos generales 5.041Presupuesto de ejecución 38.647,70

IVA (16 %) 6.183,63

TOTAL 44.831,33

Tabla 10.5: Presupuesto Total

El presupuesto total del proyecto alcanza la cifra de CUARENTA Y CUATRO MIL OCHO-

CIENTOS TREINTA Y UN EUROS CON TREINTA Y TRES CÉNTIMOS.

Madrid, 22 de julio de 2003

EL INGENIERO PROYECTISTA

Fdo. Omar Aurelio Walid Llorente

proyecto fin de carrera - dit.upm.esomar/pfc/proyecto_omar/proyecto_omar.pdf · antecedentes del...

Documents