• No results found

Para determinar la idoneidad del método analizado en este trabajo se realizó una comparación entre la instalación de sistemas operativos por imagen y la utilización de un servidor de instalaciones desatendidas y automatizadas determinándose que:

Una clonación realizada con Symantec Ghost de una computadora previamente instalada con Windows, utilizando la herramienta Autoit para instalarle programas necesarios, tales como Microsoft Office XP, WinAmp, WinRar, Codecs K-lite,

Kaspersky Anti-virus 6.0 Windows Workstations, Adobe Reader X, Enciclopedia Encarta 2006 y actualizaciones del sistema operativo pudiera ser regenerada en otra PC en un tiempo estimado de 10 a 15 minutos en dependencia del volumen de la imagen. Este tiempo resulta aproximadamente igual al realizarle también una clonación a un ordenador instalado con el paquete convencional de Ubuntu

utilizando Partimage o Clonezilla y después regenerar este en otras máquinas. Pero este método tiene un inconveniente, mientras más aplicaciones tenga instalada la máquina que se clonará, más grande será la imagen que se obtendrá y por tanto mayor será el espacio que se requerirá para almacenarla, necesitándose un servidor con amplia capacidad de disco duro y además para

Windows sería un problema pues si se administra una red con máquinas diferentes la instalación de los drivers complicaría el proceso.

Por tanto el método óptimo es el que se plantea en este proyecto que consiste en instalaciones desatendidas y automatizadas mediante un servidor maestro, la instalación de un sistema operativo GNU/Linux en una PC tardaría alrededor de 10 minutos, mientras que el proceso de reconfiguración posterior demoraría otros 10 minutos en función de la cantidad de aplicaciones que el servidor maestro le tenga que distribuir, la instalación de un ordenador con Windows demora alrededor de 40 minutos pero con la ventaja de que ya se dispondrán de aplicaciones y drivers

cuando se inicialice el sistema, permitiendo que con la automatización del proceso no sea necesario que el técnico al frente del laboratorio esté delante de la computadora durante el procedimiento, sino que incluso se puede configurar de tal forma que el propio usuario de un ordenador decida cuándo y con qué sistema operativo reinstalar esa computadora y no tener que intervenir o responder a alguna pregunta durante el proceso.

3.3 Caso Universidad

Con la necesidad de migrar a software libre debido a que los sistemas operativos y las aplicaciones que utilizan esta tecnología son más económicos gracias a que su licencia es gratuita o se cobra únicamente el costo de distribución, se trabajó en el diseño y creación de un servidor maestro en la UCLV, capaz de brindar un servicio de instalaciones desatendidas y automatizadas utilizando esta tecnología, pero que además permita ofrecer también soporte a Windows para aquellos usuarios que de una forma u otra aún necesiten utilizar este sistema operativo.

Dicho servidor maestro no requirió la creación de un DHCP Server pues se utilizó el existente en la Universidad, pero sí se necesitó modificar el Routers, de la subred en la que se encuentra, para que incluyera en su tabla de direcciones, la dirección del servidor y poder garantizar así que lleguen a él las solicitudes de conexión.

Se creó un servidor TFTP y se instaló el proyecto Syslynux generándose el directorio /var/lib/tftpboot/pxelinux.cfg y configurándose para que los parámetros de arranque (básicamente kernel e initrd), cuyos nombres se corresponden con los IP de cada una de las máquinas a instalar (Ver Anexo II), sean expresados en hexadecimal y además para crear el menú de acceso como se muestra:

create dhcp poli="RED3" lease=60480 add dhcp poli="RED3" subn=255.255.255.0 add dhcp poli="RED3" rou=10.12.3.254

add dhcp poli="RED3" dnss=10.12.1.50,10.12.1.51 add dhcp poli="RED3" do="uclv.edu.cu"

add dhcp poli="RED3" nbna=10.12.1.50,10.12.1.51

add dhcp poli="RED3" server=10.12.3.41 add dhcp poli="RED3" fi="pxelinux.0"

create dhcp ran="RED3" poli="RED3" ip=10.12.3.100 num=100

DEFAULT vesamenu.c32 TIMEOUT 600

ONTIMEOUT BootLocal PROMPT 0

MENU INCLUDE pxelinux.cfg/pxe.cfg NOESCAPE 1

LABEL BootLocal localboot 0 TEXT HELP

Boot to local hard disk ENDTEXT

label debian

menu label ^Automated install 32 bits kernel gru/debian/linux

append auto=true priority=critical url=http://10.12.1.96/pxe- web/dc/debian/squeeze.cfg vga=788 initrd=gru/debian/initrd32.gz -- quiet

TIMEOUT 600- El sistema espera 600 segundos antes de que se produzca una acción predeterminada si el usuario no toma ninguna de las opciones mostradas en el menú.

ONTIMEOUT- Indica que acción debe ser tomada cuando expire el TIMEOUT. En este caso se agregó al menú la opción BootLocal, permitiendo que pasado el tiempo predefinido, si el usuario no toma una de las opciones mostradas en el menú, el sistema intentará iniciar desde un disco local.

MENU INCLUDE pxelinux.cfg/pxe.conf- Carga opciones de configuración adicional desde otro archivo (como el color usado en el menú o el número de opciones desplegadas, etc).

NOESCAPE 1 - No permite que el usuario salga fuera del sistema de menú. LABEL – Es la forma de referirse al menú mediante una etiqueta.

Además la línea resaltada señala la dirección del fichero que contiene el instalador propio del sistema operativo, en este caso se utiliza un fichero preseed de Debian

el cual debe ser modificado manualmente. Para realizar esto se debe disponer de un instalador Debian previamente configurado como se muestra:

Para el caso de Ubuntu se realiza aproximadamente igual la operación antes descrita, solo varía la dirección desde donde se obtendrá el instalador (que se copia dentro del mismo directorio var/lib/tftpboot/) y que este sistema utiliza para

cd /tmp wget http://ftp.de.debian.org/debian/dists/squeeze/main/installer- i386/current/images/netboot/netboot.tar.gz tar –xzvf netboot.tar.gz mkdir –p /var/lib/tftpboot/debian/ cp /tmp/debian-installer/i386/initrd.gz /var/lib/tftpboot/debian/ cp /tmp/debian-installer/i386/linux /var/lib/tftpboot/debian/ cp /tmp/debian-installer/i386/pxelinux.0 /var/lib/tftpboot/debian/

instalar desatendidamente un fichero kickstart, aunque también se pudiera configurar un fichero preseed para Ubuntu, aunque el kickstart es más fácil de modificar porque todo se realiza desde una interfaz.

La instalación de Windows es un poco más difícil de desarrollar pues éste no utiliza la misma filosofía de trabajo que GNU\Linux, el primero debe obtener los recursos que necesita a través de una carpeta compartida y el segundo por lo general lo realiza a través de una página Web.

Para que el servidor maestro dispusiera de la opción de instalar Windows se necesita un ISO con el instalador de este sistema operativo copiado en el directorio var/lib/tftpboot/winxp. La imagen se crea previamente con la herramienta

nLite (Ver Anexos III, IV y V), se le eliminan las aplicaciones innecesarias y se le incluyó un paquete de programas y drivers atendiendo a las necesidades de las computadoras que se desean instalar.

Además se necesita configurar el archivo smb.conf que se encuentra en la dirección /etc/samba/smb.conf perteneciente al servidor Samba para que pueda ser compartido (shared) el directorio que contiene el instalador.

mkdir /mnt/iso

mount xpsp3.iso /mnt/iso

mkdir –p /var/lib/tftpboot/winxp/i386/ cd /mnt/iso/i386

cp -av * /var/lib/tftpboot/winxp/i386/ label kubuntu

menu label Automated install ^kubuntu kernel ubuntu/linux

append vga=normal ks=http://10.12.1.96/ks-kubuntu.cfg

También se necesita generar y configurar un archivo de respuesta /var/lib/tftpboot/winxp/winxp.sif para garantizar que el proceso de instalación sea desatendido.

Por último se crea y configura el servidor Puppet (Puppetmaster) para el despliegue de nuevos paquetes o la configuración de la distribución Linux que se encuentre instalada. Puppet se instala en /etc/default/puppet y por defecto el

/etc/samba/smb.conf [Global] workgroup = WORKGROUP [ris] path = /var/lib/tftpboot/winxp browsable = true

read only = yes writable = no guest ok = yes [Data] AutoPartition=1 MsDosInitiated="0" AutomaticUpdates=yes UnattendedInstall="Yes" floppyless="1" [UserData]

;Put here your product key

ProductKey=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX FullName="ICT"

OrgName="University" ComputerName=* [Display]

fichero que genera está diseñado de forma que no permite el arranque hasta tanto no sea modificado.

Para que el Puppetmaster funcione es necesario configurarle la opción del arranque, como se muestra en esta sección perteneciente a un archivo de configuración Kickstart.

/etc/default/puppet

# Defaults for puppet - sourced by /etc/init.d/puppet # Start puppet on boot?

START=no

# Startup options DAEMON_OPTS=""

#Network information

network --bootproto=bootp --device=eth0 #Firewall configuration

firewall --disabled

#X Window System configuration information skipx

#Package install information %packages @ openssh-server @ ubuntu-desktop build-essential thunderbird pidgin @system-tools puppet %post

Después que el Puppetmaster se reinicie se procede a crear las configuraciones que se necesitan en dependencia de la subred a la que se le brindará servicio. Estas configuraciones serán las que descarguen los clientes de puppet para actualizar sus sistemas. Lo que se muestra a continuación son dos configuraciones creadas, la primera es una aplicación para realizar la administración del sistema (sudo) donde se instale y la segundo se utiliza para los tiempos de sincronismo (ntp) del cliente :

class sudo { package {sudo: ensure => present, } file { "/etc/sudoers": owner => "root", group => "root", mode => 0440, source => "puppet://puppet.uclv.edu.cu/modules/sudo/sudoers", require => Package["sudo"], } class ntp::config { file { "/etc/ntp.conf": owner => "root", group => "root", mode => 0440, source => "puppet://puppet.uclv.edu.cu/modules/ntp/ntp.conf", require =>Class["ntp::install"], notify => Class["ntp::service"], }

Actualmente está en funcionamiento en la Universidad este servidor maestro, pero solo se está utilizando para dar soporte a Debian o Ubuntu, específicamente al nuevo Datacenter y a los servidores centrales ubicados en la Puerta, los cuales utilizan estos sistemas operativos (Ver Anexos VI y VII).

3.4 Conclusiones

En este capítulo se ha demostrado la utilidad que posee un servidor especializado en instalaciones desatendidas, su aplicabilidad y funcionalidad debido a que este sistema ahorra tiempo no sólo al personal responsable del servicio, sino también el propio usuario al que le proporciona un entorno más fiable y seguro, permitiendo que pueda ser usado incluso por personas con poca experiencia.

CONCLUSIONES Y RECOMENDACIONES

Conclusiones

En este proyecto se abordó la problemática que existe a la hora de instalar múltiples estaciones. El sistema diseñado ha permitido realizar la reinstalación desatendida y automatizada de varios equipos.

Aunque resulta difícil medir el grado de eficiencia que ha introducido el sistema de instalación desatendida y automatizada, podría decirse que supera con creces las variantes utilizadas hasta el momento debido a que permite la ampliación de los servicios en una red dada sin necesidad de variar el hardware del servidor maestro, pues a consecuencia del abaratamiento de costes ha ocurrido un aumento vertiginoso del número de computadoras (tanto portátiles como de oficina) en los últimos años y además no requerirá más personal cualificado cuando aumente el número de ordenadores administrados, ya que normalmente el personal técnico asignado a un determinado servicio está limitado por razones de presupuesto. Además este método ha significado un ahorro en tiempo notable

La gestión centralizada ha permitido la instalación de GNU/Linux desde la red en un tiempo extremadamente breve en comparación con el tiempo de instalación que se deriva de otras formas. La instalación de Windows 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, es algo más complicado la configuración del servidor de instalaciones desatendidas y automatizadas para que realice este proceso.

Con este método no se necesita utilizar una torre de CD, ventaja muy importante para la Universidad Central “Marta Abreu” de Las Villas pues muchas de las máquinas que se encuentran en los laboratorios no disponen de dichas torres o no le funcionan.

Como limitación fundamental de este sistema se debe resaltar la diversidad de

hardware existente en el mercado, lo que hace que exista una cantidad enorme de

drivers para estos dispositivos que requeriría cambiar la imagen de la instalación de Windows cada vez que se necesite dar soporte a una computadora con un

Recomendaciones

Hay varios objetivos que se han planteado para realizar en un futuro y ampliar la capacidad, gestión e inteligencia del sistema de administración desatendida y automatizada. A continuación se mencionan especificando algunos aspectos de su implementación.

 Mantener un estudio constante para estar actualizados con las nuevas versiones de las herramientas utilizadas y así lograr un sistema más estable, rápido y seguro.

 Implementación en redes de datos de tipo IPv6. Para ello habrá que utilizar servidores que soporten este protocolo. Las diferencias de funcionalidad son mínimas, pero la capacidad de la red en cuanto a número de dispositivos direccionables se amplían considerablemente y por lo tanto la calidad del servicio se mejora en el tiempo final de instalación.

 Impartir cursos de superación sobre el tema a los administradores y técnicos de laboratorio, con el objetivo de optimizar las labores de administración.

 Lograr que el sistema de administración centralizada llegue a ser lo más autónomo posible, 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.

 Extender el servicio a todas las subredes de la Universidad Central “Marta Abreu” de Las Villas para facilitar el trabajo de los administradores de red de cada área.

REFERENCIAS BIBLIOGRÁFICAS

AEFDISK. 2003. Available: http://www.aefdisk.com/. ALANOLL. 2011. Winnt.sif reference. Available:

http://unattended.msfn.org/unattended.xp/view/web/19/#data.

ALINAS. 2002. Automated Remote Installs of Ubuntu using Kickstart. Available:

http://www.linuxquestions.org/questions/linux-newbie-8/automated-remote-installs-

of-ubuntu-using-kickstart-802660/.

APPLE. 2012. MacOS. Available: www.apple.com/es/macosx/.

AUTOIT. 1999. Available: http://www.autoitscript.com/autoit3/index.php.

BARBERÁN, V. A. 2012. Partimage. Creación de copias de seguridad de particiones.

COMER, D. E. 1996. Redes Globales de información con Internet y TCP/IP. Principios básicos, protocolos y arquitectura. In: CEDEÑO, L. G. (ed.).

CROFT, B. 1985. Bootstrap Protocol (BOOTP). Available:

http://www.ietf.org/rfc/rfc951.txt.

DANAE. 2006. Available: http://www.daboweb.com/.

DAVIE, L. L. P. B. S. 2003. Computer Networks. In: PUBLISHERS, M. K. (ed.) A Systems Approach. 3 ed.

JOHN. 2009. Puppet Tutorial for Linux:Powering up with Puppet [Online]. Available:

http://bitfieldconsulting.com/puppet-tutorial-2.

LANDMANN, R. 2011. Red Hat Enterprise Linux 6. Guia de Instalación.

LÁZARO, R. D. 2012. Servidor de Instalaciones. Available: http://rdlazaro.info/compu-

sistemas-servidor_instalacones.html.

LINUX. 2012. Clonezilla. Available: http:\\www.linuxlinks.com\Disk-Cloning\Clonezilla. LOOPE, J. 2011. Managing Infrastructure with Puppet. In: O’REILLY MEDIA, I. (ed.). LLORENTE, O. A. W. 2003. Implementación de un Sistema de Gestión para

Laboratorios Docentes. Universidad Politécnica de Madrid.

MCCARTY, B. 1999. Learning Debian GNU\Linux. In: O’REILLY AND ASSOCIATES, I. (ed.) 1ra Edición ed.

MICROSOFT. 2004. How To Use Setup Manager to Create an Answer File in Windows. Available: http://support.microsoft.com/?kbid=308662.

MICROSOFT. 2005. How to use the Sysprep tool to automate successful deployment of Windows. Available: http://support.microsoft.com.

PALIZA, F. A. 2012. Protocolos del nivel de aplicacion DNS-DHCP (2da parte). PET, R. V. 2010. Curso Avanzado deGNU\Linux

Métodos de instalacion avanzados. Santiago de Compostela. SYMANTEC. 2006. Key Features [Online]. Available:

http://www.symantec.com/home_homeoffice/products/features.jsp?pcid=sp&pvid=

pm80.

TECHNET. 2012. Automating and Customizing Installations [Online]. Available:

http://technet.microsoft.com/es-es/library/bb457100%28en-us%29.aspx.

TURNBULL, J. 2011. Pro Puppet. In: MEDIA, S. S. B. (ed.). UBUNTU. 2012. GRUB [Online]. Available: http://www.guia-

ubuntu.org/index.php?title=GRUB.

UTARD, M. 2008. Maestría en Ingeniería en Telecomunicaciones. Universidad de Buenos Aires.

VIDYADHAR. 2010. PXE booting Windows XP Installation [Online]. Available:

http://www.techienote.com/2010/06/pxe-booting-windows-xp-installation.html.

VIKLUND, A. 2010. how to unattended ubuntu network install preseed [Online]. Available: http://www.debuntu.org/how-to-unattended-ubuntu-preseed-install. WINDOWS. 2012. Available: http://windows.microsoft.com/es-ES/windows/downloads.

ANEXOS

Anexo II

Anexo III

Anexo IV

Anexo VI