#LyX 1.3 created this file. For more info see http://www.lyx.org/ \lyxformat 221 \textclass book \begin_preamble %% omar -- lo siguiente pone las etiquetas de tabla en itálica \usepackage[small,hang]{caption2} \renewcommand\captionfont{\it \small} \renewcommand\captionlabelfont{\it \small} \renewcommand\captionlabeldelim{:} %% omar -- prueba para poner titulos en los laterales %\input sidefig.sty %\begin{sidefig}[table]{Una tabla de prueba}{theLabel} %\end{sidefig} \usepackage[chapter] {tocbibind} \end_preamble \language spanish \inputencoding auto \fontscheme pslatex \graphics default \paperfontsize 12 \spacing onehalf \papersize a4paper \paperpackage a4 \use_geometry 1 \use_amsmath 0 \use_natbib 1 \use_numerical_citations 1 \paperorientation portrait \leftmargin 3cm \topmargin 1.5cm \rightmargin 2cm \bottommargin 1.5cm \headheight 1cm \headsep 1cm \footskip 1cm \secnumdepth 5 \tocdepth 5 \paragraph_separation indent \defskip medskip \quotes_language swedish \quotes_times 2 \papercolumns 1 \papersides 1 \paperpagestyle fancy \layout Standard \begin_inset ERT status Inlined \layout Standard \backslash pagestyle{empty} \end_inset \layout Standard \align center \series bold \size larger UNIVERSIDAD POLITÉCNICA DE MADRID \layout Standard \added_space_top bigskip \align center \size larger \noun on Escuela Técnica Superior de Ingenieros de \newline Telecomunicación \layout Standard \added_space_top bigskip \align center \begin_inset Graphics filename ../Proyecto_Omar_figuras/Logo_etsit_2b.gif lyxscale 80 display color height 2cm keepAspectRatio \end_inset \layout Standard \added_space_top bigskip \align center \series bold \size largest PROYECTO FIN DE CARRERA \layout Standard \added_space_top 7cm \align center \series bold \size largest Implementación de un Sistema de Gestión para Laboratorios Docentes \series default \newline \SpecialChar \- \newline \series bold \size larger Sistema de Administración Centralizada \layout Standard \added_space_top 3cm \align center \series bold \size larger OMAR AURELIO WALID LLORENTE \layout Standard \align center \begin_inset ERT status Inlined \layout Standard \backslash Large{ \backslash bf{{22 de julio de 2003 \backslash \backslash }}} \end_inset \layout Title \pagebreak_top \series bold \size larger UNIVERSIDAD POLITÉCNICA DE MADRID \series default \noun on \newline \size large Escuela Técnica Superior de Ingenieros de Telecomunicación \series bold \size huge \noun default \newline \newline \series default \size default \begin_inset Graphics filename ../Proyecto_Omar_figuras/Logo_etsit_2b.gif lyxscale 80 display color height 1.5cm keepAspectRatio \end_inset \series bold \size huge \newline \series default \size large \noun on Departamento de Ingeniería de Sistemas Telemáticos \series bold \size huge \noun default \newline \newline \newline \newline \newline Implementación de un Sistema de Gestión para Laboratorios Docentes \newline \newline \size default Sistema de Administración Centralizada \newline \layout Author \series bold \size larger Autor: \series default Omar Aurelio Walid Llorente \newline \series bold Tutor: \series default Tomás Pedro de Miguel Moro \layout Date \pagebreak_bottom \series bold \size larger Fecha: \series default \size default \begin_inset ERT status Inlined \layout Standard \backslash Large{{ \backslash today \backslash \backslash }} \end_inset \layout Standard \align left \series bold Título: \layout Standard \align left Implementación de un sistema de gestión para laboratorios docentes \layout Standard \align left \series bold Subtítulo: \layout Standard \align left Sistema de Administración Centralizada \layout Standard \align left \series bold Autor: \layout Standard \align left D. Omar Aurelio Walid Llorente \layout Standard \align left \series bold Tutor: \layout Standard \align left D. Tomás Pedro de Miguel Moro \layout Standard \align left Profesor Titular de la Universidad Politécnica de Madrid \layout Standard \added_space_top 3cm \added_space_bottom bigskip \align left \series bold Tribunal: \layout Standard \align left \series bold \begin_inset Tabular \begin_inset Text \layout Standard Presidente \end_inset \begin_inset Text \layout Standard : \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard D. Tomás Pedro de Miguel Moro \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard Vocal \end_inset \begin_inset Text \layout Standard : \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard D. Santiago Pavón Gómez \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard Secretario \end_inset \begin_inset Text \layout Standard : \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard D. David Fernández Cambronero \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard Suplente \end_inset \begin_inset Text \layout Standard : \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard D. Víctor Abraham Villagrá González \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard Calificación \end_inset \begin_inset Text \layout Standard : \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard Madrid, \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard de \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard de 2003 \end_inset \end_inset \layout Standard \pagebreak_top \align right \series bold \size large \begin_inset ERT status Inlined \layout Standard \backslash vspace*{5cm} \end_inset \layout Standard \align right \series bold \size large \emph on A mi tía-abuela, a mi madre y a mi hermana. \layout Standard \align right \series bold \size large \emph on A Judith, por su apoyo incondicional. \layout Standard \align right \series bold \size large \emph on A los que han demostrado ser mis amigos, \newline por escucharme siempre que lo he necesitado. \layout Standard \align right \series bold \size large \emph on A todos los miembros del Centro de Cálculo del DIT, \newline por su ilusión y su trabajo, y porque sin ellos, \newline este proyecto no habría sido posible. \layout Standard \pagebreak_bottom \begin_inset ERT status Inlined \layout Standard \backslash setcounter{chapter}{0} \layout Standard \backslash setcounter{section}{0} \layout Standard \backslash setcounter{subsection}{0} \layout Standard \backslash setcounter{page}{-1} \layout Standard % \backslash frontmatter \layout Standard \backslash renewcommand \backslash thepage{ \backslash Roman{page}} \end_inset \layout Standard \align left \series bold \size large Resumen: \layout Standard \size large 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, resulta necesario encontrar una solución que permita gestionar de forma automática 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 Departamento 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). \layout Standard \added_space_top 1cm \noindent \series bold \size large Abstract: \layout Standard \size large 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. \layout Standard \added_space_top 1cm \align left \series bold \size large Palabras Clave: \layout Standard \size large 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. \layout Standard \added_space_top 1cm \noindent \series bold \size large Key Words: \layout Standard \size large Zero Administration, Centralized Administration, Automatic installation, \SpecialChar \- Unattended installation, Systems administration, Networks administration, Partition regeneration, Network boot, PXE, DHCP. \layout Standard \begin_inset LatexCommand \tableofcontents{} \end_inset \layout Standard \begin_inset FloatList table \end_inset \layout Standard \begin_inset FloatList figure \end_inset \layout LyX-Code \begin_inset ERT status Inlined \layout Standard \backslash mainmatter \end_inset \layout Standard \begin_inset ERT status Inlined \layout Standard \backslash pagestyle{fancy} \backslash lhead{ \backslash leftmark} \layout Standard \backslash renewcommand{ \backslash sectionmark}[1]{ \backslash markright{ \backslash thesection. \backslash #1}} \backslash renewcommand{ \backslash chaptermark}[1]{ \backslash markboth{ \backslash thechapter. \backslash #1}{}} \layout Standard \backslash renewcommand{ \backslash thefootnote}{ \backslash alph{footnote}} \layout Standard \backslash chead{} \layout Standard \backslash rhead{ \backslash thepage} \layout Standard \backslash lfoot{} \layout Standard \backslash cfoot{} \layout Standard \backslash rfoot{} \layout Standard \backslash renewcommand{ \backslash headrulewidth}{0.4 pt} \end_inset \layout Chapter Introducción \layout Section Antecedentes del proyecto \layout Standard 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 ordenador personal, este sistema de arranque era relativamente desconocido hasta la década de los 90. \layout Standard En esta época, empezaron a surgir los primeros proyectos que permitían a un PC arrancar 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 \begin_inset LatexCommand \cite{Boots} \end_inset para más informació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 ordenadore s 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. \layout Standard 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 almacenamiento, 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 \begin_inset LatexCommand \cite{Etherboot,Netboot,Syslinux} \end_inset ) 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 Free-BSD. \layout Standard A finales de los 90, surgieron nuevas especificaciones que cambiaron totalmente la definició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ía n iniciar sus sistemas operativos desde la red, así surgieron el PXE \begin_inset LatexCommand \cite{PXE} \end_inset (siglas de Preboot eXecution Environment) y el DHCP \begin_inset LatexCommand \cite{DHCP} \end_inset (acrónimo de Dynamic Host Configuration Protocol y evolución del BOOTP). \layout Section Motivación \layout Standard 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\SpecialChar \- 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. \layout Standard Las necesidades que han impulsado este proyecto son aquellas que resultan de la implanta\SpecialChar \- ción de redes con alta densidad de ordenadores. El abaratamiento de costes y las econo\SpecialChar \- mías de escala de los ordenadores de tipo PC (siglas originales de \family sans Personal Computer \family default ) 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. \layout Standard 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. \layout Standard 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). \layout Standard 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 operativo, 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 resolver y en el cual entraremos en profundidad más adelante. \layout Standard 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. \layout Standard 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. \layout Standard 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 te\SpecialChar \- ne\SpecialChar \- 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 ad\SpecialChar \- mi\SpecialChar \- nis\SpecialChar \- tr a\SpecialChar \- 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. \layout Section Sistemas Operativos para Ordenadores PC \layout Standard 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 procesamient o de datos mucho más potentes. \layout Standard 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. \layout Standard Dentro de los entornos Windows, se ha dado soporte a diferentes sistemas (desde el Windows 98 al Windows XP Professional, pasando por el Windows NT 4.0), sin embargo, en este documento sólo se mencionarán las tareas realizada s para la automatización de la gestión del entorno más moderno de todos ellos (el Windows XP Professional). \layout Standard 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 proyecto nos centraremos en la distribución RedHat 7.3, aunque se podrían haber utilizado otras distribuciones, de las 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 compilaciones del núcleo del sistema operativo Linux que suelen dar soporte a gran variedad de dispo\SpecialChar \- siti vos hardware, incluyendo para éstos las mejoras más recientes. \layout Standard 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 \begin_inset LatexCommand \cite{Boots} \end_inset 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 \begin_inset LatexCommand \cite{nfs} \end_inset ) en la época de los procesadores Intel 80286 y 80386. Más adelante, se utilizaba tanto Etherboot \begin_inset LatexCommand \cite{Etherboot} \end_inset como Netboot \begin_inset LatexCommand \cite{Netboot} \end_inset 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. \layout Section Análisis de las soluciones disponibles \layout Standard 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átic o de los sistemas operativos de un gran número de ordenadores, tanto de servidores de red como de máquinas de usuario o 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. \layout Standard 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. \layout Subsection Entorno GNU/Linux \layout Standard Si nos planteamos el realizar un sistema de administración centralizada para sistemas GNU/\SpecialChar \- Linux, estará bien que empezamos a analizar las utilidades disponibles para la gestión de ordenadores. 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 últimos años en todos los sentidos. También cabe comentar que esta misma característica ha promovido 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\SpecialChar \- Linux \begin_inset LatexCommand \cite{linux} \end_inset como núcleo del sistema y todas aprovechan en mayor o menor medida la gran cantidad de herramientas proporcionadas por el proyecto GNU \begin_inset LatexCommand \cite{GNU} \end_inset . \layout Standard Así, mediante la funcionalidad de la herramienta Kickstart \emph on \emph default \begin_inset LatexCommand \cite{kickstart} \end_inset \emph on \emph default de la distribución RedHat \begin_inset LatexCommand \cite{RedHat} \end_inset podemos realizar la instalación del sistema operativo, también podemos elegir las aplicaciones 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 aplicació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 actualizac iones software del mismo. Hay proyectos que intentan mejorar la funcionalidad 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 \begin_inset LatexCommand \cite{kickstart-tools} \end_inset . \layout Standard También hay que mencionar Replicator \begin_inset LatexCommand \cite{Replicator} \end_inset y FAI \begin_inset LatexCommand \cite{FAI} \end_inset 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í 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. \layout Standard 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 \begin_inset LatexCommand \cite{GRUB} \end_inset 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 \begin_inset LatexCommand \cite{lilo} \end_inset , que últimamente ha introducido mejoras para el arranque de discos virtuales y ofrece diferentes facilidades. \layout Standard 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 \begin_inset LatexCommand \cite{Syslinux} \end_inset , un gestor de arranque que permite 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ífico 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. \layout Standard Además, todos los sistemas de gestión de arranque que hemos mencionado tienen la posibilidad 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. \layout Standard 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 \begin_inset LatexCommand \cite{Netboot} \end_inset , Etherboot \begin_inset LatexCommand \cite{Etherboot} \end_inset , NILO \begin_inset LatexCommand \cite{nilo} \end_inset , Boots \begin_inset LatexCommand \cite{Boots} \end_inset , Bootmagic \begin_inset LatexCommand \cite{powerquest} \end_inset o Bp-batch \begin_inset LatexCommand \cite{bp-batch} \end_inset 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 aportadas. \layout Standard 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 \begin_inset LatexCommand \cite{knoppix} \end_inset ). 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. \layout Standard 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 \begin_inset LatexCommand \cite{fdisk} \end_inset , 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. \layout Subsection Entorno Microsoft Windows \layout Standard Si hablamos ahora de las herramientas de instalación automática del sistema operativo Windows XP Professional, aunque hay ciertas facilidades de red que permiten realizar la configuración automática de los dispositivos soportado s por el sistema operativo, no hay tantas facilidades disponibles para el administrador. \layout Standard 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. \layout Standard 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 \begin_inset LatexCommand \cite{sysprep} \end_inset , 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. \layout Standard 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 \begin_inset Quotes sld \end_inset unirse al dominio \begin_inset Quotes srd \end_inset ), sobre todo si deseamos que el controlador principal del dominio no sea un ordenador de la plataforma Microsoft Windows (véase la información sobre el proyecto Samba \begin_inset LatexCommand \cite{samba} \end_inset ) ya que el protocolo utilizado para este tipo de servicios está lejos de ser una especificación abierta. \layout Standard 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\SpecialChar \- 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 \begin_inset LatexCommand \cite{Samba y dominio XP} \end_inset . \layout Standard 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 \begin_inset LatexCommand \cite{Autoit} \end_inset . En este sentido también podemos utilizar una aplicación llamada WinstallLE \begin_inset LatexCommand \cite{winstallle} \end_inset 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. \layout Standard 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 pretende 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. \layout Standard 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 requerimient os tales como que el sistema de almacenamiento ha de tener un formato determinad o (NTFS) si queremos 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. \layout Standard No hay que olvidar mencionar que también hay otras herramientas de Microsoft que permiten 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). \layout Standard También hay otros proyectos que pretenden implementar sistemas de instalación desatendida de sistemas Windows desde servidor. Así, podemos mencionar Unattended \begin_inset LatexCommand \cite{unattended} \end_inset y Realmen \begin_inset LatexCommand \cite{realmen} \end_inset . También hay gran número de páginas dedicadas a la recopilación de información y artículos que versan sobre el tema en Labmice.net \begin_inset LatexCommand \cite{labmice-unattended} \end_inset y en Willowhayes \begin_inset LatexCommand \cite{oli-willowhayes} \end_inset . \layout Standard Uno de los sistemas de administración automática más divulgados para gestionar máquinas Windows es Rembo Auto-Deploy \begin_inset LatexCommand \cite{rembo} \end_inset , un sistema a su vez basado en Windows NT/2000. Tambié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 instalació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 última tecnología en protocolos de gestión de red (PXE, DHCP y Multicast) otro posible pro\SpecialChar \- blema 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 diversos sub-servidores de imágenes, lo que obliga a que todos los clientes tengan acceso directo al servidor de administración. \layout Standard 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 \begin_inset LatexCommand \cite{norton-ghost} \end_inset , PQDI (Power Quest Drive Image \begin_inset LatexCommand \cite{powerquest} \end_inset ) para Windows XP y Partimage \begin_inset LatexCommand \cite{partimage} \end_inset para Linux. \layout Standard 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 arrancando. Además de las de Linux, podemos utilizar Partition Magic \begin_inset LatexCommand \cite{powerquest} \end_inset para Windows y el aefdisk \begin_inset LatexCommand \cite{aefdisk} \end_inset para MS-DOS. \layout Chapter Objetivos \layout Section Problemas que se pretenden resolver \layout Comment Estado inestable de los ordenadores, administración cero de los ordenadores, mala gestión de los usuarios, problemas de virus y otras intromisiones en el sistema, actualización sistemática de los SO. \layout Standard 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. \layout Enumerate 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\SpecialChar \- ble\SpecialChar \- mas de seguridad (virus, troyanos, gusanos, puertas traseras, etc) que son más graves cuanto menos experto en informática es el usuario del sistema. \layout Enumerate Problemas de Repetibilidad de las pruebas: ordenadores en que uno o varios admi\SpecialChar \- nis\SpecialChar \- tra\SpecialChar \- do\SpecialChar \- res 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. \layout Enumerate 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. \layout Enumerate Salas de ordenadores (laboratorios, cibercafés y centros de trabajo): conjuntos de ordenadores 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. \layout Enumerate 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 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. \layout Enumerate 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. \layout Enumerate 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. \layout Enumerate Fallos de estabilidad de los sistemas operativos: problemas causados por la incompatibilidad 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 solución pasa por la reinstalación del ordenador, hemos encontrado un candidato más a los sistemas de administraci ón centralizada. \layout Enumerate 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. \layout Section Requisitos generales \layout Standard Para resolver algunos de los problemas anteriormente descritos pueden adoptarse diversas soluciones, algunas de las cuales nosotros hemos decidido no contempla r por el elevado consumo 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. \layout Enumerate No requerir más personal cualificado cuando aumenta el número de ordenadores adminis\SpecialChar \- 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 ordenadore s. \layout Enumerate 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. \layout Enumerate 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). \layout Enumerate 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. \layout Enumerate El usuario no tendrá que responder a ninguna pregunta una vez que ha elegido realizar la reinstalación del sistema. \layout Enumerate 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. \layout Enumerate 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. \layout Enumerate 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 procedimient os de verificación de integridad permitirán regenerar el sistema sin malgastar recursos de red. Además, habrá que redimensionar adecuadamente las redes locales para garantizar una buena calidad del servicio. \layout Enumerate 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 suficientemente 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. \layout Enumerate 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. \layout Section Requisitos del entorno \layout Standard 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. \layout Standard 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. \layout Standard 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 consistió 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, 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. \layout Standard 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. \layout Section Objetivos \layout Comment Repetibilidad y reproducción de estado, flexibilidad, rapidez de instalación, autonomía, sostenibilidad, NO: instalación de servidores a mano, NO: reparación de servidores \layout Standard 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. \layout Itemize Instalación y/o regeneración desatendida: Dada la diversidad de sistemas operativos y aplicaciones que queremos incluir en nuestro sistema de administra ció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. \layout Itemize 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 software de un grupo de ordenadores de tal forma que se reducen al mínimo las tareas de administración de éstos. \begin_deeper \layout Standard De hecho, algunas de las tareas que más tiempo consumen se eliminan de forma completa. 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 rege\SpecialChar \- ne\SpecialChar \- ra\SpecialChar \- ción de su sistema completo y, en caso de que no sea suficiente, se buscará el problema en profundidad. \end_deeper \layout Itemize 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. \begin_deeper \layout Standard 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. \layout Standard 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. \layout Standard 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 implementación es posible con la tecnología de que disponemos. \end_deeper \layout Itemize 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 cen\SpecialChar \- tra\SpecialChar \- li\SpecialChar \- zada. 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 \begin_inset LatexCommand \ref{cha:Discusiones-de-diseño} \end_inset , 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. \layout Itemize 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. \layout Itemize 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 importante, será posible adaptarse a los cambios de entorno producidos por las actualizaciones del software del que se pretende dar soporte. \layout Itemize Rapidez del proceso: El sistema ha de ser suficientemente ágil como para que sea sustancialmente 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 administrado s, debería ser posible la regeneración o reinstalació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. \layout Itemize 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 inactivos 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. \layout Itemize Independencia: El sistema debe ser totalmente independiente, de tal forma que los cambios 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 herramien tas que tenemos a nuestro alcance y que podremos actualizar, modificar o sustituir por otras cuando 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 administrado 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. \layout Itemize 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 dependerá de ciertos medios que habrán de estar disponibles para la llevar a cabo las mismas. \layout Itemize Sostenibilidad: Esta característica nos permitirá aumentar el conjunto de ordenadores administrados 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 parecidos entre sí de tal forma que su replicación sea tan sencilla como la de cualquiera de los ordenadores administrados. \layout Itemize 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. \layout Itemize 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). \layout Chapter \begin_inset LatexCommand \label{cha:Discusiones-de-diseño} \end_inset Discusiones de diseño \layout Comment Estado del Arte, visiones del diseño, planteamientos generales, tareas a realizar, funciones y decisiones generales de trabajo, elecciones de métodos (instalación o regeneración), dependencias del sistema, ahorro de trabajo aplicando las herramientas proporcionadas por los sistemas operativos \layout Section Introducción \layout Comment Son muchos los proyectos que han pretendido resolver estas necesidades, pero no vamos a describir ninguno de ellos en particular. En esta sección, lo que se pretende realizar es un análisis de cuáles son las soluciones técnicas que se pueden adoptar para resolver el problema. \layout Standard 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 pretendemos 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, dependiendo 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 procedimientos 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ático 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. \layout Section Instalación automática \layout Standard \begin_inset LatexCommand \label{sub:Instalación-automática} \end_inset 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. \layout Standard 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 automá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 re\SpecialChar \- ge\SpecialChar \- ne\SpecialChar \- ra\SpecialChar \- ció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. \layout Standard 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. \layout Standard 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 \begin_inset LatexCommand \ref{sub:Fase-de-arranque} \end_inset se dan amplios detalles de la fase de arranque del ordenador PC): \layout Itemize 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. \layout Itemize En un CDROM o DVDROM. Este tipo de soporte, al tener mayor capacidad, puede incluso contener el sistema operativo completo, de tal forma que no sea necesario utilizar ningún otro medio para finalizar la instalación. \layout Itemize En un ordenador remoto y accesible a través de la red de datos. Para que este procedimiento sea efectivo, será necesario proporcionar previamen te al ordenador alguna herramienta para que sea capaz de averiguar sus parámetro s de conexión a la red de datos. \layout Standard 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. \layout Standard 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. \layout Standard Uno de los grandes inconvenientes de los sistemas de instalación automática es la heterogeneidad 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. \layout Section \begin_inset LatexCommand \label{sec:Regeneración-cruda} \end_inset Regeneración cruda \layout Standard Tipos de regeneración: \layout Enumerate Clonación de discos duros: Como sabemos, el disco duro es la parte del ordenador encargada del almacenamiento permanente del sistema operativo y sus aplicacione s 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. \begin_deeper \layout Itemize Ventajas: \begin_deeper \layout Enumerate 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). \layout Enumerate Es muy sencillo, habiendo una gran variedad de programas para todos los sistemas operativos que son capaces de realizar este tipo de operación. \layout Enumerate 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 posterior a la primera instalación) lo que significaría una vuelta al trabajo casi inmediata. \layout Enumerate 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. \end_deeper \layout Itemize Inconvenientes: \begin_deeper \layout Enumerate Cualquier pequeña modificación de la configuración del sistema supone la nece\SpecialChar \- 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 sistema a gestionar, sobre todo si los ordenadores no son todos idénticos en hardware y software, lo que supone una gran cantidad de trabajo. \layout Enumerate 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. \layout Enumerate Normalmente la recuperación del sistema requiere un sistema operativo con una funcionalidad mínima, que será necesario proveer en forma de soporte magnético 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. \layout Enumerate La utilización de un disco duro para hacer una copia cruda requiere una inversión considerable, teniendo en cuenta que su precio (aunque cada vez menor) es bastante alto. \layout Enumerate Los discos duros están expuestos a la pérdida de datos en caso de avería. Incluso, al ser un soporte magnético, pueden ser afectados por campos eléctrico s o magnéticos del medio ambiente. \end_deeper \end_deeper \layout Enumerate 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. \begin_deeper \layout Itemize Ventajas (con respecto a la clonación de discos duros): \begin_deeper \layout Enumerate No se requiere inversión en la compra de hardware extra. \layout Enumerate No se requiere la gestión del almacenamiento del hardware extra, ya que la copia de seguridad está siempre disponible en el ordenador. \end_deeper \layout Itemize Inconvenientes (con respecto a la clonación de discos duros): \begin_deeper \layout Enumerate Al estar disponible la partición de resguardo para el sistema operativo en todo momento, cabe la posibilidad de que los mismos procesos que provocan la necesidad de regenerarlo dañen la propia copia de seguridad. \layout Enumerate 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 sistema 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. \end_deeper \end_deeper \layout Enumerate \pagebreak_top Clonación de particiones de disco duro a disco(s) ópticos: \begin_deeper \layout Itemize Ventajas (con respecto a la clonación de discos duros): \begin_deeper \layout Enumerate Realizar la copia a un soporte óptico (CDROM o DVDROM) puede resultar mucho más barato en costes. \layout Enumerate Puede ser bastante más duradero en el tiempo. \end_deeper \layout Itemize Inconvenientes (con respecto a la clonación de discos duros): \begin_deeper \layout Enumerate Dado el tamaño actual de los discos duros y de la cantidad de software instalabl e 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. \layout Enumerate Este tipo de soportes son muy sensibles a los cambios de temperatura, lo que puede comprometer la fiabilidad del sistema de recuperación. \layout Enumerate 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. \layout Enumerate El proceso será sensiblemente más lento y complejo tanto a la hora de la ge\SpecialChar \- ne\SpecialChar \- ra\SpecialChar \- ción de la imagen como a la de la recuperación de la misma. \end_deeper \end_deeper \layout Enumerate Clonación de disco duro a disco de red: \begin_deeper \layout Itemize Ventajas (con respecto a la clonación de discos duros): \begin_deeper \layout Enumerate Si se tiene una buena infraestructura de red y una buena cantidad de disco libre, puede resultar un método más eficiente. \layout Enumerate 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. \layout Enumerate Este método es ampliable con facilidades que permitan gestionar la primera ins\SpecialChar \- ta\SpecialChar \- la\SpecialChar \- ción del sistema, lo que permitiría mejorar sensiblemente las prestacion es del proceso. \end_deeper \layout Itemize Inconvenientes (con respecto a la clonación de discos duros): \begin_deeper \layout Enumerate Si se pretenden gestionar muchos sistemas operativos diferentes, puede resultar 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). \layout Enumerate 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 ralentizará el proceso de regeneración. \layout Enumerate 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. \end_deeper \end_deeper \layout Section Procedimientos desatendidos \layout Standard Para que la regeneración o la instalación de un sistema operativo pueda no requerir la atención del usuario que pretende realizar la tarea, es necesario que el sistema sea capaz de autoconfigurarse. É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 proporcion arí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 mencionan 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 pro\SpecialChar \- ce\SpecialChar \- di\SpecialChar \- mien\SpecialChar \- tos 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. \layout Subsection Estado inicial \layout Standard 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 implementa ció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. \layout Standard 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). \layout Standard 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. \layout Standard Partamos, por tanto, de que el ordenador de tipo PC a regenerar está debidamente configurado para que la BIOS detecte las unidades de arranque configuradas para iniciar el sistema operativo 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. \layout Standard 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). \layout Standard 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. \layout Standard 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: \layout Itemize 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. \layout Itemize WOL, acrónimo de Wake On Lan, que permite iniciar un PC si recibe un paquete especialmente formado a través de la red a la que esté conectado. \layout Itemize 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. \layout Standard 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. \layout Subsection Fase de arranque \layout Standard \begin_inset LatexCommand \label{sub:Fase-de-arranque} \end_inset La siguiente tarea que es necesario realizar en un sistema de tipo PC es gestionar el arran\SpecialChar \- que o inicialización del mismo. Este proceso, es el que lleva al ordenador a cargar un sistema operativo en memoria, y por lo tanto el que inicializa los recursos disponibles del sistema (CPU, memoria, adaptadores, etc). Para hacerlo hay diferentes opciones a disposición del administrador. Las analizaremos para ver qué opciones nos ofrecen. \layout Enumerate \pagebreak_top Sistemas de arranque basados en soporte magnético y/o óptico: \begin_deeper \layout Standard 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. \layout Standard 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. \end_deeper \layout Enumerate Sistemas de arranque basados en memoria no volátil (NVRAM) \begin_deeper \layout Standard Son sistemas que utilizan un dispositivo hardware extra, normalmente diseñado expresamente 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. \layout Standard 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. \end_deeper \layout Enumerate Sistemas de arranque basados en servicios de red: \begin_deeper \layout Standard 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 protocolos de red expresamente diseñados para la configuración de sistemas y la descarga de datos, permite: \layout Enumerate Configurar el dispositivo de red y enviar a través del mismo una petición de información. \begin_deeper \layout Standard 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. \layout Standard Por lo tanto, esta petición se hace únicamente a nivel del protocolo de enlace, lo que obliga a que: \layout Itemize la subred disponga de un sistema capaz de dar una respuesta de forma local, o que \layout Itemize 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. \layout Standard 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. \end_deeper \layout Enumerate Extrayendo la información de la respuesta, configurar la parte de la pila de protocolos 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. \layout Enumerate 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. \begin_deeper \layout Standard 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\SpecialChar \- que, algunas de las cuales llevarían a la instalación o regeneración del sistema, mientras 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 arran\SpecialChar \- que por defecto que arranca el sistema de forma automática en caso de que se cumpla un tiempo de espera determinado. \layout Standard 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. \end_deeper \end_deeper \layout Subsection Fase de comprobación \layout Standard 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 desatendida. 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 pos\SpecialChar \- te\SpecialChar \- rio\SpecialChar \- res. \layout Subsection Fase de instalación automática o regeneración cruda \layout Standard Normalmente se basa en la ejecución de forma automática de un programa específic amente 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 \begin_inset LatexCommand \ref{sub:Instalación-automática} \end_inset y en la sección \begin_inset LatexCommand \ref{sec:Regeneración-cruda} \end_inset . \layout Subsection Fase de rearranque \layout Standard 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 regenerac ió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. \layout Subsection Fase de finalización \layout Standard En esta fase, se configuran los servicios y se realizan las actualizaciones del sistema operativo. Una vez hecho esto, se comprueba el funcionamiento del sistema y se da por terminado el proceso de regeneración. \layout Subsection Estado final \layout Standard 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 rege\SpecialChar \- ne\SpecialChar \- rado 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. \layout Chapter Arquitectura \layout Comment máquina maestra (de administración) que guia el proceso de instalación y configuración, todo lo demás es regenerable a partir de ella. Lo demás son servidores y nodos o máquinas clientes que son iguales entre sí. Así podremos generar granjas de servidores, cibercafés, laboratorios de programación, aulas de videoconferencia, etc. ¿qué tiene que tener? distribuciones, mecanismo de distribución, mecanismo de actualización ¿qué tipo de ordenadores hay? dos tipos: servidores y clientes. ¿Cómo arrancan? DHCP, con varios servidores, con configuraciones personalizadas , con ... \layout Section Gestión de red local (nivel de enlace) \layout Comment Tipo de Red (ip, fast-ethernet, switches y VLANes). Gestión de cableado \layout Standard 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. \layout Standard 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. \layout Standard Todos los servidores están conectados entre sí como mínimo a 100Mbps en un sólo conmutador 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). \layout Standard Para poder aislar grupos de ordenadores del laboratorio con el fin de hacer ciertas prácticas 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 \begin_inset LatexCommand \cite{VLAN} \end_inset (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. \layout Standard 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 conmutado r ethernet para que repita en uno de sus puertos todo lo que reciba del puerto conflictivo. \layout Section \begin_inset LatexCommand \label{sec:Gestión-de-red} \end_inset Gestión de red de acceso (nivel de red) \layout Comment Red pública. Red privada. Firewalling (proxy, filtrado). \layout Standard 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. \layout Standard 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). \layout Standard 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. \layout Standard A su vez, la red más externa está conectada a Internet a través de un cortafuego s. 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. \layout Standard Todos los servidores mencionados están basados en sistemas GNU/Linux RedHat 7.3. El proxy está configurado mediante Squid \begin_inset LatexCommand \cite{squid} \end_inset , mientras que la administración del cortafuegos se realiza con el sistema Iptables \begin_inset LatexCommand \cite{iptables} \end_inset y Fwbuilder \begin_inset LatexCommand \cite{fwbuilder} \end_inset . \layout Section Gestión de equipos \layout Comment Tipos de ordenador soportados, tipos de tarjetas de red, garantías de reparación , recambios \layout Standard Para la realización de este proyecto no sólo es necesario crear buenos procedimi entos de automatización de las configuraciones e integrarlos entre sí para permitir el máximo rendimiento (como iremos contando en este capítulo), sino que también juegan un papel importante las ca\SpecialChar \- racterísticas de las máquinas que se pretenden administrar. De este modo, será fundamental (para evitar tener que hacer trabajos extra) que los ordenadores cliente del sistema de administración centralizada sean máquinas compatibles con el estándar PXE \begin_inset LatexCommand \cite{PXE} \end_inset . Hoy en día la práctica tota\SpecialChar \- li\SpecialChar \- dad 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). \layout Standard 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. \layout Standard 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. \layout Standard 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. \layout Standard 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. \layout Standard Por todo esto, será necesario tener personal preparado para ser capaz de configurar adecuadamente 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 mismo. \layout Section \begin_inset LatexCommand \label{sec:Gestión-de-arranque} \end_inset Gestión de arranque de red \layout Standard 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 ordenador. \layout Standard 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. \layout Standard 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. \layout Standard Actualmente, en los laboratorios docentes del DIT se utilizan 6 servidores de arranque. Están configurados para servir DHCP \begin_inset LatexCommand \cite{DHCP} \end_inset mediante el software de ISC \begin_inset LatexCommand \cite{ISC} \end_inset 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 \begin_inset LatexCommand \cite{TFTP} \end_inset 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ápidament e 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. \layout Standard 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 \begin_inset LatexCommand \cite{sed} \end_inset ), gestionándose todo el conjunto con la herramienta make \begin_inset LatexCommand \cite{make} \end_inset . \layout Standard 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 \begin_inset LatexCommand \cite{rdist} \end_inset . Aunque se podría haber utilizado para este caso rsync \begin_inset LatexCommand \cite{rsync} \end_inset , rdist resulta más útil puesto que permite ejecutar en el servidor remoto (al que se ha distribuído el árbol) un script \begin_inset Foot collapsed false \layout Standard script: conjunto de comandos agrupados en un fichero y ejecutados de forma secuencial \end_inset de configuración, que por ejemplo reiniciaría el servidor TFTP. \layout Standard La imagen de inicio que el ordenador cliente descarga por TFTP, para nuestra configuración particular, puede ser la proviniente de dos sistemas software de arranque de los que hemos comentado algo previamente: GRUB \begin_inset LatexCommand \cite{GRUB} \end_inset o Pxelinux \begin_inset LatexCommand \cite{Pxelinux} \end_inset . 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 drivers \begin_inset Foot collapsed false \layout Standard driver: código específico que gestiona un dispositivo de un sistema \end_inset hereda de otro proyecto (Etherboot \begin_inset LatexCommand \cite{Etherboot} \end_inset ). 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. \layout Standard 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 implementar 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. \layout Section Gestión de disco local \layout Standard Dada la necesidad de múltiples sistemas operativos en los ordenadores cliente de los labo\SpecialChar \- ratorios docentes del DIT (Windows XP y GNU/Linux), hemos tenido que permitir en los ordenadores 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. \layout Standard 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 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. \layout Standard Si vamos a la gestión física del disco duro del sistema, ésta se compone de 3 fases: particionado, 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 adoptado 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 \begin_inset LatexCommand \cite{fdisk} \end_inset para particionar los discos de forma automática, \family typewriter mke2fs \family default para formatear las particiones de GNU/Linux (ext2 y ext3) y \family typewriter partimage \family default \begin_inset LatexCommand \cite{partimage} \end_inset para regenerar tanto el formato como los datos de las particiones de Windows XP (NTFS). \layout Section \begin_inset LatexCommand \label{sec:Gestión-de-instalaciones} \end_inset Gestión de instalaciones \layout Standard 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. \layout Standard Para independizar las funciones y aumentar el rendimiento, se han creado tres niveles jerár\SpecialChar \- qui\SpecialChar \- cos diferentes: \layout Itemize 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. \layout Itemize Servidor secundario o esclavo de administración centralizada (intermediario entre el sistema 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 servicios comunes. \layout Itemize 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. \layout Standard El sistema está pensado para poder gestionar tanto instalaciones como regeneraci ones, según resulte más conveniente. \layout Standard \begin_inset Float figure placement H wide false collapsed false \layout Standard \align center \begin_inset Graphics filename ../Proyecto_Omar_figuras/jerarquia.gif width 100cm height 7cm keepAspectRatio \end_inset \layout Caption Esquema de la jerarquía de servidores \end_inset \layout Standard 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 conseguir 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. \layout Subsection \begin_inset LatexCommand \label{sub:Instalación-servidores-linux} \end_inset Instalación automática de servidores GNU/Linux \layout Standard Para realizar la tarea de instalar de forma desatendida un servidor GNU/Linux es muy conveniente basarse en la utilización de las herramientas de autoinstala ció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 resulta 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. \layout Standard 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 utilizados por los autoinstaladore s y para configurar y añadir aplicaciones (ajenas o no a la propia distribución). \layout Standard Los servidores RedHat GNU/Linux instalados, usan la versión 7.3 de la distribució n RedHat Linux y, por tanto, las herramientas creadas están particularizadas para este sistema ope\SpecialChar \- rativo, aunque se prevé la generalización de las mismas para otras distribuciones también de GNU/Linux. \layout Standard 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. \layout Standard 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 fichero \family typewriter comps \family default que aparece bajo el directorio \family typewriter /RedHat/base \family default 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. \layout Standard Aunque el proceso de instalación habitual utiliza un disquete o CD para gestionar el arran\SpecialChar \- 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. \layout Standard 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. \layout Standard El arranque de las máquinas se hará según se describe en la sección \begin_inset LatexCommand \ref{sec:Gestión-de-arranque} \end_inset , pasando como parámetro al núcleo de Linux ( \family typewriter vmlinuz \family default ) el tipo de instalación y la localización en la red del fichero de configuració n de la instalación desatendida ( \family typewriter ks=nfs:\SpecialChar \- AC_IP_DEL_SERVIDOR:\SpecialChar \- /kickstart/\SpecialChar \- ks.cfg \family default , donde habría que sustituir \family typewriter AC_IP_DEL_SERVIDOR \family default por la dirección IP física del servidor que contiene el archivo \family typewriter ks.cfg \family default ). \layout Standard Mediante Kickstart también es posible configurar la ejecución de tareas en la fase inmedia\SpecialChar \- tamente anterior y posterior a la fase de instalación, lo que proporciona ciertas facilidades de configuración fuera de las estrictame nte contempladas (como por ejemplo, el enviar un correo al administrador). \layout Standard Dada la cantidad de factores modificadores, la tarea de generación del fichero de configuració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. También será necesario crear ciertas infraestructuras que puedan ser utilizadas para el resto de los servicios de administración. \layout Standard Se enumeran a continuación las tareas más importantes a desarrollar por el sistema de administración centralizada, dentro de las que implican la instalación automática y desatendida de nuevos servidores GNU/Linux: \layout Itemize 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, proporciona ndo al sistema de administración una visión completa de los parámetros necesario s en el proceso de instalación. \layout Itemize Generación automática del fichero de configuración de Kickstart ( \family typewriter ks.cfg \family default ) para cada servidor, a partir del perfil almacenado en la base de datos de administración. Para ello\SpecialChar \- , se ha diseñado una herramienta que hemos llamado \family typewriter mkdist \family default . \layout Itemize 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 realiza \family typewriter mkdist \family default . \layout Itemize Gestión automática de los servidores DHCP y DNS, modificando su configuración cuando 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 llamado \family typewriter install.hosts \family default . \layout Itemize 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. \layout Itemize Gestión automática de las claves SSH, para evitar que se pida la intervención del admi\SpecialChar \- 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 script \family typewriter ssh-keyscan \family default . \layout Itemize Configuración del software instalado, instalación de aplicaciones no estándar, actuali\SpecialChar \- zación automática del software y realización de otras tareas automatizab les. Para ello, hemos desarrollado la herramienta \family typewriter autoactualiza \family default . \layout Itemize 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: \family typewriter labadmin \family default y \family typewriter mkcuentas \family default . \layout Standard Los detalles de implementación de la solución adoptada para manejar la problemát ica de esta sección, se detallan en el punto \begin_inset LatexCommand \ref{sub:implem-instalación-linux} \end_inset . \layout Subsection Instalación automática de clientes GNU/Linux \layout Standard 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 \begin_inset LatexCommand \ref{sub:Instalación-servidores-linux} \end_inset . Por motivos de rendimiento 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\SpecialChar \- ta\SpecialChar \- la\SpecialChar \- ció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. \layout Standard 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. \layout Standard Los detalles de implementación de la solución adoptada para manejar la problemát ica de esta sección, se detallan en el punto \begin_inset LatexCommand \ref{sub:implem-instalación-clientes-linux} \end_inset . \layout Subsection \begin_inset LatexCommand \label{sec:Gestión-de-regeneraciones} \end_inset Regeneración automática de clientes Windows XP \layout Standard 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 (diferenciando 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. \layout Standard 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 gestionarlos todos con sólo dos imágenes diferentes. Si esto no fuese así, la tarea de administración de este tipo de regeneraciones podría llegar a ser demasiado costosa. \layout Standard 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, \family typewriter partimage \family default \begin_inset LatexCommand \cite{partimage} \end_inset . \layout Standard 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. \layout Standard Los detalles de implementación se facilitan en la sección \begin_inset LatexCommand \ref{sub:implem-regeneración-XP} \end_inset . \layout Subsection Instalación automática de clientes Windows XP \layout Standard 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 \begin_inset LatexCommand \cite{Microsoft} \end_inset ), para la instalación desa\SpecialChar \- ten\SpecialChar \- dida de las estaciones. Aunque hay varios documentos ( \begin_inset LatexCommand \cite{MS-Zero,MS-NetworkPC} \end_inset ) 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 corporativ as, 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. \layout Standard 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, principalmente) 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 postinstalación se generan los usuarios y se instalan las aplicaciones extra (no incluidas con el sistema operativo). \layout Standard Los detalles sobre la implementación de este proceso para el sistema de administración centralizada se pueden consultar en la sección \begin_inset LatexCommand \ref{sub:implem-instalación-XP} \end_inset y también a través de la documentación proporcionada por Pedro J. Pérez \begin_inset LatexCommand \cite{pjpg-autoinst} \end_inset y por Karl Bernard \begin_inset LatexCommand \cite{unattended-install} \end_inset . Sobre la generación de instalaciones de aplicaciones automatizables para Windows hay más información en las páginas de Autoit \begin_inset LatexCommand \cite{Autoit} \end_inset y WinstallLE \begin_inset LatexCommand \cite{winstallle} \end_inset de Veritas, así como en Microsoft \begin_inset LatexCommand \cite{Microsoft} \end_inset . \layout Section Gestión de servicios generales \layout Standard En esta sección, se pretenden agrupar aquellos servicios que son de carácter general y suelen 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 ofrecen 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. \layout Subsection \begin_inset LatexCommand \label{sec:Gestión-de-usuarios} \end_inset Gestión de usuarios \layout Standard 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 administr ación, que es quien se encarga de distribuir las configuraciones adecuadas a cada servidor. \layout Standard En el sistema de gestión de usuarios hay varios aspectos importantes implicados. A saber: \layout Itemize gestión de nombres de usuario, \layout Itemize gestión de grupos de usuarios, \layout Itemize gestión de números de identificación de usuarios y grupos, \layout Itemize gestión de cuotas de disco, \layout Itemize gestión de la configuración de usuarios de correo electrónico (aliases), \layout Itemize gestión de permisos de acceso de usuarios y grupos, \layout Itemize gestión de claves de acceso (Unix y Samba), \layout Itemize distribución de las cuentas a los servidores de configuración y \layout Itemize exportación de disco de red para los usuarios en los servidores de disco de red. \layout Standard Para la realización de todas estas tareas se han realizado varias aplicaciones que trabajan en conjunto. Los nombres que les hemos dado son: \family typewriter labadmin \family default , \family typewriter mkcuentas \family default y \family typewriter mkcuota \family default . \layout Standard 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 llamado \family typewriter cron \family default en los sistemas GNU/Linux, que no es más que un gestor de tareas a partir de patrones temporales (scheduler). \layout Subsection Gestión de impresoras \layout Standard 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. \layout Standard Este problema tiene dos consecuencias fundamentales: 1) no es posible generar los trabajos 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 ta\SpecialChar \- reas, 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). \layout Standard 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. \layout Standard 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. \layout Standard Dadas todas estas circunstancias, hay varias formas de acometer la problemática: \layout Enumerate 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. \layout Enumerate Utilizar las herramientas disponibles para GNU/Linux y realizar un control laxo de las impresoras. Es un ejemplo de este tipo la utilidad \family typewriter printquota \family default \begin_inset LatexCommand \cite{printquota} \end_inset . \layout Enumerate 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. \layout Enumerate 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 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. \layout Standard Después de probar todas las opciones, y a pesar de todos los esfuerzos, la opción aplicada finalmente 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 soporte 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. \layout Subsection Gestión de sistema de nombres \layout Standard En nuestro diseño, en lo relativo al DNS se ha contemplado la existencia de un servidor secundario 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. \layout Standard 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ón \family typewriter bind \family default de ISC \begin_inset LatexCommand \cite{ISC} \end_inset 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 laborator io, dada su posición estratégica en la red. \layout Standard 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 ( \family typewriter /etc/hosts \family default ). \layout Subsection Gestión de correo electrónico \layout Standard 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. \layout Standard 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. Estas tareas son realizadas por un conjunto de scripts de distribución y gestión situados en el directorio \family typewriter cuentas \family default del usuario operador en el servidor central de administración. \layout Standard 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. \layout Subsection Gestión de web \layout Standard 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. \layout Standard 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 nombre \family typewriter passwd.html \family default y \family typewriter comprueba.cgi \family default y están preparados para facilitarles la nueva información a los scripts que se ocupan de las tareas de gestión de usuarios. \layout Subsection Gestión de disco de red \layout Standard 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 configurado 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 aislamiento seguro de las prácticas entre los alumnos. \layout Standard 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 de \family typewriter ckquota \family default . \layout Standard También hemos decidido incluir en el sistema de cuotas el directorio en el que se almacena el correo del usuario ( \family typewriter /var/spool/mail \family default ) para así gestionar de forma conjunta el disco total utilizado 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). \layout Subsection Gestión de dispositivos especiales \layout Standard 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 hardware 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 \family typewriter sudo \family default \begin_inset LatexCommand \cite{sudo} \end_inset , mientras que en Windows tienen que utilizar una cuenta de administrador local para poder configurar el hardware. \layout Subsection Gestión de reserva de equipos \layout Standard En un entorno compartido en el que conviven muchas asignaturas prácticas resulta extremadamente 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. \layout Standard Este servicio ha sido desarrollado a partir de un proyecto \begin_inset LatexCommand \cite{reservas} \end_inset rea\SpecialChar \- lizado en el marco de estos laboratorios en Diciembre de 2000. Las mejoras introducidas han permitido gestionar las reservas 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. \layout Subsection Gestión de actualizaciones \layout Standard Las actualizaciones de los servidores GNU/Linux se basan en la instalación de los paquetes de actualización mediante \family typewriter autoupdate \family default \begin_inset LatexCommand \cite{autoupdate} \end_inset , 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 ( \family typewriter root.tgz \family default ) o cuando se utilizan las aplicaciones y librerías actualizados desde el servidor a través de NFS. \layout Standard 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 \family typewriter partimage \family default . 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 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. \layout Subsection Gestión de copias de seguridad. Plan de contingencia. \layout Standard 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 contingenc ia, es decir, en definir una serie de procedimientos que permitan recuperar la información del sistema completo en diferentes supuestos, a saber: \layout Enumerate En caso de fallo de un equipo terminal o cliente. \layout Enumerate En caso de fallo de un servidor secundario. \layout Enumerate En caso de fallo del servidor principal. \layout Enumerate En caso de pérdida de archivos individuales de usuario. \layout Standard Tal y como se ha comentado anteriormente y se profundizará en el capítulo \begin_inset LatexCommand \ref{cha:Implementación} \end_inset , 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. \layout Standard También se ha contemplado la posibilidad de generar imágenes de reinstalación del servidor principal tanto a disco óptico de arranque (herramienta \family typewriter hazcd \family default ) como a fichero (herramienta \family typewriter mkmaestro \family default ). A partir de estas imágenes, se puede recuperar el sistema de gestión centraliza da 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. \layout Standard 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 backups \begin_inset Foot collapsed true \layout Standard backup: palabra inglesa que se utiliza en informática para referirse a la salvaguarda de datos \end_inset . \layout Standard 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 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. \layout Standard 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 backups 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). \layout Standard 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 queramos utilizar y de la cantidad de disco duro para backups de que dispongamos podremos tener más o menos días de salvaguarda. \layout Standard Los programas utilizados para realizar los backups completos en el laboratorio ha sido \family typewriter dump \family default , mientras que para la realización de los incrementales utilizamos \family typewriter tar \family default . 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). \layout Subsection Gestión de las caídas de tensión \layout Standard 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, inconsistenci a 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. \layout Standard Este equipo es lo que llamamos un SAI (sistema de alimentación ininterrumpida). Normalmente 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 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. \layout Subsection Gestión de estadísticas \layout Standard Es fundamental para comprobar y planificar el uso de los recursos del laboratori o. 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 con \family typewriter analog \family default , un programa especializado en contabilizar los accesos a servidores web, que se puede adaptar para realizar la tarea. \layout Standard Mediante este método, se extraen las siguientes estadísticas: \layout Itemize Porcentaje de ocupación en el período \layout Itemize Valores max/min/avg de logines y usuarios en el período \layout Itemize Relación usuarios/turnos en el período \layout Itemize Relación logins/usuarios/turno en el período especificado \layout Itemize Número de usuarios y puestos ocupados durante el período \layout Itemize Usuarios que más utilizan el laboratorio \layout Itemize Turnos más utilizados \layout Itemize Puestos más utilizados \layout Itemize Método de login más utilizado \layout Itemize Número de logins/usuarios en función de la asignatura \layout Itemize Número de logins/usuarios contabilizados \layout Itemize Número de entradas de root \layout Itemize Listado detallado de entradas de root \layout Subsection Chequeo automático de servicios \layout Standard Para comprobar el funcionamiento de los servicios de forma periódica es conveniente rea\SpecialChar \- 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 llamado \family typewriter lab_servers_info \family default , que me\SpecialChar \- dian\SpecialChar \- te la herramienta \family typewriter nmap \family default \begin_inset LatexCommand \cite{nmap} \end_inset 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 administra dor de que el sistema esté funcionando co\SpecialChar \- rrec\SpecialChar \- ta\SpecialChar \- men\SpecialChar \- te. Para comprobar la carga del servidor, y la cantidad de disco utilizado y disponible, se realiza un comando remoto con \family typewriter ssh \family default . \layout Standard Según va recibiendo los resultados, el programa los analiza, estableciendo niveles de alarma 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. \layout Standard 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 di\SpecialChar \- fe\SpecialChar \- ren\SpecialChar \- tes 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. \layout Chapter \begin_inset LatexCommand \label{cha:Implementación} \end_inset Implementación \layout Section Infraestructura de comunicaciones \layout Standard En este apartado se pretende ofrecer una visión general sobre las infraestructur as 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. \layout Subsection Nivel físico \layout Standard Los laboratorios docentes del DIT tienen dos características diferenciales que le han condicionado 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). \layout Standard \begin_inset Float figure placement H wide false collapsed false \layout Standard \align center \begin_inset Graphics filename ../Proyecto_Omar_figuras/PICT0967b.GIF lyxscale 50 height 5cm keepAspectRatio \end_inset \layout Caption Vista del laboratorio A.127-2 \end_inset \layout Standard 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 convivir 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 compatibilidad (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). \layout Standard 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). \layout Standard \begin_inset Float figure placement H wide false collapsed false \layout Standard \align center \begin_inset Graphics filename ../Proyecto_Omar_figuras/PICT0016b.GIF lyxscale 50 height 5cm keepAspectRatio \end_inset \layout Caption Vista del laboratorio B.123 \end_inset \layout Standard 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 inde\SpecialChar \- pen\SpecialChar \- dien\SpecialChar \- te\SpecialChar \- mente 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 \begin_inset LatexCommand \ref{cap:LRyST2002} \end_inset se muestra la estructura general de este laboratorio. \layout Standard \begin_inset Float figure placement th wide false collapsed false \layout Standard \align center \begin_inset Graphics filename ../Proyecto_Omar_figuras/LRST2002-2.gif scale 55 keepAspectRatio \end_inset \layout Caption \begin_inset LatexCommand \label{cap:LRyST2002} \end_inset Mapa de red del laboratorio de Redes y Servicios Telemáticos (curso 01-02) \end_inset \layout Standard Hay que mencionar también que debido a las características especiales de la instalación eléctrica de los diferentes edificios en los que se tienen aulas de laboratorio (por estar suministrados por compañías eléctricas diferentes), es necesario interconectarlos mediante fibra óptica, tal y como se indicará en la sección \begin_inset LatexCommand \ref{sub:Nivel-de-enlace} \end_inset . 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 panels \begin_inset Foot collapsed false \layout Standard patch panel: distribuidor intermedio que permite independizar el cableado vertical del horizontal \end_inset 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ísticas del cableado sino también el disponer de personal capacitado para realizar las tareas de administración, configuración, pruebas y mantenimie nto del mismo. \layout Subsection \begin_inset LatexCommand \label{sub:Nivel-de-enlace} \end_inset Nivel de enlace \layout Standard El nivel de enlace se ha construido mediante el despliegue de una red Ethernet interconectada 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 necesidad es de comunicación de todos los servicios desplegados de forma simultánea. La 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 monomodo, fibra óptica multimodo y par trenzado no apantallado) y con capacidad de gestión de redes virtuales de área local. \layout Standard 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 \begin_inset LatexCommand \cite{VLAN} \end_inset ) 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. \layout Standard 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 \begin_inset Quotes sld \end_inset multihoming \begin_inset Quotes srd \end_inset , 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. \layout Standard \begin_inset Float figure placement H wide false collapsed false \layout Standard \align center \begin_inset Graphics filename ../Proyecto_Omar_figuras/nivel-enlace-2003.gif height 10cm keepAspectRatio \end_inset \layout Caption \begin_inset LatexCommand \label{cap:Mapa-de-Conmutadores} \end_inset Mapa de Conmutadores Ethernet del Laboratorio \end_inset \layout Standard Como se ve en la figura \begin_inset LatexCommand \ref{cap:Mapa-de-Conmutadores} \end_inset 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 mediante 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). \layout Standard \begin_inset Float figure placement H wide false collapsed false \layout Standard \align center \begin_inset Graphics filename ../Proyecto_Omar_figuras/PICT0956.gif lyxscale 40 height 5cm keepAspectRatio \end_inset \layout Caption Imagen del rack de distribución de cableado y equipamiento en el aula A.127-2 \end_inset \layout Subsection Nivel de red \layout Standard 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. \layout Standard \begin_inset Float figure placement th wide false collapsed false \layout Standard \align center \begin_inset Graphics filename ../Proyecto_Omar_figuras/dibujo-red-2.gif height 10cm keepAspectRatio \end_inset \layout Caption \begin_inset LatexCommand \label{cap:Mapa-general-red} \end_inset Mapa general de la infraestructura de red del laboratorio \end_inset \layout Standard Como se puede observar en la figura \begin_inset LatexCommand \ref{cap:Mapa-general-red} \end_inset , la red interna (LABnet) es la red del laboratorio donde están situados: \layout Itemize La máquina \series bold cuentas \series default (servidor de disco, de impresoras, gestor de cuotas y servidor principal de correo electrónico), \layout Itemize Los múltiples \series bold binarios \series default (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. \layout Itemize Los \series bold servidores específicos \series default de asignaturas del laboratorio, como orion, lubina, rape o dorada que tienen software y/o hardware especialmente configurado. \layout Itemize Los \series bold clientes \series default del 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 \begin_inset Quotes sld \end_inset l \begin_inset Quotes srd \end_inset seguida del número de ordenador, que a su vez coincide con el último campo de la dirección IP que se le asigna. \layout Itemize Las \series bold impresoras \series default , que están distribuidas por cada aula del laboratorio y es en ellas donde los alumnos pueden imprimir sus resultados y memorias. \layout Itemize El \series bold router \series default 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). \layout Standard \begin_inset Float figure placement th wide false collapsed false \layout Standard \align center \begin_inset Graphics filename ../Proyecto_Omar_figuras/PICT0013b.GIF lyxscale 40 height 6cm keepAspectRatio \end_inset \layout Caption Imagen del rack de servidores del laboratorio en el CDC \end_inset \layout Standard En ADMnet se han situado los servidores públicos del laboratorio, que gestionan los servicios que el laboratorio ofrece a través de Internet, como son el web, el correo electrónico, el DNS, etc. En la figura \begin_inset LatexCommand \ref{cap:Mapa-general-red} \end_inset se puede ver que en ella están: \layout Itemize El servidor \series bold maestro \series default , 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\SpecialChar \- ner acceso a otros servidores del DIT a los que llega a través de la máquina firewall (y para ello ha de te\SpecialChar \- ner ruta hacia Internet). \layout Itemize El servidor de web ( \series bold www \series default ) 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. \layout Itemize El \series bold firewall \series default , 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. \layout Itemize La máquina \series bold besugo \series default , que se utiliza para permitir la gestión remota de los servidores Windows que hay en el interior del laboratorio (mediante las facilidades de Terminal Server). \layout Standard 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 comunicacion es, 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 \begin_inset LatexCommand \ref{cap:LRyST2002} \end_inset y \begin_inset LatexCommand \ref{cap:Rack-de-b123} \end_inset . \layout Standard \begin_inset Float figure placement th wide false collapsed false \layout Standard \align center \begin_inset Graphics filename ../Proyecto_Omar_figuras/rack-b123.gif height 8cm keepAspectRatio \end_inset \layout Caption \begin_inset LatexCommand \label{cap:Rack-de-b123} \end_inset Rack de equipos de comunicaciones en el aula B.123 \end_inset \layout Section Sistema de administración centralizada \layout Standard 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 sostenibl e. 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. \layout Standard 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. \layout Subsection \begin_inset LatexCommand \label{sub:Jerarquía-de-servidores} \end_inset La jerarquía de servidores \layout Standard Como se ha comentado anteriormente (sección \begin_inset LatexCommand \ref{sec:Gestión-de-instalaciones} \end_inset ), el sistema de administración centra\SpecialChar \- lizada está dividido jerárquicamente en tres niveles, siendo el nivel superior (servidor principal o maestro) el que implementa el sistema de administración cen\SpecialChar \- tra\SpecialChar \- li\SpecialChar \- zada 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. \layout Standard \begin_inset Float figure wide false collapsed false \layout Standard \align center \begin_inset Graphics filename ../Proyecto_Omar_figuras/jerarq-servicios.gif lyxscale 80 width 100cm height 8cm keepAspectRatio \end_inset \layout Caption Esquema de la distribución jerárquica servicios para las instalaciones \end_inset \layout Subsubsection Servidor principal \layout Standard 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 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. \layout Standard Los servidores que se ejecutan en maestro son: \layout Itemize DHCP (para configurar las tarjetas de red de los servidores que administra) \layout Itemize TFTP (para enviarles los menús y archivos de arranque) \layout Itemize NFS (para exportar los archivos de instalación de GNU/Linux) \layout Itemize NETBEUI (para exportar los archivos de instalación a los servidores Windows XP) \layout Itemize HTTPS (para gestionar el cambio de claves de los usuarios) \layout Standard 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. \layout Subsubsection Servidores secundarios \layout Standard 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: \layout Itemize Servicio de DHCP (para la configuración remota de las tarjetas de red de los clientes) \layout Itemize 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) \layout Itemize 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). \layout Itemize 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). \layout Standard 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. \layout Standard Tanto los binarios como el resto de los servidores secundarios son máquinas que el ad\SpecialChar \- mi\SpecialChar \- nis\SpecialChar \- tra\SpecialChar \- dor no ha de gestionar manualmente, puesto que esa labor la realiza el sistema de administración centralizada implementado. Así, por ejemplo mediante éste se programa el servicio de \family typewriter cron \family default para realizar las actualizaciones automáticamente o para reiniciar el sistema de forma pe\SpecialChar \- rió\SpecialChar \- di\SpecialChar \- ca. También está programado el rotado de los ficheros de registro para evitar una utilización excesiva del disco duro. \layout Standard 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: \layout Itemize Gran cantidad de memoria RAM, para no tener que realizar consultas al disco duro con demasiada frecuencia \layout Itemize Buena conexión de red. El full-duplex y un ancho de banda igual o superior a 100 Mbps son imprescindib les. \layout Itemize Procesador suficientemente rápido, ya que esto agiliza mucho la gestión de disco y la transmisión de archivos en la arquitectura PC. \layout Itemize Discos duros de gran ancho de banda, con memoria caché (cuanta más, mejor) y de bajo tiempo medio de acceso. \layout Itemize 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). \layout Subsubsection Clientes \layout Standard Son los ordenadores finales del laboratorio y por tanto los que dan servicio de forma directa 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: \layout Itemize Cargar GNU/Linux \layout Itemize Cargar XP \layout Itemize Regenerar XP \layout Standard 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. \layout Standard En el caso de la carga Linux, se hace la reinstalación cada vez que el usuario quiere utilizarlo, 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á concebido 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. \layout Standard 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. \layout Standard 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. \layout Subsection \begin_inset LatexCommand \label{sub:implem-instalación-linux} \end_inset Sistema de instalación automática de servidores GNU/Linux \layout Standard El sistema de administración centralizada consiste en un conjunto de utilidades que gestionan 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 administrador o como operador (dado que ambos roles tienen funciones diferentes). \layout Subsubsection Modelos y patrones de estación \layout Standard 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. \layout Standard Llamamos modelo a una lista ordenada de patrones, siendo los patrones un conjunto concreto 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. \layout Standard 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. \layout Standard 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. \layout Standard 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 directorio \family typewriter etc \family default (por ejemplo el \family typewriter /etc/resolv.conf \family default ), el directorio del patrón tendrá un subdirectorio llamado \family typewriter etc \family default y, dentro, el fichero que se quiere configurar ( \family typewriter resolv.conf \family default ). \layout Standard \begin_inset Float figure placement H wide false collapsed true \layout Standard \align center \begin_inset Tabular \begin_inset Text \layout Standard \family typewriter search dit.upm.es lab.dit.upm.es \end_inset \begin_inset Text \layout Standard \family typewriter nameserver 138.4.26.2 \end_inset \end_inset \layout Caption Ejemplo del fichero estándar \family typewriter /etc/resolv.conf \end_inset \layout Standard 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 configura ción a partir de la información contenida en la base de datos. \layout Standard Los patrones están pensados de tal forma que actúan como una transparencia sobre el sistema 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, prevaleciendo 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 partido a la configuración de cada modelo de estación. \layout Subsubsection Transformación de patrones \layout Standard Todas las estaciones de una red pueden clasificarse según su configuración. Esta característica es la que aprovecha el sistema de patrones, que permite catalogar en modelos de estación las diferentes configuraciones de un modo extensible. \layout Standard 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. \layout Standard Así, para el caso anterior de la configuración del servicio de nombres de una estación particular a través del fichero \family typewriter /etc/resolv.conf \family default , se podrían definir dos variables (o propiedades) \family typewriter AC_NAMESERVER \family default y \family typewriter AC_DNS_SEARCH \family default que serían sustituidas por los valores almacenados en la base de datos para esa estación en concreto (ver figura \begin_inset LatexCommand \ref{cap:patron-ejemplo} \end_inset ). Añadir el prefijo \family typewriter AC_ \family default 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. \layout Standard \begin_inset Float figure placement H wide false collapsed false \layout Standard \align center \begin_inset Tabular \begin_inset Text \layout Standard \family typewriter search AC_DNS_SEARCH \end_inset \begin_inset Text \layout Standard \family typewriter nameserver AC_NAMESERVER \end_inset \end_inset \layout Caption \begin_inset LatexCommand \label{cap:patron-ejemplo} \end_inset Ejemplo de un fichero ( \family typewriter /etc/resolv.conf \family default ) pertenciente a un patrón \end_inset \layout Standard Cuando se construye la configuración de una estación determinada, se sustituyen las varia\SpecialChar \- 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 \begin_inset LatexCommand \ref{cap:bdm-ejemplo} \end_inset ). Para realizar esta operación de transformación, se han desarrollado unos scripts basados en la utilidad m4 de GNU \begin_inset LatexCommand \cite{GNU} \end_inset , disponible para todas las distribuciones de GNU/Linux. m4 se invoca con dos parámetros principales: el archivo que contiene la definició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. \layout Standard \begin_inset Float figure placement H wide false collapsed false \layout Standard \align center \begin_inset Tabular \begin_inset Text \layout Standard \family typewriter define(`AC_DNS_SEARCH',`lab.dit.upm.es') \end_inset \begin_inset Text \layout Standard \family typewriter define(`AC_NAMESERVER',`138.4.26.2') \end_inset \end_inset \layout Caption \begin_inset LatexCommand \label{cap:bdm-ejemplo} \end_inset Fragmento del fichero \family typewriter bdm/net/admnet.m4 \family default de la base de datos, que contiene la definición de variables para DNS de una estación determinada \end_inset \layout Subsubsection Organización de la base de datos \layout Standard 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 \family typewriter bdm \family default (acrónimo de \begin_inset Quotes sld \end_inset base de datos de máquinas \begin_inset Quotes srd \end_inset ). \layout Standard Por ejemplo, si el componente es la tarjeta VGA, habrá diferentes ficheros con las definiciones de variables para las diferentes tarjetas de ese tipo. Así, tendremos un fichero \family typewriter ati.m4 \family default para las definiciones de variable correspondientes a la tarjeta de video ATI, y otro llamado \family typewriter s3.m4 \family default para las definiciones de variable correspondientes a la tarjeta de vídeo S3. Ambos archivos estarán bajo el subdirectorio \family typewriter vga \family default del directorio \family typewriter bdm \family default . \layout Standard \begin_inset Float figure placement th wide false collapsed false \layout Standard \align center \begin_inset Graphics filename ../Proyecto_Omar_figuras/bdm2.gif height 7cm keepAspectRatio \end_inset \layout Caption Esquema de directorios de la base de datos de máquinas (bdm) \end_inset \layout Standard 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\SpecialChar \- dian\SpecialChar \- te 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. \layout Standard 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 \begin_inset LatexCommand \ref{cap:bdm-ejemplo} \end_inset , que quedaría tal y como se muestra en la figura \begin_inset LatexCommand \ref{cap:Ejemplo-de-perfil} \end_inset . \layout Standard \begin_inset Float figure wide false collapsed false \layout Standard \align center \begin_inset Tabular \begin_inset Text \layout Standard \family typewriter include(bdm/net/admnet.m4) \end_inset \begin_inset Text \layout Standard \family typewriter include(bdm/vga/ati.m4) \end_inset \begin_inset Text \layout Standard \family typewriter [...] \end_inset \end_inset \layout Caption \begin_inset LatexCommand \label{cap:Ejemplo-de-perfil} \end_inset Ejemplo del perfil de una estación para la base de datos ( \family typewriter bdm/nombremaq.m4 \family default ) \end_inset \layout Standard 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. \layout Standard 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). \layout Standard 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. \layout Standard 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 equivocacion es 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. \layout Standard \begin_inset Float figure placement th wide false collapsed false \layout Standard \align center \begin_inset Graphics filename ../Proyecto_Omar_figuras/redhat.gif width 100cm height 7cm keepAspectRatio \end_inset \layout Caption Esquema general de directorios del sistema de instalación para RedHat 7.3 \end_inset \layout Subsubsection Procedimiento de instalación desatendida \layout Standard La herramienta del sistema de administración centralizada que generará el \family typewriter ks.cfg \family default en función del perfil de cada máquina se llama \family typewriter mkdist \family default . A \family typewriter mkdist \family default se le pasa como parámetro el nombre del perfil de la máquina ( \family typewriter nombremaq.m4 \family default ) con el que se genera el archivo de instalación desatendida ( \family typewriter ks.cfg \family default ) 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 directorio \family typewriter distrib/\SpecialChar \- redhat-7.3/\SpecialChar \- maquinas/\SpecialChar \- nombremaq \family default y se transmitirá a la máquina para que, en un proceso posterior de configuració n ( \family typewriter autoactualiza \family default ), disponga localmente de los valores de todas sus variables AC. \layout Standard \begin_inset Float figure wide false collapsed false \layout Standard \align center \begin_inset Graphics filename ../Proyecto_Omar_figuras/inst-bin-linux1.gif lyxscale 80 width 100cm height 8cm keepAspectRatio \end_inset \layout Caption Esquema del procedimiento de instalación desatendida para servidores GNU/Linux en su primera fase \end_inset \layout Standard Tal y como se explicó en la sección \begin_inset LatexCommand \ref{sub:Instalación-servidores-linux} \end_inset , los servidores a instalar deberán estar configurados 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 ( \family typewriter install.hosts \family default ), para más detalles véase también el punto \begin_inset LatexCommand \ref{sub:Dar-de-alta-cli-y-serv} \end_inset . \layout Standard En la fase de postinstalación del sistema operativo, se configura la estación para que en su primer arranque ejecute la herramienta \family typewriter autoactualiza. \family default 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 del \family typewriter cron \family default 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). \layout Standard \begin_inset Float figure wide false collapsed false \layout Standard \align center \begin_inset Graphics filename ../Proyecto_Omar_figuras/inst-bin-linux2.gif lyxscale 80 width 100cm height 8cm keepAspectRatio \end_inset \layout Caption Esquema del procedimiento de instalación desatendida para servidores GNU/Linux en su fase final \end_inset \layout Standard Como se puede intuir por la cantidad de cosas mencionadas, la herramienta \family typewriter autoactualiza \family default es la que más valor añadido proporciona al sistema de administración centraliza da, ya que está diseñada para permitir la gestión automática de cualquier parte del software del sistema administrado. \layout Standard Este proceso en conjunto, aunque quizá resulte muy complejo de comprender, es sin embargo muy rápido, permitiendo instalar y configurar un servidor completo en muy pocos minutos. \layout Subsection \begin_inset LatexCommand \label{sub:implem-instalación-clientes-linux} \end_inset Sistema de instalación automática de clientes GNU/Linux \layout Standard En nuestro caso, el fichero \family typewriter root.tgz \family default está generado con \family typewriter tar \family default y comprimido con \family typewriter gzip \family default . Para gestionar este tipo de imágenes de forma automática, hemos creado un script llamado \family typewriter mkroot \family default . \layout Standard Una vez se ha creado el fichero \family typewriter root.tgz \family default , hemos de distribuirlo a los servidores de arranque de los clientes. Para realizar la tarea de distribución se ha configurado la herramienta \family typewriter rdist \family default en el directorio \family typewriter imagenes_rdist \family default del servidor de administración. \layout Standard El fichero \family typewriter root.tgz \family default , 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 archivo \family typewriter root.tgz \family default 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 me\SpecialChar \- dian\SpecialChar \- te 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áticamen te el cliente tiene disponible la versión actualizada. \layout Standard 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 \family typewriter /usr \family default ), sino también para las librerías dinámicas del sistema ( \family typewriter /lib \family default ), y las aplicaciones generales y de administración (que están en \family typewriter /bin \family default y \family typewriter /sbin \family default , 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. \layout Standard Las tareas previas a la de descompresión del fichero \family typewriter root.tgz \family default 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 configura r 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 ( \family typewriter linuxrc \family default ) 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 llama \family typewriter initrd \family default 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 llama \family typewriter mkimagen \family default 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. \layout Standard Para minimizar el uso de la red en tiempo de arranque, hemos diseñado un programa ( \family typewriter rc.\SpecialChar \- checkfile_hda4 \family default ) que es capaz de gestionar una partición del disco como caché, comprobar si existe el archivo necesario (en este caso el \family typewriter root.tgz \family default ), 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 ( \family typewriter md5sum \family default ). \layout Standard Desde el punto de vista del usuario, la opción que ha de elegir para reinstalar el cliente con GNU/Linux es la de \begin_inset Quotes sld \end_inset Instalación y Arranque de GNU/Linux \begin_inset Quotes srd \end_inset . Describimos a continuación los pasos intermedios realizados en el ordenador cliente cuando se ejecuta esta opción: \layout Itemize 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. \layout Itemize 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 particionado ha de ser exactamente igual que el que se realiza cuando se ejecuta la opción de regeneración de Windows XP. \layout Itemize Se formatean las particiones de Linux destinadas a almacenamiento de archivos en local. Para ello se utiliza \family typewriter mk2fs \family default . \layout Itemize Se formatea y activa la partición de memoria virtual (Linux swap). Con \family typewriter mkswap \family default y \family typewriter swapon \family default . \layout Itemize 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 aplicaciones \family typewriter tar \family default y \family typewriter gzip \family default , además de \family typewriter mount \family default . \layout Itemize Se regenera el Master Boot Record (MBR) con un gestor de arranque de disco local (LILO \begin_inset LatexCommand \cite{lilo} \end_inset ) para poder arrancar Windows XP desde el disco duro local. Esta tarea se debe realizar siempre que se reparticiona el disco duro. \layout Itemize 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. \layout Itemize 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. \layout Itemize 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 \begin_inset LatexCommand \cite{sudo} \end_inset , que permite dar permisos de ejecución especiales a usuarios concretos. \layout Itemize 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 \family typewriter /tmp \family default ) 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 \begin_inset LatexCommand \ref{sec:Gestión-de-usuarios} \end_inset ). \layout Standard \begin_inset Float figure wide false collapsed false \layout Standard \align center \begin_inset Graphics filename ../Proyecto_Omar_figuras/inst-cli-linux.gif lyxscale 80 width 100cm height 8cm keepAspectRatio \end_inset \layout Caption Esquema del proceso de reinstalación de clientes GNU/Linux \end_inset \layout Subsection \begin_inset LatexCommand \label{sub:implem-regeneración-XP} \end_inset Sistema de regeneración automática de clientes Windows XP \layout Standard 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: \layout Itemize \begin_inset LatexCommand \label{enu:Regeneración-de-Windows} \end_inset Regeneración de Windows XP: Mediante esta opción se realiza la subfase de regeneración cruda de Windows XP. \begin_deeper \layout Itemize 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. \layout Itemize 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é \begin_inset Foot collapsed false \layout Standard caché: lugar temporal de almacenamiento de datos de uso frecuente, con el fin de evitar malgastar tiempo o ancho de banda \end_inset de ficheros. Este particionado ha de ser exactamente igual que el que se realiza cuando se ejecuta la opción de arranque de Linux. \layout Itemize Se formatea la partición caché si es que no está formateada y se copia en ella la ima\SpecialChar \- gen del Windows XP que está accesible desde la red (por NFS \begin_inset LatexCommand \cite{nfs} \end_inset ). Se comprueba que la copia es correcta utilizando un sistema de firma basado en el algoritmo MD5. \layout Itemize Mediante un clonador de particiones ( \family typewriter partimage \family default \begin_inset LatexCommand \cite{partimage} \end_inset ) 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 recupera 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á directament e 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). \layout Itemize 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 \begin_inset LatexCommand \cite{lilo} \end_inset por su sencillez. \layout Itemize Se modifica el fichero de configuración del Sysprep \begin_inset LatexCommand \cite{sysprep} \end_inset ( \family typewriter sysprep.inf \family default ) mediante el montado de la partición NTFS en lectura/escritura, para cambiar los campos dife\SpecialChar \- ren\SpecialChar \- ciales 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. \layout Itemize Se reinicia el ordenador. \end_deeper \layout Itemize \begin_inset LatexCommand \label{enu:Arranque-de-Windows} \end_inset 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: \begin_deeper \layout Itemize Que sea la primera vez que arranca el Windows XP después de una regeneración, caso en el que la subfase a ejecutar será la de autoconfiguración (previamente preparada a través del programa \family typewriter sysprep \family default 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 configuración de los dispositivos locales para que éstos estén disponibles para el usuario. \begin_deeper \layout Standard Terminado el proceso de autoconfiguración, se reiniciará automáticamente el sistema. El proceso de reinicialización después de la autoconfiguración es inevitable con este sistema operativo. \end_deeper \layout Itemize 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. \begin_deeper \layout Standard En algunos entornos puede resultar conveniente que este sistema operativo esté configurado 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 \begin_inset LatexCommand \cite{samba} \end_inset 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 dificultade s \begin_inset LatexCommand \cite{Samba y dominio XP} \end_inset . \layout Standard Además de la configuración mencionada es necesario administrar los identificador es 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 \begin_inset LatexCommand \ref{sec:Gestión-de-usuarios} \end_inset ). \end_deeper \end_deeper \layout Standard \begin_inset Float figure wide false collapsed false \layout Standard \align center \begin_inset Graphics filename ../Proyecto_Omar_figuras/reg-xp.gif lyxscale 80 width 100cm height 8cm keepAspectRatio \end_inset \layout Caption Esquema del proceso de regeneración de clientes Windows XP en su fase inicial \end_inset \layout Standard \begin_inset Float figure wide false collapsed false \layout Standard \align center \begin_inset Graphics filename ../Proyecto_Omar_figuras/reg-xp2.gif lyxscale 80 width 100cm height 8cm keepAspectRatio \end_inset \layout Caption Esquema del proceso de regeneración de clientes Windows XP en su fase final \end_inset \layout Standard Desde el punto de vista del administrador, y dadas las características específic as 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: \family typewriter partimage \family default . Los detalles de esta tarea se facilitan en la sección \begin_inset LatexCommand \ref{sub:Creación-de-imágenes-XP} \end_inset , dentro de la especificación de las funciones del administrador. \layout Subsection \begin_inset LatexCommand \label{sub:implem-instalación-XP} \end_inset Sistema de instalación automática de clientes y servidores Windows XP \layout Standard La instalación de Windows XP de forma automática y desatendida se basa en la confi\SpecialChar \- guración de un disquete de arranque que permite al ordenador iniciar su dispositivo de inter\SpecialChar \- cone\SpecialChar \- xión a la red. El proceso está dividido en varias fases. Primero, se realizará un arranque de disquete y una configuración del dispositi vo de red, hecho esto, se montará el servidor de red correspondiente. Luego, se realizará el particionado y la configuración del disco duro local 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). \layout Standard \begin_inset Float figure placement th wide false collapsed false \layout Standard \align center \begin_inset Graphics filename ../Proyecto_Omar_figuras/winxp.gif width 100cm height 9cm keepAspectRatio \end_inset \layout Caption Esquema general de directorios del sistema de instalación para Windows XP \end_inset \layout Subsubsection Estado inicial \layout Standard 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 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 utilidades \family typewriter isolinux \family default y \family typewriter memdisk \family default \begin_inset LatexCommand \cite{Syslinux} \end_inset ). Por sencillez, el proceso que se relatará en esta sección está referido únicamente a la utilización de un disquete. \layout Standard 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. \layout Subsubsection Fase MS-DOS \layout Standard 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. \layout Standard Mediante un disquete MS-DOS con soporte de red (creado con las utilidades proporcionadas por Bart Lagerweij desde su página web \begin_inset LatexCommand \cite{bart-bootdisk} \end_inset ) se arranca el cliente. En el proceso de arranque, este disquete analizará sus dispositivos, identifica rá su tarjeta de red, cargará sus drivers, utili\SpecialChar \- zará DHCP para averiguar su dirección IP y nombre ( \family typewriter nombremaq \family default ) y después montará me\SpecialChar \- dian\SpecialChar \- te protocolo NETBEUI un directorio de una máquina remota (el servidor principal o uno de los servidores secundarios). \layout Standard En ella (a esta unidad la hemos llamado \family typewriter z: \family default ), estarán ubicados los comandos necesarios para realizar las tareas de preparación del disco local (nosotros hemos llamado a este archivo \family typewriter nombremaq.bat \family default ) 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 llamado \family typewriter y: \family default ). \layout Standard Hecho esto, se busca en la unidad \family typewriter z: \family default el archivo de comandos \family typewriter nombremaq.bat \family default y con él se particiona y formatea en FAT-32 el disco duro a través de la aplicación aefdisk \begin_inset LatexCommand \cite{aefdisk} \end_inset . 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 archivo \family typewriter nombremaq.bat \family default habrá de estar correctamente configurado 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. \layout Standard La segunda subfase arranca también con el disquete MS-DOS que hemos utilizado antes. Esta vez, el archivo de ejecución por lotes ( \family typewriter autoexec.bat \family default ) 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. \layout Standard Para llevar a cabo la instalación de Windows XP desde la unidad de red de forma desatendida, es necesario ejecutar el comando de instalación pasándole como parámetro el fichero de configuración \family typewriter nombremaq.txt \family default que previamente habremos preparado. Este archivo, que Microsoft en su documentación denomina \family typewriter unattend.txt \family default , se puede crear con una utilidad llamada \family typewriter setupmgr \family default que encontramos en el disco de instalación de Windows XP dentro del fichero \family typewriter support \backslash \SpecialChar \- tools \backslash \SpecialChar \- deploy.cab \family default . \layout Standard \begin_inset Float figure placement th wide false collapsed false \layout Standard \align center \begin_inset Graphics filename ../Proyecto_Omar_figuras/inst-win.gif width 100cm height 8cm keepAspectRatio \end_inset \layout Caption Esquema del proceso de instalación de sistemas Windows XP \end_inset \layout Standard En nuestro caso, \family typewriter nombremaq.txt \family default 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\SpecialChar \- ra\SpecialChar \- tivo (en lo que es realmente la postinstalación ). En nuestro caso, hemos llamado a este último script \family typewriter nombremaq.cmd \family default . \layout Standard En concreto, el comando de instalación que se ejecuta es \family typewriter z: \backslash \SpecialChar \- winxp \backslash \SpecialChar \- i386 \backslash \SpecialChar \- winnt /s:z: \backslash \SpecialChar \- winxp \backslash \SpecialChar \- i386 /u:z: \backslash \SpecialChar \- WINXP \backslash \SpecialChar \- MAQUINAS \backslash \SpecialChar \- nombremaq \backslash \SpecialChar \- nombremaq.txt. \family default Este comando, al ejecutarse, realiza la preinstalación del sistema para que el disco duro sea capaz de iniciar la ins\SpecialChar \- tala\SpecialChar \- ción propiamente dicha, objeto de la siguiente fase. Durante la preinstalación, se copia el contenido del directorio \family typewriter winxp \backslash i386 \family default de la unidad \family typewriter z: \family default a la unidad de disco formateada anteriormente mediante el comando \family typewriter aefdisk \family default y que tomará como nombre unidad \family typewriter c: \family default . Después, se configura el sistema para continuar la instalación desde disco duro y se reinicia de nuevo. \layout Subsubsection Fase Windows \layout Standard 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. \layout Standard Este proceso, al haberlo indicado así en el fichero de configuración \family typewriter nombremaq.txt \family default , 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 incluidos en la distribución siempre que se lo hayamos indicado así en el fichero \family typewriter nombremaq.txt \family default y realizará de forma automática la detección y la configuración del hardware, así como la instalación de la licencia y de todos los archivos y configuracione s del sistema operativo. \layout Subsubsection Fase Aplicaciones \layout Standard 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 script \family typewriter nombremaq.cmd \family default (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). \layout Standard 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 \begin_inset LatexCommand \cite{pjpg-autoinst} \end_inset y la de Karl Bernard \begin_inset LatexCommand \cite{unattended-install} \end_inset . También se puede encontrar información sobre la generación de instalaciones de aplicaciones automatizables para Windows en las páginas de Autoit \begin_inset LatexCommand \cite{Autoit} \end_inset y WinstallLE \begin_inset LatexCommand \cite{winstallle} \end_inset de Veritas, así como en Microsoft \begin_inset LatexCommand \cite{Microsoft} \end_inset (formato msi). \layout Chapter Guía de Administración \layout Section Generación de la plataforma de administración \layout Standard El primer trabajo que habrá de afrontar el admi\SpecialChar \- nis\SpecialChar \- trador será la instalación del servidor principal y la implantación en el mismo del sistema de administrac ión centralizada. Esta tarea se realizará en varias fases, que describiremos a continuación. \layout Enumerate Instalación del sistema operativo del servidor principal o maestro. Para llevar a cabo esta 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. \layout Enumerate Creación de los usuarios de administración del sistema: operador y admin con UID \begin_inset Foot collapsed true \layout Standard UID: número identificador de usuario utilizado en los sistemas Unix \end_inset 500 y 501, respectivamente. \layout Enumerate A partir de la imagen creada con la utilidad \family typewriter mkmaestro \family default ( \family typewriter sadmc\SpecialChar \- 20030721.\SpecialChar \- tar.\SpecialChar \- gz \family default ), 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). \layout Enumerate 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: \begin_deeper \layout Standard \family typewriter /home/admin/distrib/redhat-7.3 \family default : en este directorio se copiará el contenido de los CDs de instalación de la distribución de GNU/Linux, respetando los subdirectorios del sistema de administración particularizados para esta distribución que existan por debajo del mismo. \layout Standard \family typewriter /home/admin/distrib/redhat-7.3/updates \family default : aquí se deben almacenar los paquetes de actualización de la distribución. \layout Standard \family typewriter /home/admin/distrib/winxp \family default : aquí se guardará el contenido de los directorios \family typewriter docs \family default , \family typewriter I386 \family default , \family typewriter support \family default y \family typewriter valueadd \family default del disco de instalación de Windows XP Professional. \layout Standard \family typewriter /home/admin/distrib/winapps \family default : 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 subdirectorio \family typewriter officexp \family default . A estos directorios accederá el archivo de ejecución de la postinstalación, \family typewriter nombremaq.cmd \family default . \end_deeper \layout Enumerate 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 configuraciones de DHCP y las imágenes estándar exportables por TFTP están bajo el directorio \family typewriter servicios \family default del usuario operador (en los subdirectorios \family typewriter dhcpd \family default y \family typewriter tftpboot \family default , respectivamente). \layout Standard 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 \begin_inset LatexCommand \ref{cha:Implementación} \end_inset y en el resto de secciones de este capítulo. \layout Standard Entre otras cosas, habrá que generar los perfiles de instalación de los servidores secundarios GNU/Linux ( \family typewriter nombremaq.m4 \family default ) y los archivos de configuración correspondientes para la instalación de estaciones Windows XP ( \family typewriter nombremaq.{bat, txt, cmd} \family default ), así como las imágenes de reinstalación de los clientes GNU/\SpecialChar \- Linux ( \family typewriter root.tgz \family default ) y de regeneración de los clientes Windows XP ( \family typewriter xp.gz.000 \family default ). Para ello, el administrador habrá de familiarizarse con las herramientas implementadas y con la estructura de directorios del sistema que deberá manejar. \layout Section Tareas frecuentes del administrador \layout Subsection Creación y modificación de los perfiles para los servidores binarios \layout Standard 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. \layout Standard Cuando el perfil está preparado, lo único que resta hacer es ejecutar \family typewriter mkdist \family default , 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 ( \family typewriter ks.cfg \family default ), 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 postinstal ación para ajustar detalles del sistema. \layout Subsection \begin_inset LatexCommand \label{sub:perfiles-hardware} \end_inset Creación de nuevos perfiles hardware para los clientes GNU/Linux \layout Standard 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 del \family typewriter root.tgz \family default , y por último ejecutan el script de inicialización local (contenido en el archivo \family typewriter /etc/rc.d/rc.local \family default ). \layout Standard Tal y como está configurado el cliente, el archivo \family typewriter rc.local \family default es un enlace al archivo \family typewriter /usr/\SpecialChar \- local/\SpecialChar \- local/\SpecialChar \- clients_conf-1.1/\SpecialChar \- etc/\SpecialChar \- rc.d/\SpecialChar \- rc.local \family default del servidor binario que le ha proporcionado el arranque. Con él, se analiza el archivo \family typewriter dispositivos \family default (también accesible por NFS), se extrae el perfil concreto del cliente y se configuran con él las aplicaciones depen\SpecialChar \- dien\SpecialChar \- tes de los mismos: el gestor de ratón ( \family typewriter gpm \family default ) y el servidor gráfico (XFree \begin_inset LatexCommand \cite{xfree} \end_inset ). \layout Standard Para ver cómo modificar el archivo \family typewriter dispositivos \family default , se puede consultar el apartado \begin_inset LatexCommand \ref{sub:Modificar-dispositivos} \end_inset . Para modificar el fichero \family typewriter rc.local \family default , aunque es necesario tener conocimientos de programación en shell \begin_inset Foot collapsed false \layout Standard shell: nombre que recibe el intérprete de comandos en los sistemas operativos tipo Unix \end_inset , se debe utilizar exactamente el mismo procedimiento de distribución. \layout Standard Todos los clientes GNU/Linux utilizan el mismo servidor gráfico y el mismo fichero de configuración ( \family typewriter /etc/X11/XF86Config-4 \family default , que también se obtiene por NFS), aunque sus dispositivos sean diferentes. La distinción se realiza al ejecutar el \family typewriter rc.local \family default , especificándole al sistema gráfico el perfil concreto para la máquina en cuestión. Para ello, hay que utilizar el parámetro \family typewriter -layout \family default seguido del nombre que agrupa la configuración concreta del cliente y guardar esa información en el archivo de configuración del sistema gráfico \family typewriter /etc/X11/xdm/Xservers \family default , tarea que también realiza el propio \family typewriter rc.local \family default . \layout Standard Por eso, cuando se modifica el archivo \family typewriter /usr/\SpecialChar \- local/\SpecialChar \- local/\SpecialChar \- clients_conf-1.1/\SpecialChar \- lib/\SpecialChar \- X11/\SpecialChar \- XF86Config-4 \family default 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 script \family typewriter rc.local \family default . \layout Standard 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 administr ador del sistema teniendo en cuenta las capacidades físicas del monitor y la configuración del resto de los dispositivos. \layout Subsection Creación y actualización de las imágenes de arranque para los \newline clientes GNU/Linux \layout Standard Como se ha explicado en la sección \begin_inset LatexCommand \ref{sub:implem-instalación-clientes-linux} \end_inset , los clientes de Linux utilizan un disco virtual en memoria RAM ( \family typewriter initrd \family default ) 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 \family typewriter initrd \family default se almacenan los módulos del núcleo ( \family typewriter vmlinuz \family default ) relativos a la gestión del hardware, y que éstos son diferentes cuando cambia la versión, el \family typewriter initrd \family default habrá de modificarse siempre que se decida actualizar la versión del núcleo. \layout Standard Para una gestión más sencilla del \family typewriter initrd \family default de los clientes del laboratorio, se ha creado el programa \family typewriter mkimagen \family default . 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 archivo \family typewriter initrd \family default especificado. \layout Standard 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 de \family typewriter vmlinuz \family default o para modificar la configuración del sistema durante el arranque (a través del script \family typewriter /linuxrc \family default del ramdisk). Explicaremos brevemente la forma de proceder para la realización de estos cambios. \layout Standard \begin_inset Float figure wide false collapsed false \layout Standard \align center \begin_inset Graphics filename ../Proyecto_Omar_figuras/operador-general.gif width 100cm height 7cm keepAspectRatio \end_inset \layout Caption Esquema general del directorio de servicios del usuario operador \end_inset \layout Enumerate Entrar al directorio de operador donde están los scripts de gestión del arranque de los clientes Linux: \begin_deeper \layout Standard \family typewriter cd /home/operador/administracion/servicios/arranque_maquinas \layout Standard NOTA: Por abreviar, en esta sección, indicaremos el acceso a este directorio refiriéndonos únicamente a \family typewriter arranque_maquinas. \end_deeper \layout Enumerate Ejecutar el script de configuración de imágenes, con las opciones de edición ( \family typewriter -e \family default ) e instalación ( \family typewriter -i \family default ): \begin_deeper \layout Standard . \family typewriter /mkimagen -i -e linux-ntfs \layout Standard En este caso, como deseamos modificar la imagen de disco RAM de Linux que se carga en los clientes GNU/Linux, utilizamos el parámetro \family typewriter linux-\SpecialChar \- ntfs \family default . Con este parámetro se le dice al programa que utilice la imagen que recibe como nombre completo \family typewriter initrd.img-\SpecialChar \- linux-\SpecialChar \- ntfs \family default . \layout Standard Al arrancar el programa, éste muestra una serie de mensajes indicando que está desempaquetando la imagen y muestra el directorio en que la pone accesible ( \family typewriter arranque\SpecialChar \- _maquinas/\SpecialChar \- mount\SpecialChar \- _points/\SpecialChar \- nueva \family default ). Asimismo, queda a la espera de una pulsación de [ENTER] para volver a empaqueta rla desde ese mismo directorio. \layout Itemize Para cambiar un módulo: \begin_deeper \layout Enumerate Desde otra consola de maestro, entrar en el directorio donde están los módulos del núcleo: \begin_deeper \layout Standard \family typewriter cd \family default \family typewriter arranque_maquinas/mount_points/nueva/lib/modules/current \end_deeper \layout Enumerate Cambiar los módulos necesarios simplemente reescribiendo el módulo existente 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: \begin_deeper \layout Standard \family typewriter cp /lib/modules//kernel/drivers/net/eepro100.o . \end_deeper \end_deeper \layout Itemize Para cambiar el script de inicio: \begin_deeper \layout Enumerate Desde otra consola de maestro, cambiar al directorio / del ramdisk: \begin_deeper \layout Standard \family typewriter cd arranque_maquinas/mount_points/nueva \end_deeper \layout Enumerate Editar el archivo de gestión de inicio: \begin_deeper \layout Standard \family typewriter vi linuxrc \end_deeper \layout Enumerate Guardar los cambios en el directorio de backups: \begin_deeper \layout Standard \family typewriter cp linuxrc arranque_maquinas/scripts/linuxrc. \layout Standard Para seguir una norma, especificamos la \family typewriter \family default empezando por las dos últimas 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. \end_deeper \end_deeper \end_deeper \layout Enumerate Cerrar la consola nueva o cambiar a cualquier directorio por encima del punto de montaje de la imagen: \begin_deeper \layout Standard \family typewriter cd arranque_maquinas \end_deeper \layout Enumerate Pulsar [ENTER] (en la consola donde se lanzó \family typewriter mkimagen \family default ) para que el programa finalice con el empaquetado de la nueva imagen. \layout Enumerate Distribuir los cambios a los binarios: \begin_deeper \layout Standard \family typewriter cd arranque_maquinas/tftpboot \layout Standard \family typewriter make rdist \end_deeper \layout Enumerate Probar la nueva imagen en los clientes arrancando la opción adecuada (en este caso, GNU/Linux). \layout Standard \begin_inset Float figure wide false collapsed false \layout Standard \align center \begin_inset Graphics filename ../Proyecto_Omar_figuras/operador-arranque.gif width 100cm height 7cm keepAspectRatio \end_inset \layout Caption Esquema detalle del subdirectorio \family typewriter arranque_maquinas \end_inset \layout Standard Para minimizar la cantidad de imágenes necesarias para las diferentes configurac iones locales, 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 programa \family typewriter linuxrc \family default que toma control al cargarse el disco RAM y que, a su vez, hace uso de otros scripts que están en disco RAM: \layout Itemize \family typewriter rc.fdisk.\SpecialChar \- , que se encarga de realizar el particionado del disco en función de la variable \family typewriter DISCO \family default 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 programa \family typewriter linuxrc \family default . Los valores que puede tomar la variable \family typewriter DISCO \family default son: \family typewriter mucho \family default , \family typewriter poco \family default o \family typewriter muypoco \family default . \layout Itemize \family typewriter rc.checkfile\SpecialChar \- _hda4 \family default , 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 variable \family typewriter REGENERA \family default ) 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 programa \family typewriter linuxrc \family default habrá de utilizar. Los valores que la variable REGENERA puede tomar en la actualidad son: \family typewriter root.tgz \family default , \family typewriter xp.\SpecialChar \- gz.000 \family default y \family typewriter xp.nec\SpecialChar \- .gz.000 \family default . \layout Itemize \family typewriter rc.bootp \family default , 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. \layout Subsection Creación y modificación de la imagen de reinstalación de los clientes GNU/Linux \layout Standard Los clientes GNU/Linux utilizan el \family typewriter root.tgz \family default para reconstruir su sistema de ficheros raíz. La gestión de este archivo se realiza mediante el script \family typewriter mkroot \family default que utiliza \family typewriter tar \family default para generar el fichero \family typewriter root.tgz \family default . \layout Standard 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. \layout Standard Luego a este archivo se le añaden o sustituyen los archivos que queramos, utilizando los que se almacenan en el directorio \family typewriter arranque\SpecialChar \- _maquinas/\SpecialChar \- client\SpecialChar \- _root, \family default que reproduce la jerarquía de directorios de un cliente. \layout Standard Al final, el archivo root.tgz se distribuye a todos los binarios (desde el directorio \family typewriter arranque\SpecialChar \- _maquinas/\SpecialChar \- imagenes\SpecialChar \- _rdist \family default ) ejecutando \family typewriter make rdist \family default . \layout Standard Para generar un \family typewriter root.tgz \family default correspondiente a otra distribución, solamente habría que configurar algunos binarios con nueva distribución, generar a través de ellos una nueva imagen de reinstalación (otro fichero como el \family typewriter root.tgz \family default pero con otro nombre), configurarlos para que diesen arranque a los clientes a través del menú de arranque y configurar el \family typewriter rc.local \family default . Evidentemente, 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 directorio \family typewriter client_root \family default . \layout Subsection Modificación del sistema para instalar de servidores GNU/Linux con otras distribuciones \layout Standard Los pasos que debe seguir el administrador para soportar la instalación de una nueva distribución son: \layout Enumerate 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. \begin_deeper \layout Standard En el caso de RedHat 7.3, los pasos aconsejados son (el siguiente proceso configurará el directorio /target/directory en el servidor): \layout Standard 1) Introducir el disco 1 \layout Standard 2) \family typewriter mount /mnt/cdrom \layout Standard 3) \family typewriter cp -a /mnt/cdrom/RedHat /target/directory \layout Standard 4) \family typewriter umount /mnt/cdrom \layout Standard 5) Sustituir el disco 1 por el disco 2 \layout Standard 6) \family typewriter mount /mnt/cdrom \layout Standard 7) \family typewriter cp -a /mnt/cdrom/RedHat /target/directory \layout Standard 8) \family typewriter umount /mnt/cdrom \layout Standard 9) Sustituir el disco 2 por el disco 3 \layout Standard 10) \family typewriter mount /mnt/cdrom \layout Standard 11) \family typewriter cp -a /mnt/cdrom/RedHat /target/directory \layout Standard 12) \family typewriter umount /mnt/cdrom \end_deeper \layout Enumerate 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. \begin_deeper \layout Standard 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. \end_deeper \layout Enumerate 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. \layout Enumerate Deberá comprobar también que \family typewriter mkdist \family default genera un fichero que el instalador entiende (para RedHat, \family typewriter ks.cfg \family default ; para SuSE, XML) y si no lo hace, modificar \family typewriter mkdist \family default para que genere un fichero adecuado para cada distribución. \layout Enumerate Por ultimo, el administrador debe hacer que el menú de arranque de los servidore s, tenga la opción de iniciar la instalación de ambas distribuciones. \layout Standard Tras realizar estos pasos, se podrán instalar por el mismo procedimiento las diferentes distribuciones GNU/Linux (véase el punto \begin_inset LatexCommand \ref{sub:Instalación-y-postinstalación-bins} \end_inset ). \layout Subsection \begin_inset LatexCommand \label{sub:Creación-de-imágenes-XP} \end_inset Creación de imágenes para la regeneración de Windows XP \layout Standard La herramienta utilizada para la creación de las imágenes de disco de Windows XP es \family typewriter partimage \family default \begin_inset LatexCommand \cite{partimage} \end_inset . 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. \layout Standard Las tareas de creación se han de realizar en el siguiente orden: \layout Enumerate Se reinstala un Windows XP en uno de los ordenadores cliente. \layout Enumerate Se utiliza el comando \family typewriter sysprep \family default para dejar el sistema operativo configurado de tal forma que la próxima vez que arranque se realice una reconfiguración de la parte software 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 \family typewriter sysprep.inf \family default que contiene los parámetros básicos de la reconfiguración. \layout Enumerate 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é. Como \family typewriter partimage \family default necesita espacio libre en el directorio \family typewriter /tmp \family default (tanto para crear imágenes como para restaurarlas) puede ser conveniente montar la partición caché en el directorio mencionado. Para ello, ejecutar \family typewriter mount /dev/hda4 /tmp \family default desde la línea de comandos. \layout Enumerate Se ejecuta \family typewriter partimage \family default 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é ( \family typewriter /tmp \family default ). El nombre temporal de la imagen puede ser el que queramos. \layout Enumerate 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 es \family typewriter maestro:\SpecialChar \- /home/\SpecialChar \- operador/\SpecialChar \- administracion/\SpecialChar \- servicios/\SpecialChar \- arranque\SpecialChar \- _maquinas/\SpecialChar \- imagenes_rdist /\SpecialChar \- lib \family default , y el nombre del fichero que usa para guar\SpecialChar \- dar la partición de Windows XP es \family typewriter xp.gz.000 \family default (para el caso de los clientes Dell y Compaq del laboratorio) o \family typewriter xp.nec.gz.000 \family default (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. \layout Enumerate Se distribuye la imagen creada para que se puedan regenerar las máquinas con ella. Para ello, entrar en el directorio \family typewriter /home/\SpecialChar \- operador/\SpecialChar \- administracion/\SpecialChar \- servicios/\SpecialChar \- arranque\SpecialChar \- _maquinas/\SpecialChar \- imagenes_rdist/ \family default y ejecutar \family typewriter make all \family default . 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. \layout Enumerate Se regenera un cliente Windows XP del tipo modificado y se comprueba que el funcionamiento es correcto. \layout Standard 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 \begin_inset LatexCommand \ref{enu:Regeneración-de-Windows} \end_inset . \layout Section Tareas frecuentes del operador \layout Subsection Configuración de la BIOS de los clientes del laboratorio \layout Standard 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 siguiente s tareas: \layout Itemize Configurar una clave de administrador (ojo, no de usuario) para que los alumnos no puedan modificar los parámetros. \layout Itemize Hacer que la máquina sea capaz de arrancar de la tarjeta de red. \layout Itemize Asegurarse de que la primera opción en la secuencia de arranque sea precisamente la red. \layout Itemize 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. \layout Standard Para tarjetas de red antiguas, será necesario grabar la memoria ROM (véase \begin_inset LatexCommand \ref{sub:Grabación-ROM} \end_inset ). \layout Subsection \begin_inset LatexCommand \label{sub:Grabación-ROM} \end_inset Grabación y actualización de las ROM de las tarjetas de red de los clientes \layout Standard 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: \layout Itemize El operador configurará la BIOS para que arranque de disquete. \layout Itemize 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 llamado \family typewriter flash.exe \family default ). \layout Itemize El programa le guiará paso a paso con unas instrucciones sencillas. Lo más normal es que sean los siguientes: \begin_deeper \layout Enumerate Salvar el contenido actual de la memoria FLASH a un fichero del disquete. \layout Enumerate Grabar la ROM con la imagen contenida en el programa. \layout Enumerate Reiniciar el PC. \end_deeper \layout Itemize El operador probará la detección de la ROM en fase de arranque y quitará el disquete como medio de arranque de la BIOS. \layout Standard 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 \begin_inset LatexCommand \cite{rom-o-matic} \end_inset a través de los que se ofrece la posibilidad de generar y descargar una imagen para muchas tarjetas no soportadas. \layout Subsection Regeneración de Windows XP en los clientes del laboratorio \layout Standard Si por algún motivo (generación de nuevas imágenes de regeneración, instalación de aplicaciones, 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: \layout Enumerate Arrancar el cliente y esperar a que aparezca el menú de arranque \layout Enumerate Seleccionar la opción "Regenerar Windows XP" \layout Enumerate Esperar mientras se regenera la partición del disco duro. Cuando la máquina reinicie, ha de seleccionar \begin_inset Quotes sld \end_inset Cargar Windows XP \begin_inset Quotes srd \end_inset del menú. \layout Enumerate Esperar mientras se autoconfigura el Windows. Cuando la máquina reinicie, ha de volver a seleccionar \begin_inset Quotes sld \end_inset Cargar Windows XP \begin_inset Quotes srd \end_inset del menú. \layout Enumerate Iniciar la sesión en Windows XP, seleccionando el dominio LABPDC e introduciendo usuario y clave. \layout Subsection \begin_inset LatexCommand \label{sub:Instalación-y-postinstalación-bins} \end_inset Instalación y postinstalación de servidores secundarios GNU/Linux \layout Itemize Instalación: La instalación de un servidor secundario del laboratorio consiste en: \begin_deeper \layout Enumerate 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. \layout Enumerate Presionar el botón de encendido y esperar a que aparezca un menú. \layout Enumerate Seleccionar la opción de \begin_inset Quotes sld \end_inset Instalación automática de RedHat 7.3 \begin_inset Quotes srd \end_inset . \layout Enumerate Esperar a que se reinicie el ordenador. Cuando vuelva a arrancar, al expirar el temporizador de un minuto, se iniciará de forma automática la opción del menú \begin_inset Quotes sld \end_inset Arrancar de Disco Duro \begin_inset Quotes srd \end_inset . \layout Enumerate Al ser el primer arranque, la máquina está configurada para realizar su postinstalación mediante la aplicación \family typewriter autoactualiza \family default . Esta aplicación configura los servidores, programa las actualizaciones de paquetes e instala todo lo que por estar en otros formatos no haya podido instalarse mediante el instalador del sistema operativo. Pasados unos minutos la máquina estará operativa y dando servicio a los clientes del laboratorio. \end_deeper \layout Itemize Postinstalación: La postinstalación de un servidor del laboratorio se puede realizar independientemente de la instalación en cualquier momento posterior. Se puede ordenar desde el servidor principal o desde el servidor secundario concreto que deseamos actualizar: \begin_deeper \layout Itemize Desde el servidor principal: Ejecutar \family typewriter actualiza -m perfil \family default , donde \family typewriter perfil \family default 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 \family typewriter -binarios \family default . \layout Itemize Desde el servidor que se quiera actualizar: Ejecutar \family typewriter autoactualiza \family default . Podemos indicarle al programa de postinstalación si queremos que utilice todos los patrones que tiene el servidor preparados para esta máquina (opción \family typewriter -f \family default ), 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). \layout Standard 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. \end_deeper \layout Subsection Comprobación del funcionamiento del laboratorio \layout Standard Periódicamente, el servidor principal del laboratorio efectúa un chequeo de todos los servicios que tienen que estar funcionando en los servidores del laboratorio. Esto lo hace mediante la ejecución de diferentes comandos de \family typewriter nmap \family default \begin_inset LatexCommand \cite{nmap} \end_inset 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. \layout Standard El modo de efectuar todas las comprobaciones necesarias, es mediante la ejecución de un script ( \family typewriter lab_servers_info \family default ) a través del \family typewriter cron \family default , que cada dos horas chequea puertos abiertos y espacio libre en los discos, entre otras cosas. El programa está situado en el directorio de servicios del usuario operador de la máquina maestro ( \family typewriter maestro:\SpecialChar \- /home/\SpecialChar \- operador/\SpecialChar \- administracion/\SpecialChar \- servicios/\SpecialChar \- lab_servers_info \family default ) y se puede ejecutar directamente cada vez que se quiera rea\SpecialChar \- 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. \layout Subsection Comprobar los clientes asignados a cada binario \layout Standard 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. \layout Standard 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 llama \family typewriter binarios_info \family default y está situado en el directorio de servicios del usuario operador de la máquina maestro ( \family typewriter maestro:\SpecialChar \- /home/\SpecialChar \- operador/\SpecialChar \- administracion/\SpecialChar \- servicios/\SpecialChar \- binarios_info \family default ). Para obtener la información, sólo hay que ejecutarlo desde el directorio indicado ( \family typewriter ./binarios_info \family default ) y será mostrada en la misma consola del usuario. \layout Subsection Comprobar y gestionar la cola de las impresoras \layout Standard 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: \layout Itemize Comprobar si las impresoras de red están encendidas y funcionando: \begin_deeper \layout Standard \family typewriter ping impresoraA \layout Standard \family typewriter ping impresoraB \end_deeper \layout Itemize Comprobar el estado de todas las colas: \begin_deeper \layout Standard \family typewriter ssh cuentas lpq -a \end_deeper \layout Itemize Eliminar un trabajo de la cola de impresora: \begin_deeper \layout Standard \family typewriter ssh cuentas lprm -PlpA \layout Standard \family typewriter ssh cuentas lprm -PlpB \family default \end_deeper \layout Itemize Eliminar los trabajos de la cola de impresora de un usuario concreto: \begin_deeper \layout Standard \family typewriter ssh cuentas lprm -PlpA -U \layout Standard \family typewriter ssh cuentas lprm -PlpB -U \end_deeper \layout Itemize Eliminar todos los trabajos de la cola de impresora: \begin_deeper \layout Standard \family typewriter ssh cuentas lprm -PlpA all \layout Standard \family typewriter ssh cuentas lprm -PlpB all \end_deeper \layout Itemize Reiniciar el servidor de impresoras: \begin_deeper \layout Standard \family typewriter ssh cuentas /etc/init.d/lpd restart \end_deeper \layout Subsection Comprobar y gestionar la cola de correo electrónico \layout Standard Del mismo modo que el operador gestiona las colas de las impresoras, también puede gestionar la cola de correo electrónico. Algunas operaciones que puede efectuar son: \layout Itemize Comprobar el estado de las colas: \begin_deeper \layout Standard \family typewriter ssh cuentas mailq \layout Standard \family typewriter ssh www mailq \end_deeper \layout Itemize En caso de que haya muchos mensajes en la cola, habrá que mirar los archivos de registro implicados, en cada uno de los servidores: \begin_deeper \layout Standard \family typewriter ssh cuentas less /var/log/maillog \layout Standard \family typewriter ssh www less /var/log/maillog \end_deeper \layout Itemize 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: \begin_deeper \layout Standard \family typewriter ssh cuentas /usr/sbin/sendmail -v -qR \layout Standard \family typewriter ssh www /usr/sbin/sendmail -v -qR \layout Standard 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. \end_deeper \layout Itemize Para reiniciar los servidores de correo: \begin_deeper \layout Standard \family typewriter ssh cuentas /etc/init.d/sendmail restart \layout Standard \family typewriter ssh www /etc/init.d/sendmail restart \end_deeper \layout Subsection \begin_inset LatexCommand \label{sub:Dar-de-alta-cli-y-serv} \end_inset Dar de alta nuevos clientes y servidores \layout Standard 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): \layout Itemize Primera fase (a realizar en la máquina central de administración del DIT): \layout Enumerate 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\SpecialChar \- lidad y dirección MAC) de la máquina en un fichero de texto ( \family typewriter /etc/tabla.numeros \family default ). NOTA: Habrá que tener en cuenta las cabeceras \family typewriter #+ \family default correspondientes a la configuración de los sistemas DHCP y TFTP. \layout Enumerate Se ejecuta el script \family typewriter install.hosts \family default 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). \layout Itemize Segunda fase (a realizar de forma automática en la máquina central de administra ción del laboratorio): \layout Enumerate Se copia en el directorio adecuado de maestro el nuevo archivo de configuración del servicio DHCP del laboratorio ( \family typewriter dhcpd.conf.admin \family default ). \layout Enumerate Se accede a maestro, se entra en el directorio de configuración de DHCP, que está situado bajo el directorio servicios del usuario operador ( \family typewriter maestro:/home/\SpecialChar \- operador/\SpecialChar \- adminis\SpecialChar \- tracion/\SpecialChar \- servicios/\SpecialChar \- arranque\SpecialChar \- _maquinas/\SpecialChar \- dhcpd \family default ) y se ejecuta \family typewriter make install \family default . Esto permite personalizar la configuración del servicio para cada uno de los binarios (en función de lo especificado en el \family typewriter Makefile \family default local). \layout Enumerate Generada la configuración, sólo falta distribuirla a los servidores, para ello hay que ejecutar \family typewriter make rdist \family default desde el mismo directorio. \layout Standard 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 \begin_inset LatexCommand \ref{sub:Modificar-dispositivos} \end_inset . \layout Subsection \begin_inset LatexCommand \label{sub:Modificar-dispositivos} \end_inset Modificar la configuración de dispositivos de un cliente GNU/Linux \layout Standard 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 configurarlo en cada cliente. El sistema de administración guarda esta información en un fichero de texto llamado \family typewriter clients_conf-1.1/lib/dispositivos \family default , que está situado bajo el subdirectorio \family typewriter usrlocallocal \family default del directorio de servicios del usuario operador en la máquina maestro ( \family typewriter maestro:\SpecialChar \- /home/\SpecialChar \- operador/\SpecialChar \- administracion/\SpecialChar \- servicios/\SpecialChar \- usrlocallocal \family default ). \layout Standard 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 en \family typewriter dispositivos \family default 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. \layout Standard \begin_inset Float table placement H wide false collapsed false \layout Standard \align center \begin_inset Tabular \begin_inset Text \layout Standard \family typewriter l001 B-123 imps2 /dev/psaux nvidia nec \end_inset \begin_inset Text \layout Standard \family typewriter l002 B-123 imps2 /dev/psaux ati zenith \end_inset \begin_inset Text \layout Standard \family typewriter [...] \end_inset \end_inset \layout Caption Ejemplo de la línea de descripción de los equipos l001 y l002 en el archivo \family typewriter dispositivos \end_inset \layout Standard Este archivo se distribuye automáticamente y de forma periódica a los binarios a través del \family typewriter cron \family default del sistema principal, pero si resulta necesario distribuirlo en un momento concreto se puede hacer mediante la orden \family typewriter make rdist \family default en el mismo directorio. \layout Standard 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 dispositiv os, esta tarea se realiza a través del script \family typewriter /etc/rc.d/rc.local \family default (véase el punto \begin_inset LatexCommand \ref{sub:perfiles-hardware} \end_inset ). El nombre de máquina, igual que el resto de los parámetros de red, el cliente los aprende a través del DHCP. \layout Subsection Dar de alta nuevos usuarios \layout Standard 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 es \family typewriter labadmin \family default . Su interfaz es a base de menús y el control se realiza a través de los cursores y la tecla [ENTER]. \layout Itemize Crear una cuenta nueva: \begin_deeper \layout Enumerate Ejecutar \family typewriter labadmin \family default en la linea de comandos, entrando como operador en maestro. \layout Enumerate Seleccionar opción: Operar sobre una cuenta concreta \layout Enumerate Seleccionar opción: Dar de alta una cuenta \layout Enumerate Seleccionar un grupo del laboratorio al que pertenecerá el usuario (se listan todos los grupos posibles). \layout Enumerate 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. \layout Enumerate Aceptar los datos \layout Enumerate Seleccionar opción: Salir \end_deeper \layout Itemize Borrar una cuenta existente: \begin_deeper \layout Enumerate Ejecutar \family typewriter labadmin \family default en la linea de comandos, entrando como operador en maestro. \layout Enumerate Seleccionar opción: Operar sobre una cuenta concreta \layout Enumerate Seleccionar opción: Borrar una cuenta \layout Enumerate Especificar el login de la cuenta que se va a eliminar \layout Enumerate Confirmar el borrado \layout Enumerate Seleccionar opción: Salir \end_deeper \layout Chapter Casos de Aplicación \layout Section Los laboratorios del DIT \layout Standard El caso de los laboratorios docentes del DIT tiene unas características particulares que impulsaron con mayor energía el desarrollo de este proyecto. Los puestos de laboratorio son ordenadores 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 comunicaciones). En la tabla \begin_inset LatexCommand \ref{tabla:Necesidades-DIT} \end_inset , se muestran las necesidades específicas de los laboratorios de grado y postgrado de los últimos años. \layout Standard \begin_inset Float table placement tph wide false collapsed false \layout Standard \begin_inset Tabular \begin_inset Text \layout Standard \series bold Asignatura \end_inset \begin_inset Text \layout Standard \series bold Sistema(s) Operativo(s) \end_inset \begin_inset Text \layout Standard \series bold Necesidades Extra \end_inset \begin_inset Text \layout Standard Programación \end_inset \begin_inset Text \layout Standard GNU/Linux \end_inset \begin_inset Text \layout Standard Entorno de programación Java \end_inset \begin_inset Text \layout Standard Programación de Sistemas \end_inset \begin_inset Text \layout Standard GNU/Linux \end_inset \begin_inset Text \layout Standard Entorno de programación Java \end_inset \begin_inset Text \layout Standard Técnicas de Programación \end_inset \begin_inset Text \layout Standard GNU/Linux \end_inset \begin_inset Text \layout Standard Entorno de programación C \end_inset \begin_inset Text \layout Standard Sistemas de Tiempo Real \end_inset \begin_inset Text \layout Standard Específico \end_inset \begin_inset Text \layout Standard Sistema de tiempo real \end_inset \begin_inset Text \layout Standard Software de Comunicaciones \end_inset \begin_inset Text \layout Standard GNU/Linux \end_inset \begin_inset Text \layout Standard Entorno de programación Java \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard Multicast \end_inset \begin_inset Text \layout Standard Redes y Servicios Telemáticos \end_inset \begin_inset Text \layout Standard GNU/Linux \end_inset \begin_inset Text \layout Standard Simulador NS, conexión a routers \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard MS Windows \end_inset \begin_inset Text \layout Standard y otros sistemas de comunicación \end_inset \begin_inset Text \layout Standard Ingeniería del Software \end_inset \begin_inset Text \layout Standard GNU/Linux \end_inset \begin_inset Text \layout Standard Herramientas CASE y ofimáticas \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard MS Windows \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard Sistemas Inteligentes \end_inset \begin_inset Text \layout Standard GNU/Linux \end_inset \begin_inset Text \layout Standard Entorno de programación Java \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard MS Windows \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard Administración de Sistemas \end_inset \begin_inset Text \layout Standard GNU/Linux \end_inset \begin_inset Text \layout Standard Posibilidad de instalar S.O. \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard en la máquina cliente \end_inset \begin_inset Text \layout Standard Transmisión Digital \end_inset \begin_inset Text \layout Standard GNU/Linux \end_inset \begin_inset Text \layout Standard Entorno de programación C \end_inset \begin_inset Text \layout Standard Conmutación de Circuitos \end_inset \begin_inset Text \layout Standard GNU/Linux \end_inset \begin_inset Text \layout Standard Simulador NS \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard MS Windows \end_inset \begin_inset Text \layout Standard \end_inset \end_inset \layout Caption \begin_inset LatexCommand \label{tabla:Necesidades-DIT} \end_inset Necesidades específicas de los laboratorios de grado por asignatura \end_inset \layout Standard Además, los laboratorios docentes del DIT son utilizados también por otros grupos de alumnos de la ETSIT y cuyas necesidades se basan en el acceso a Internet y la utilización de los programas ofimáticos disponibles: \layout Enumerate Monitores de Laboratorio \layout Enumerate Alumnos Erasmus y de otros Programas de Intercambio \layout Enumerate Alumnos de Proyecto Fin de Carrera \layout Enumerate Alumnos de Doctorado \layout Standard 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. \layout Standard 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 \begin_inset Quotes eld \end_inset logins \begin_inset Quotes erd \end_inset ) 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). \layout Standard 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 gestionar 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 administrac ión centra\SpecialChar \- lizada no habría sido posible dar servicio con una calidad razonable a la cantidad de usuarios de los laboratorios del DIT. \layout Standard 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. \layout Standard 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\SpecialChar \- 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 desprecia ble. \layout Standard 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. \layout Standard 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. \layout Standard 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. \layout Standard 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. \layout Section La red de producción del DIT \layout Standard 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 departamento, 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 laboratorio s docentes. \layout Standard Si tenemos en cuenta que -como media- habrá un reparto de 0.75 ordenadores de uso personal 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. \layout Standard 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. \layout Standard 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: \layout Itemize gestión de impresoras compartidas, \layout Itemize gestión de servidores de correo, \layout Itemize compartición de recursos con otros usuarios, \layout Itemize gestión del acceso a Internet, \layout Itemize administración de servicios para la navegación en Internet, \layout Itemize recuperación de datos destruidos o borrados, \layout Itemize gestión del acceso inalámbrico a la red, \layout Itemize seguridad en el uso de Internet (virus, gusanos, troyanos, puertas traseras, ataques, denegación de servicio...), \layout Itemize gestión de actualizaciones, \layout Standard y, en general, todos aquellos susceptibles de dar un servicio de red. Estas tareas de administració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\SpecialChar \- lizadamente. Como dato, baste decir, que en la red de producción del DIT se instalan, gestionan, mantienen y actualizan más de 30 servidores de todo tipo, principalm ente basados en GNU/Linux, que se encargan de ofrecer esos servicios comunes a los que hacíamos mención. \layout Standard Otro factor que nos impulsa a generalizar el uso de la administración centraliza da 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. \layout Standard Por todo ello, desde el año 2002, se están aplicando los conocimientos desarroll ados a través del sistema de gestión centralizada de los laboratorios docentes para instalar y administrar tambié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. \layout Chapter Conclusiones y Trabajos Futuros \layout Section Análisis del cumplimiento de objetivos \layout Standard Analizaremos en esta sección el grado de cumplimiento de los objetivos planteado s para este proyecto. \layout Itemize 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. \layout Itemize Administración cero: Si entendemos por administración cero \begin_inset Quotes sld \end_inset 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 \begin_inset Quotes srd \end_inset , 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. \layout Itemize 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 alumnos), dado que es posible que el usuario inicie el proceso de reinstalación o regeneración 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 automatizada del equipo se le ofrece al usuario mediante el menú de arranque que se le proporciona a través de la red. \layout Itemize 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 laboratorios 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 embargo, hay constancia de que es una tarea que se ha realizado innumerable s 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 fiabilidad (salvo en los casos de fallo hardware, obviamente) por lo que podemos considera r este objetivo como uno más de los cumplidos. \layout Itemize Reproducción de estado: El sistema de administración centralizada ha permitido gestionar los ordenadores clientes que se usan para realizar tareas de programación avanzada, programación de entorno de red, configuración de redes y realización de simulaciones, 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 ordenadores 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 centralizad a altamente expansible y reproducible. \layout Itemize 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. \layout Itemize Rapidez del proceso: La gestión centralizada de los ordenadores del laboratorio ha permitido la reinstalación de GNU/Linux desde la red en escasos minutos, un tiempo extremadamente 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 operativo, no basta con la regeneración, sino que también hay que dedicar algún tiempo a la autoconfiguración del mismo. \begin_deeper \layout Standard La reinstalación de servidores mediante el sistema de administración centralizad a, 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. \layout Standard Aunque en esta versión del sistema de gestión no se han incluido mecanismos de distribució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. \end_deeper \layout Itemize 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 regenerar se todos los ordenadores cliente del laboratorio. La única excepció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. \layout Itemize Independencia: El sistema de administración centralizada es, por su concepción y dise\SpecialChar \- ñ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 necesitar a 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. \layout Itemize 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. \layout Itemize 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 mismos 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 secundario 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\SpecialChar \- lizada es un sistema sostenible. Incluso, es posible la generación de dominios de aplicación como los que se han creado en el DIT, uno para los laboratorios docentes y otro para la red de producción. \layout Itemize Eficiencia: Aunque resulta difícil medir el grado de eficiencia que ha introduci do el sistema 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 proporcionarle un entorno mucho más estable y fiable, evitándos e así la mayor parte de los antiguos problemas. \layout Itemize Gestión de los datos personales: Los datos de los usuarios son guardados de forma pe\SpecialChar \- riódica en backups completos, siendo diario el backup incremental a disco. La planificació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 secundarios 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. \layout Section Beneficios extra \layout Standard Se mencionan a continuación los beneficios que ha proporcionado nuestro sistema fuera de sus objetivos principales. \layout Enumerate 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. \layout Enumerate 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. \layout Enumerate 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. \layout Enumerate Gestionar las actualizaciones de los sistemas y subsistemas software del ordenador (tanto 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 gestionados. \layout Enumerate 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. \layout Enumerate 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 permanece 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. \layout Section Limitaciones \layout Itemize 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 principales 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\SpecialChar \- rios para la estandarización de las interfaces hardware, cosa harto difícil debido a las altas tensiones que ya soporta este mercado. \layout Itemize 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. \layout Itemize 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 hardware o software) y de aprovecharlos en el beneficio del sistema. \layout Section Ampliaciones y Trabajos futuros \layout Comment identificación de los problemas, ¿cómo nos aseguramos de que una máquina no tiene problemas?, MCAST para TFTP, distribución de carga, ipv6, gestión automática de VLANes, reseteo automático o a través de web de consolas de routers, filtrado por dirección MAC, firewalling tipo NAT, sistemas de acceso a través de internet a los ficheros y al correo electrónico del laboratorio, sistema de entrega de prácticas certificadas \layout Comment No utilizar la palabra backdoor en plural, pq se muere el lyx cuando se hace la correción ortográfica. \layout Standard 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 continuación por orden de importancia, especificando brevemente ciertos detalles posibles de su implementación. \layout Enumerate Se podrían implementar sistemas más sofisticados para el balanceo de carga de los servidores secundarios. Hoy por hoy, actúan como sistemas independientes, pero podrían llegar a actuar como uno solo gracias a algún tipo de gestor intermedio de carga que repartiese el trabajo uniformemente. \layout Enumerate 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\SpecialChar \- ren\SpecialChar \- cias de funcionalidad serían mínimas, pero la capacidad de la red en cuanto a número de dispositivos direccionables se ampliaría considerable mente. \layout Enumerate 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. \layout Enumerate 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. \layout Enumerate 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. \begin_deeper \layout Standard 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. \end_deeper \layout Enumerate 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. \layout Enumerate 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 broadcast 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. \layout Enumerate 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. \layout Bibliography \bibitem {Replicator} Replicator (conjunto de programas para automatizar la duplicación de un modelo de ordenador que ejecute Debian/GNU Linux). \begin_inset LatexCommand \url{http://replicator.sourceforge.net/} \end_inset \layout Bibliography \bibitem {FAI} FAI (Fully Automatic Installation) para Debian GNU/Linux. \begin_inset LatexCommand \url{http://www.informatik.uni-koeln.de/fai/index.html} \end_inset \layout Bibliography \bibitem {Boots} Sistema de Arranque Remoto para Ordenadores IBM PC y Compatibles. Manuel J. Petit. \begin_inset LatexCommand \url{http://www.dit.upm.es/mpetit/boots/pfc.ps} \end_inset \layout Bibliography \bibitem {jitel} 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. Universidad 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 (Departament d'Enginyeria Telemática, Universidad Politècnica de Catalunya). \layout Bibliography \bibitem {jitel-tomas} 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). \layout Bibliography \bibitem {reservas} Proyecto Fin de Carrera: \begin_inset Quotes sld \end_inset Desarrollo de un sistema distribuido de reserva de recursos de laboratorio \begin_inset Quotes srd \end_inset . José Antonio Mendoza Lorente. ETSIT-UPM. 2000 \layout Bibliography \bibitem {Netboot} Netboot \begin_inset LatexCommand \url{http://netboot.sourceforge.net} \end_inset \layout Bibliography \bibitem {Etherboot} Etherboot \begin_inset LatexCommand \url{http://etherboot.sourceforge.net} \end_inset \layout Bibliography \bibitem {Syslinux} Syslinux \begin_inset LatexCommand \url{http://syslinux.zytor.com/} \end_inset \layout Bibliography \bibitem {Pxelinux} Pxelinux \begin_inset LatexCommand \url{http://syslinux.zytor.com/pxe.php} \end_inset \layout Bibliography \bibitem {PXE} Preboot Execution Environment (PXE) Specification. Septiembre de 1999. \begin_inset LatexCommand \url{ftp://download.intel.com/labs/manage/wfm/download/pxespec.pdf} \end_inset \layout Bibliography \bibitem {DHCP} Dynamic Host Configuration Protocol (DHCP) \begin_inset LatexCommand \url{http://www.ietf.org/rfc/rfc2131.txt} \end_inset \layout Bibliography \bibitem {kickstart} RedHat Kickstart \begin_inset LatexCommand \url{http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/ch-kickstart2.html} \end_inset \layout Bibliography \bibitem {MS-Zero} The \begin_inset Quotes sld \end_inset Zero Administration \begin_inset Quotes srd \end_inset Initiative for Microsoft Windows. \begin_inset LatexCommand \url{http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnentdevgen/html/msdn_zerowin.asp} \end_inset \layout Bibliography \bibitem {MS-NetworkPC} Network PCs - Reducing Total Cost of Ownership While Leveraging the Power and Compatibility of PC Computing \begin_inset LatexCommand \url{http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnentdevgen/html/msdn_netpc.asp} \end_inset \layout Bibliography \bibitem {GNU} Proyecto GNU \begin_inset LatexCommand \url{http://www.gnu.org/} \end_inset \layout Bibliography \bibitem {linux} Núcleo Linux \begin_inset LatexCommand \url{http://www.kernel.org/} \end_inset \layout Bibliography \bibitem {Microsoft} Microsoft \begin_inset LatexCommand \url{http://www.microsoft.com/} \end_inset \layout Bibliography \bibitem {BOOTP} Bootstrap Protocol (BOOTP) \begin_inset LatexCommand \url{http://www.ietf.org/rfc/rfc951.txt} \end_inset \layout Bibliography \bibitem {RARP} A Reverse Address Resolution Protocol (RARP) \begin_inset LatexCommand \url{http://www.ietf.org/rfc/rfc903.txt} \end_inset \layout Bibliography \bibitem {TFTP} Bootstrap loading using TFTP \begin_inset LatexCommand \url{http://www.ietf.org/rfc/rfc783.txt} \end_inset , \begin_inset LatexCommand \url{http://www.ietf.org/rfc/rfc906.txt} \end_inset \layout Bibliography \bibitem {RedHat} RedHat \begin_inset LatexCommand \url{http://www.redhat.com} \end_inset \layout Bibliography \bibitem {Autoit} Autoit \begin_inset LatexCommand \url{http://www.hiddensoft.com/autoit3/} \end_inset \layout Bibliography \bibitem {sysprep} Microsoft System Preparation Tool (Sysprep) \begin_inset LatexCommand \url{http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/windows2000pro/deploy/depopt/sysprep.asp} \end_inset \layout Bibliography \bibitem {samba} Samba \begin_inset LatexCommand \url{http://www.samba.org/} \end_inset \layout Bibliography \bibitem {nfs} Network File System Protocol Specification (NFS) \begin_inset LatexCommand \url{http://www.ietf.org/rfc/rfc1094.txt} \end_inset \layout Bibliography \bibitem {Samba y dominio XP} Rembo Listserver Archives. Asunto del mensaje: Security. Fecha: Junio de 2003. \begin_inset LatexCommand \url{http://listas.us.es/pipermail/rembo/2003-June/000218.html} \end_inset \layout Bibliography \bibitem {rembo} Rembo Auto-Deploy, Rembo Technology SaRL \begin_inset LatexCommand \url{http://www.rembo.com} \end_inset \layout Bibliography \bibitem {GRUB} GRand Unified Bootloader \begin_inset LatexCommand \url{http://www.gnu.org/software/grub/} \end_inset \layout Bibliography \bibitem {remote-boot-mHowto} Linux Remote-Boot mini-HOWTO: Configuring Remote-Boot Workstations with \SpecialChar \- Linux, DOS, Windows 95/98 and Windows NT Marc Vuilleumier Stückelberg, David Clerc v3.26, February 2000 \begin_inset LatexCommand \url{http://cui.unige.ch/info/pc/remote-boot/howto.html} \end_inset \layout Bibliography \bibitem {bp-batch} BP-Batch \begin_inset LatexCommand \url{http://www.bpbatch.org/} \end_inset \layout Bibliography \bibitem {unattended} Unattended \begin_inset LatexCommand \url{http://unattended.sourceforge.net/} \end_inset \layout Bibliography \bibitem {realmen} Real Men Don't Click \begin_inset LatexCommand \url{http://isg.ee.ethz.ch/tools/realmen/} \end_inset \layout Bibliography \bibitem {labmice-unattended} Labmice: Unattended, Automated, and Remote Installations of Windows 2000 \begin_inset LatexCommand \url{http://www.labmice.net/Windows2000/install/unattend_install.htm} \end_inset \layout Bibliography \bibitem {oli-willowhayes} Windows 2000 Unattended Installations and related utilities \begin_inset LatexCommand \url{http://www.willowhayes.co.uk/} \end_inset \layout Bibliography \bibitem {powerquest} Power Quest \begin_inset LatexCommand \url{http://www.powerquest.com/} \end_inset \layout Bibliography \bibitem {norton-ghost} Norton Ghost \begin_inset LatexCommand \url{http://www.symantec.com/sabu/ghost/ghost_personal/} \end_inset \layout Bibliography \bibitem {partimage} Partimage \begin_inset LatexCommand \url{http://www.partimage.org/} \end_inset \layout Bibliography \bibitem {winstallle} Windows WinInstall LE ("limited edition") \begin_inset LatexCommand \url{http://ftp.support.veritas.com/pub/support/products/WinINSTALL_LE/247602.pdf} \end_inset \layout Bibliography \bibitem {aefdisk} Aefdisk \begin_inset LatexCommand \url{http://www.aefdisk.com/} \end_inset \layout Bibliography \bibitem {fdisk} Fdisk \begin_inset LatexCommand \url{http://cvs.kerneli.org/util-linux/fdisk/} \end_inset \layout Bibliography \bibitem {lilo} Linux Loader (LILO) \begin_inset LatexCommand \url{http://brun.dyndns.org/} \end_inset \begin_inset LatexCommand \url{http://www.advogato.org/proj/lilo/} \end_inset \layout Bibliography \bibitem {knoppix} Knoppix - Live Linux Debian CD \begin_inset LatexCommand \url{http://www.knoppix.org/} \end_inset \layout Bibliography \bibitem {squid} SQUID Web Proxy Cache \begin_inset LatexCommand \url{http://www.squid-cache.org/} \end_inset \layout Bibliography \bibitem {iptables} Netfilter Iptables \begin_inset LatexCommand \url{http://www.netfilter.org/} \end_inset \layout Bibliography \bibitem {fwbuilder} Firewall Builder \begin_inset LatexCommand \url{http://www.fwbuilder.org/} \end_inset \layout Bibliography \bibitem {ISC} Internet Software Consortium \begin_inset LatexCommand \url{http://www.isc.org} \end_inset \layout Bibliography \bibitem {VLAN} ANSI/IEEE Standard 802.1Q, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", 1998. (VLAN 802.1q) ISBN: 0-7381-3663-8. \layout Bibliography \bibitem {sed} Sed \begin_inset LatexCommand \url{http://www.gnu.org/directory/sed.html} \end_inset \layout Bibliography \bibitem {make} Make \begin_inset LatexCommand \url{http://www.gnu.org/directory/make.html} \end_inset \layout Bibliography \bibitem {rdist} Rdist \begin_inset LatexCommand \url{http://www.magnicomp.com/rdist/} \end_inset \layout Bibliography \bibitem {rsync} Rsync \begin_inset LatexCommand \url{http://samba.anu.edu.au/rsync/index.html} \end_inset \layout Bibliography \bibitem {nilo} Network Interface Loader (NILO) \begin_inset LatexCommand \url{http://www.nilo.org/} \end_inset \layout Bibliography \bibitem {sudo} Superuser Do (sudo) \begin_inset LatexCommand \url{http://www.courtesan.com/sudo/} \end_inset \layout Bibliography \bibitem {kickstart-tools} Kickstart Tools \begin_inset LatexCommand \url{http://kickstart-tools.sourceforge.net} \end_inset \layout Bibliography \bibitem {autoupdate} Autoupdate \begin_inset LatexCommand \url{http://www.mat.univie.ac.at/~gerald/ftp/autoupdate/} \end_inset \layout Bibliography \bibitem {analog} Analog \begin_inset LatexCommand \url{http://www.analog.cx/} \end_inset \layout Bibliography \bibitem {nmap} Network Mapper (nmap) \begin_inset LatexCommand \url{http://www.insecure.org/nmap/} \end_inset \layout Bibliography \bibitem {printquota} Printquota \begin_inset LatexCommand \url{http://printquota.sourceforge.net/} \end_inset \layout Bibliography \bibitem {bart-bootdisk} Bart's Network Boot Disk \begin_inset LatexCommand \url{http://www.nu2.nu/bootdisk/network/} \end_inset \layout Bibliography \bibitem {unattended-install} Unattended Install of Windows 2000. Karl Bernard, University of Houston, Information Technology, Texas. \begin_inset LatexCommand \url{http://www.uh.edu/windows2000/docs/Unattended_Install.doc} \end_inset \layout Bibliography \bibitem {pjpg-autoinst} Autoinstalación de Windows XP. Pedro Jesús Pérez García. DIT-UPM. \begin_inset LatexCommand \url{http://oasis.dit.upm.es/~pjpg/autoinst/} \end_inset \layout Bibliography \bibitem {xfree} The XFree86 Project, Inc. \begin_inset LatexCommand \url{http://www.xfree.org} \end_inset \layout Bibliography \bibitem {rom-o-matic} ROM-O-MATIC \begin_inset LatexCommand \url{http://www.rom-o-matic.org/} \end_inset \layout Chapter* Pliego de condiciones \layout Standard \begin_inset ERT status Inlined \layout Standard \backslash setcounter{chapter}{9} \layout Standard \backslash lhead{Pliego de condiciones} \layout Standard \backslash addcontentsline{toc}{chapter}{Pliego de condiciones} \end_inset \layout Section* Requisitos hardware \layout Itemize 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. \layout Itemize 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. \layout Itemize Acceso a Internet \layout Section* Requisitos software \layout Itemize Discos de instalación de Windows XP Professional y de RedHat 7.3 GNU/Linux. Licencia de Windows XP. \layout Itemize \pagebreak_bottom Discos de instalación del software ofimático y de aplicación específica, así como de sus licencias de utilización. \layout Chapter* Presupuesto \layout Standard \begin_inset ERT status Inlined \layout Standard \backslash setcounter{chapter}{10} \layout Standard \backslash lhead{Presupuesto} \layout Standard \backslash addcontentsline{toc}{chapter}{Presupuesto} \end_inset \layout Standard Este proyecto se ha desarrollado dentro del Centro de Cálculo del Departamento de Ingeniería de Sistemas Telemáticos de la Universidad Politécnica de Madrid. \layout Section* Costes \layout Standard A continuación se dividen los costes de ejecución material en costes de equipamiento (o costes materiales) y costes de mano de obra. \layout Section* Costes Materiales \layout Standard 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 centralizada 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 introducidos 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. \layout Standard En las siguientes tablas de coste se desglosan los costes por equipo. \layout Standard \begin_inset Float table placement H wide false collapsed false \layout Standard \align center \begin_inset Tabular \begin_inset Text \layout Standard \series bold Material \end_inset \begin_inset Text \layout Standard \series bold Coste (euros) \end_inset \begin_inset Text \layout Standard 24-port 10/100 Switch w/Two Module Slots \end_inset \begin_inset Text \layout Standard 4.400 \end_inset \begin_inset Text \layout Standard 2-port 100BaseFX ISL/802.1Q Switch Module \end_inset \begin_inset Text \layout Standard 1.734 \end_inset \begin_inset Text \layout Standard \series bold Total \end_inset \begin_inset Text \layout Standard \series bold 6.134 \end_inset \end_inset \layout Caption Conmutador Ethernet Cisco Catalyst 2900 (WS-C2924M-XL-EN) \end_inset \layout Standard \begin_inset Float table placement H wide false collapsed false \layout Standard \align center \begin_inset Tabular \begin_inset Text \layout Standard \series bold Material \end_inset \begin_inset Text \layout Standard \series bold Coste (euros) \end_inset \begin_inset Text \layout Standard \series bold Uso (%) \end_inset \begin_inset Text \layout Standard \series bold Coste final (euros) \end_inset \begin_inset Text \layout Standard 2 PC Intel Pentium III 850MHz \end_inset \begin_inset Text \layout Standard 1.800 \end_inset \begin_inset Text \layout Standard 100 \end_inset \begin_inset Text \layout Standard 1.800 \end_inset \begin_inset Text \layout Standard 1 Licencia de Windows XP Professional \end_inset \begin_inset Text \layout Standard 260 \end_inset \begin_inset Text \layout Standard 100 \end_inset \begin_inset Text \layout Standard 260 \end_inset \begin_inset Text \layout Standard 1 Licencia de Office XP \end_inset \begin_inset Text \layout Standard 340 \end_inset \begin_inset Text \layout Standard 100 \end_inset \begin_inset Text \layout Standard 340 \end_inset \begin_inset Text \layout Standard 1 Conmutador Ethernet Cisco Catalyst 2900 \end_inset \begin_inset Text \layout Standard 6.134 \end_inset \begin_inset Text \layout Standard 5 \end_inset \begin_inset Text \layout Standard 306,70 \end_inset \begin_inset Text \layout Standard \series bold Total \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \series bold 2.706,70 \end_inset \end_inset \layout Caption Costes de Material Total \end_inset \layout Section* Costes de Mano de Obra \layout Standard 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. \layout Standard \begin_inset Float table placement H wide false collapsed false \layout Standard \align center \begin_inset Tabular \begin_inset Text \layout Standard \series bold Tarea \end_inset \begin_inset Text \layout Standard \series bold Duración (horas) \end_inset \begin_inset Text \layout Standard Estudio previo sobre sistemas de arranque remoto \end_inset \begin_inset Text \layout Standard 120 \end_inset \begin_inset Text \layout Standard Estudio previo sobre implementaciones comerciales \end_inset \begin_inset Text \layout Standard 70 \end_inset \begin_inset Text \layout Standard Instalación de sistemas finales \end_inset \begin_inset Text \layout Standard 200 \end_inset \begin_inset Text \layout Standard Definición del modelo \end_inset \begin_inset Text \layout Standard 30 \end_inset \begin_inset Text \layout Standard Implementación del escenario de pruebas \end_inset \begin_inset Text \layout Standard 10 \end_inset \begin_inset Text \layout Standard Desarrollo de aplicaciones específicas \end_inset \begin_inset Text \layout Standard 200 \end_inset \begin_inset Text \layout Standard Pruebas \end_inset \begin_inset Text \layout Standard 100 \end_inset \begin_inset Text \layout Standard Elaboración de la memoria \end_inset \begin_inset Text \layout Standard 300 \end_inset \begin_inset Text \layout Standard \series bold Total \end_inset \begin_inset Text \layout Standard \series bold 1.030 \end_inset \end_inset \layout Caption Horas de Mano de Obra \end_inset \layout Standard Multiplicando por el sueldo por hora de un Ingeniero, se obtiene el coste total de la mano de obra. \layout Standard \begin_inset Float table placement H wide false collapsed false \layout Standard \align center \begin_inset Tabular \begin_inset Text \layout Standard \series bold Responsable \end_inset \begin_inset Text \layout Standard \series bold Tiempo \end_inset \begin_inset Text \layout Standard \series bold Coste \end_inset \begin_inset Text \layout Standard \series bold Total \end_inset \begin_inset Text \layout Standard Ingeniero Superior \end_inset \begin_inset Text \layout Standard 1.030 horas \end_inset \begin_inset Text \layout Standard 30 euros/hora \end_inset \begin_inset Text \layout Standard \series bold 30.900 euros \end_inset \end_inset \layout Caption Costes de Mano de Obra \end_inset \layout Section* Gastos Generales \layout Standard 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. \layout Section* Presupuesto total \layout Standard \begin_inset Float table placement H wide false collapsed false \layout Standard \align center \begin_inset Tabular \begin_inset Text \layout Standard \series bold Concepto \end_inset \begin_inset Text \layout Standard \series bold Coste (euros) \end_inset \begin_inset Text \layout Standard Coste material \end_inset \begin_inset Text \layout Standard 2.706,70 \end_inset \begin_inset Text \layout Standard Coste de mano de obra \end_inset \begin_inset Text \layout Standard 30.900 \end_inset \begin_inset Text \layout Standard \series bold Presupuesto de ejecución material \end_inset \begin_inset Text \layout Standard 33.606,70 \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard Gastos generales \end_inset \begin_inset Text \layout Standard 5.041 \end_inset \begin_inset Text \layout Standard \series bold Presupuesto de ejecución \end_inset \begin_inset Text \layout Standard 38.647,70 \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard \end_inset \begin_inset Text \layout Standard IVA (16%) \end_inset \begin_inset Text \layout Standard 6.183,63 \end_inset \begin_inset Text \layout Standard \series bold TOTAL \end_inset \begin_inset Text \layout Standard \series bold 44.831,33 \end_inset \end_inset \layout Caption Presupuesto Total \end_inset \layout Standard El presupuesto total del proyecto alcanza la cifra de CUARENTA Y CUATRO MIL OCHO\SpecialChar \- CIENTOS TREINTA Y UN EUROS CON TREINTA Y TRES CÉNTIMOS. \layout Standard \added_space_top 3cm \align right Madrid, 22 de julio de 2003 \layout Standard \align right EL INGENIERO PROYECTISTA \layout Standard \added_space_top 5cm \align right Fdo. Omar Aurelio Walid Llorente \the_end