650 likes | 743 Views
CURSO DE INICIACIÓN A REMBO. Servicio de Informática y Comunicaciones Universidad de Zaragoza. Miguel Angel Villalba Elbaz mavilla@unizar.es. OBJETIVOS DEL CURSO. Conocer qué es un sistema de arranque remoto. Conocer qué es REMBO.
E N D
CURSO DE INICIACIÓN A REMBO Servicio de Informática y Comunicaciones Universidad de Zaragoza Miguel Angel Villalba Elbaz mavilla@unizar.es
OBJETIVOS DEL CURSO • Conocer qué es un sistema de arranque remoto. • Conocer qué es REMBO. • Instalar y configurar un servidor DHCP y el servicio REMBO tanto bajo Windows como bajo Linux. • Clonar y restaurar sistemas operativos con REMBO. • Problemas y soluciones con REMBO.
QUÉ ES UN SISTEMA DE ARRANQUE REMOTO Como su propio nombre indica, es un sistema que permite arrancar una estación de trabajo, conectada a una red, desde un servidor antes de que se inicie cualquier sistema operativo localizado en el disco duro de la estación. Para conseguir el arranque de un cliente desde un servidor son necesarios elementos hardware y software tanto en la parte del cliente como en la parte del servidor. Desde el punto de vista del cliente, es necesario que éste disponga de una tarjeta de red (NIC) con soporte para el arranque remoto y de una BIOS que cumpla la especificación BBS (BIOS Boot Specification)— gracias a la cual se puede especificar en la secuencia de arranque que el ordenador arranque desde la red —. Desde el punto de vista del servidor, es necesario disponer de una tarjeta de red (NIC) con o sin soporte para el arranque remoto, haber instalado un servicio de servidor DHCP y tener instalado algún software para dar soporte de arranque remoto (como por ejemplo REMBO). Otros factores sumamente importantes que van a influir en el arranque remoto serán: el protocolo y medio de transmisión, la topología de la red y factores cualitativos como la existencia de caché en los discos cliente, la existencia de imágenes incrementales o diferenciales, la posibilidad de sincronización como restauración selectiva, la determinación del tiempo de vida de las imágenes, la ubicación única del espacio del usuario y la tolerancia a fallos.
BIOS Basic Input/Output System La BIOS es el elemento encargado de inicializar la parte hardware del ordenador. Una vez entendido qué hace la BIOS, se comprende que es importante escoger un fabricante y modelo de BIOS adecuados, que sea tan flexibles y modulares que permitan tantas opciones como tipos de hardware disponemos. Podemos definir la BIOS como un software, normalmente residente en ROM, encargado de inicializar los periféricos del ordenador y establecer el nexo entre el sistema operativo y el hardware. El circuito ROM en el que está contenido el código de la BIOS, siempre aparece en el segmento superior de la memoria F000h. La posición exacta en el segmento de memoria no esta claramente definida. Ésta dependerá del propio tamaño de la BIOS.
SECUENCIA DE ARRANQUE DE UN PC Al encender un ordenador la BIOS toma el control, empezando a ejecutar automáticamente el código en la posición F000h:FFF0h, a partir de aquí la BIOS hace una serie de comprobaciones y acciones bien sea directamente, bien sea mediante llamadas a funciones. Primero se ejecutarán aquellas instrucciones y/o funciones que comprueban el sistema, y que realizan la inicialización de los diferentes componentes hardware. Esta etapa se conoce como POST ( Power On Self Test ), más adelante podremos ver una descripción más detallada de esta etapa. Después, mediante una interrupción, entramos en la etapa del BootStrap Loader. Esta etapa/función intenta localizar un dispositivo del que cargar un software desde un sitio determinado, que finalmente se encargará de cargar y ejecutar el sistema operativo. Veremos ahora el algoritmo seguido antes de cargar un sistema operativo:
acción encender_ordenador_genérico es Presionar_interruptor; error := BIOS_POST(); fin:=falso; mientras no fin hacer si no error entonces unidad_con_sistema_arranque := BootStrap_Loader(); si no unidad_con_sistema_arranque entonces si existe ROM BASIC entonces salida := ROM_BASIC; fin := cierto; sino caso versión_BIOS de Tipo A: Mensaje( “ Introducir floppy con S.O. “ ); Tipo B: Mensaje_error ( “ Sistema Interrumpido “); Salida := SYSTEM_HALTED; fin:=cierto; fin_caso; fin_si; sino salida := unidad_con_sistema_operativo; fin_si; sino fin := cierto; fin_si; fin_mientras; ejecutar ( salida ); fin_acción;
ETAPA POST DE LA BIOS Comprende diferentes tests referentes al hardware central del PC, como son: procesador, memoria, controlador de interrupciones, DMA, etc. Normalmente, y como aún no podemos considerar la tarjeta de vídeo como si hubiera pasado el test, o bien porque quizás aún no hemos llegado a hacer el test de vídeo, cada BIOS tiene un código de señales acústicas (vía ‘speaker’), que identifican la causa del error, en caso de producirse. Es conveniente identificar el tipo de BIOS del que disponemos y los códigos de error en caso de no encenderse el ordenador. Además, también se inicializan durante el desarrollo de los tests las extensiones del hardware que hay en los slots de expansión. Es decir, todas las tarjetas asociadas al ordenador, como por ejemplo la tarjeta de vídeo, la tarja de red, tarjeta SCSI, etc. De entre los diferentes tests que hace la BIOS, dependiendo del fabricante y versión de BIOS, podemos destacar: comprobación CPU, CMOS clock, DMA, teclado, los primeros 64 Kbytes de RAM, controlador de interrupciones, controlador cache placa madre, controladora de vídeo, memoria superior a los primeros 64 Kbytes, puerto serie y paralelo, disco y disquetera. Una vez la BIOS ha hecho y pasado correctamente todos los tests de hardware, hace la inicialización de variables de la BIOS y la tabla del vector de interrupciones.
La última tarea de la etapa POST de la BIOS es la búsqueda de extensiones ROM. Este proceso, especialmente interesante para nosotros, consiste en hacer una búsqueda por el hardware de slots con circuitería ROM ó EPROM con el propósito de ejecutar el contenido. Normalmente éstos tienen la función de ampliar o sustituir las funciones de la BIOS, como puede ser una tarjeta de vídeo, o cualquier otro tipo de periférico que quizás se limitará a reemplazar/interceptar alguna función de la BIOS referente al periférico y ejecutará una función propia, sustituyendo así la de la BIOS. Éstos se pueden encontrar tanto en placa madre como en alguno de los slots de expansión añadidos al PC. En nuestro caso, estará en la tarjeta de red, y será una EPROM con el código de encendido que se encargará de buscar un servidor y encender el PC según determine el servidor.
SECUENCIA DE ARRANQUE EN UN PC CON EPROM Y CAPACIDAD DE ARRANQUE POR RED Al encender el ordenador la BIOS toma el control, comenzando a ejecutar automáticamente el código en la posición F000h:FFF0h (para un i8088 ), a partir de aquí la BIOS hace toda una serie de comprobaciones y acciones bien sea directamente, bien sea mediante llamadas a funciones. Primero se ejecutarán aquellas instrucciones y/o funciones que comprueban el sistema, y que realizan la inicialización de los diferentes componentes del hardware. Se ejecutarán todas tal y como se ha explicado en el apartado anterior, pero al llegar al punto de buscar extensiones ROM, el código residente en la EPROM de la tarjeta de red toma el control de la BIOS. En este punto, dependiendo de cómo se ha configurado la EPROM, se nos dará la opción de arrancar en red o localmente, si escogemos la opción local continuaremos el paso lógico de la BIOS haciendo la llamada al BootStrap Loader. Por otro lado, si se ha escogido la opción de arranque por red se ejecutará el cliente de BOOTP y de TFTP residentes en la EPROM. El siguiente algoritmo refleja a grandes trazas este flujo de encendido:
acción encender_ordenador_con_etapa_POST_detallada es Presionar_interruptor; error := test_hardware_BIOS_POST(); fin:=falso; si no error entonces mientras no fin hacer hay_eprom_red := búsqueda_extensiones_ROM_BIOS_POST(); si no hay_eprom_red entonces esquema_normal_arranque_BIOS(); sino salida := pasar_control_a_código_EPROM; fin_si; fin_mientras; ejecutar ( salida ); fin_si; fin_acción; Esquema por capas de la posición de la EPROM en el flujo de arranque, quedando claro que intercepta, y sustituye el flujo normal de arranque de la BIOS.
INCOMPATIBILIDAD BIOS CON ARRANQUE REMOTO • En ciertas aulas se ha detectado la incompatibilidad de la versión de la BIOS de los PCs existentes con dicha tarjeta, de forma que al instalar la tarjeta no realiza el arranque desde la red. Eso ocurre con PCs "antiguos" que no tienen una BIOS compatible BBS (BIOS Boot Specification) en la que no se le puede especificar en la secuencia de arranque que primero arranque de la Red. Aunque se han seguido los pasos del manual de usuario de MBA (Managed PC Boot Agent User Guide for Version 4.x, capítulo 3) y se ha utilizado el software NIC Doctor y MBA Config para configurarlo, sigue sin funcionar. • En casos de este tipo, se recomienda: • desactivar la partición primaria del disco duro de manera que la secuencia de arranque pase a la tarjeta de red, para desactivar la partición primaria hay que utilizar algún programa de gestión de particiones distinto a fdisk, ya que este no soporta esta característica. • seguir los pasos del manual de usuarios para BIOS no BBS, que en resumidas cuentas es: • asegurarse de que la tarjeta tiene activada la Boot PROM (se hace con el NIC Doctor bajo Windows)
con la utilidad MBACFG.EXE utilizar la interrupción 19 o 18 en “Startup configuration” y poner “Network” como “Default Boot” en vez de “Local“. • si esto no resulta, intentar actualizar la BIOS a una superior que ya tenga BBS (consultar la web de la placa base correspondiente para ver cómo se hace); por ejemplo, AWARD ofrece una utilidad llamada awflash.exe (o algo parecido) • como último recurso se puede emplear un disquete de arranque, específico para tarjetas 3COM (MBADISK.EXE), que simula el arranque remoto. También es posible generar un disquete de arranque remoto empleando la utilidad que viene incluida en el CD de Microsoft Windows 2000 Server llamada RBFG.EXE. Esta herramienta emula el protocolo PXE v0.98 y sólo funciona para tarjetas PCI.
CONCEPTOS SOBRE REMBO • ¿QUÉ ES REMBO? • REMBO es un programa de arranque remoto por red mediante PXE (Preboot eXecution Environment) Un programa de arranque remoto por red se diferencia de otros programas en una serie de características: • es invocado durante el proceso inicial de arranque de la computadora, antes de cualquier sistema operativo o programa de control del arranque (boot manager) • depende de la presencia de un chip especial localizado en la tarjeta de red: el ‘boot ROM’. • es capaz de usar la red gracias a un entorno programado proporcionado por el chip ‘bootrom’. De echo, el protocolo PXE es el estándar para este tipo de entornos programados. • se puede descargar de un servidor especial de arranque y no depende de ningún tipo de dispositivo de almacenamiento local. Puede trabajar en computadoras sin disco duro, CD-ROM o disquetera. Sin embargo, si se encuentra disponible cualquier dispositivo de almacenamiento local, el programa de arranque remoto por red puede utilizarlo. En cualquier caso, el proceso no se detendrá si ese dispositivo de almacenamiento está dañado o deja de funcionar.
obtiene los parámetros necesarios para su funcionamiento (dirección IP y otros parámetros de arranque) de un servidor DHCP centralizado. • Una vez ejecutado, REMBO actúa como un ‘mini’ sistema operativo. Puede ejecutar diferentes tareas dependiendo de las instrucciones escritas en un programa (denominado ‘script’) englobado dentro de una página HTML (HyperText Markup Language) Estas tareas se pueden dividir en cuatro categorías: ficheros, red, entorno del usuario y sistema. A continuación se muestra una visión global de las tareas más útiles: • Autentificación (validación) de usuarios. REMBO puede permitir o denegar el acceso a una computadora basándose en las credenciales de validación aportadas por el usuario (por lo general un identificador y una clave de acceso o ‘password’) • Acceso a los ficheros independientemente del sistema operativo. Los ficheros pueden ser creados, copiados, borrados, renombrados, etc. REMBO puede acceder a particiones NTFS (Windows NT/2000), FAT16-FAT32 (DOS, Windows 95/98/Me) y EXT2 (UNIX/Linux); y esto puede hacerse antes de que cualquier sistema operativo se haya cargado, lo que permite la manipulación de ficheros que, de otro forma, pudieran estar bloqueados o protegidos por el sistema operativo.
Entorno HTML. REMBO incluye un completo entorno de trabajo basado en HTML, con formularios y hojas de estilo CSS (Control Style Sheet) Los administradores del sistema pueden diseñar el aspecto de REMBO casi sin limitaciones, soportando menús gráficos con manejo del ratón. • Imágenes de discos. Se incluye una potente herramienta de copia/restauración. Esta herramienta se puede emplear para ‘clonar’ sistemas operativos a gran escala o para restaurarlos si se vuelven inestables. • Sistema de ficheros de red. En el lado del servidor, REMBO ofrece un potente software basado en multi-procesos con un sistema de archivos propio. Los ficheros del servidor pueden ser descargados desde el cliente que ejecuta REMBO mediante el protocolo ‘unicast’ (el paquete de información se envía a un único receptor) o ‘multicast’ (el mismo paquete de información es enviado a múltiples receptores ) • Grupos de computadoras. Las computadoras pueden agruparse en el fichero de configuración del servidor para compartir las mismas operaciones durante el arranque así como el mismo entorno de trabajo. Cada computadora o grupo de computadoras, sin embargo, puede tener sus propias opciones.
¿CÓMO TRABAJA? • Una secuencia típica de arranque remoto incluye los siguiente pasos: • Encendido. El equipo remoto es encendido bien por el usuario bien por un evento ‘wake up’. • Configuración IP. El equipo remoto envía una señal de tipo ‘broadcast’ en busca de un servidor DHCP que le asigne una dirección IP. Cualquier servidor DHCP que conozca al cliente (por ejemplo, que reconozca su dirección física o ‘MAC Address’) o que tenga una batería de direcciones libres para ser distribuidas de forma dinámica le enviará una dirección IP. El cliente tomará la primera dirección asignada y la validará contra el servidor. Adicionalmente, el servidor le asignará otros parámetros de red necesarios, así como información acerca del procedimiento de arranque a seguir. • Localización del servidor de arranque. En el caso del arranque remoto mediante PXE, el cliente procederá a la localización del servidor de arranque. El servidor de arranque es el responsable del envío de un programa de arranque remoto al cliente. No es necesario que el servidor de arranque esté en la misma máquina que el servidor DHCP.
El cliente responderá al primer servidor de arranque que se comunique con él y descargará un pequeño programa de arranque remoto (MBA) empleando el protocolo de ‘multicast’ simple MTFTP (MulticasT File Transfer Protocol) • Conexión NBP (Network Bootstrap Program) Si el programa de arranque remoto es REMBO, el cliente establecerá una conexión segura con el servidor y obtendrá del servicio NBP los parámetros específicos sobre cómo debe ser configurado, el grupo al que pertenece el cliente, si algún dispositivo de entrada/salida debe ser bloqueado, qué servidor de ficheros se le ha asignado y cuál es su página de inicio. • Configuración previa del sistema operativo. REMBO descargará, entonces, del servidor de ficheros todo lo necesario para la configuración especificada por el administrador del sistema. Esta transferencia de ficheros se realiza empleando un protocolo ‘multicast’ seguro, robusto y eficiente. Se pueden realizar un gran número de acciones para dejar en las mejores condiciones de trabajo al equipo (modificar el sector de arranque, reparticionar, formatear, etc.) • Arranque del sistema operativo. Cuando el proceso de configuración lo ordene, REMBO se eliminará así mismo de la memoria y dejará que el sistema operativo tome el control de la misma, como si el equipo arrancará normalmente del disco duro (o cualquier otro dispositivo)
Esto asegura una plena compatibilidad con el sistema operativo y previene cualquier tipo de problemas que generan los sistemas de arranque remoto. Ya que REMBO incluye una arquitectura a prueba de fallos de tolerancia (‘fault-tolerant’), el proceso de arranque siempre podrá estar disponible al cliente. De cualquier forma, en caso de un fallo grave de la red los clientes REMBO pueden ser configurados para trabajar de modo ‘offline’, es decir, sin conectividad con la red.
REQUERIMIENTOS DE LOS CLIENTES Los clientes de arranque remoto deberán estar equipados con un chip ‘bootrom’ compatible PXE versión 0.99 ó 2.00. Se recomienda comprar tarjetas de red con memoria ‘flash’ y grabar los chip ‘bootrom’ con la última versión disponible de PXE. Actualmente, la mejor implementación de PXE se encuentra en las tarjetas de red de Intel ya que es éste el autor de las especificaciones PXE; las compañías 3COM, IBM y RealTek también proporcionan con sus tarjetas de red (últimos modelos) la implementación PXE. Como solución temporal para aquellos clientes que no dispongan de tarjeta de red con el chip ‘bootrom’, se puede emplear un disquete de arranque específico de Microsoft que incluye PXE. Este disquete se puede encontrar en la distribución de Microsoft Windows 2000 Server. El entorno gráfico de REMBO requiere una memoria BIOS compatible con VESA 1.1, además el acceso a bajo nivel a los discos es más eficiente con una BIOS con soporte para discos Extended INT13 (soporte para discos mayores de 8.4GB)
REQUERIMIENTOS DEL SERVIDOR SERVIDOR DHCP No son necesarios requerimientos específicos para el servidor DHCP. REMBO funciona bajo Windows NT DHCP, Windows 2000 DHCP, Servidor ISC DHCP, DHCP de Solaris 7 y DHCP de Netware 5. Si REMBO y DHCP se ejecutan desde la misma máquina, debe definirse la opción “class identifiers” del DHCP. SERVIDOR REMBO El servidor REMBO puede funcionar bajo Windows NT, Windows 2000, Linux (Intel) y Solaris (SUN Sparc.) Se recomienda un hardware potente.
INSTALACIÓN Y CONFIGURACIÓN DEL SERVIDOR REMBO • CONFIGURACIÓN DEL SERVIDOR DHCP EN WINDOWS 2000 • SERVIDOR DHCP Y SERVIDOR REMBO EN EL MISMO HOST • Si la opción 43 del DHCP está activada hay que eliminarla. • Activar la opción 60 del DHCP y configurarla como ‘PXEClient’. Habrá que configurar el DHCP para que envíe a los clientes la información de la opción 60 (“class indentifiers”) c:\>netsh netsh>dhcp dhcp>server 155.210.xxx.xxx (indicar la dirección IP del servidor) dhcp server>add optiondef 60 PXEClient STRING 0 comment=opcion añadida para soporte PXE dhcp server>set optionvalue 60 STRING PXEClient Comando completado con éxito. dhcp server>show optionvalue all Opción estándar de DHCP: Valores de opciones generales: Id. de opción : 60 Valor de opción: Número de elementos de opción = 1 Tipo de elemento de opción = STRING Valor del elemento de opción = PXEClient Comando completado con éxito. dhcp server>quit dhcp>quit netsh>quit
SERVIDOR DHCP Y SERVIDOR REMBO EN DIFERENTES HOSTS • Si las opciones 43 y 60 del DHCP están activadas, se eliminan. • Como el DHCP y REMBO están ejecutándose en diferentes hosts, no hay cambios que hacer en la configuración del DHCP. El servidor REMBO detectará los paquetes del DHCP enviados por la red por el protocolo PXE y ofrecerá los parámetros del PXE sin interferir en las negociaciones estándar del DHCP (lo que se denomina DHCPProxy)
INSTALACIÓN DE REMBO EN WINDOWS 2000 • Ejecutar el programa de instalación e instalar en el directorio deseado. • Copiar el fichero REMBO.KEY al directorio de instalación de REMBO. • Seleccionar el tipo de configuración: basada en el registro o basada en un fichero de texto. • Una vez instalado debemos tener los siguientes archivos y directorios creados: • rembo.exe: ejecutable del servicio. • files/: archivos del servidor • misc/: varias utilidades como netclnt. También incluye el SDK en las versiones Enterprise y Campus. • logs/: ficheros de log del servidor. • sconsole.exe: consola para controlar el servidor. • rconsole.exe: consola de acceso a clientes remotos.
CONFIGURACIÓN • En el proceso de instalación, REMBO crea una configuración mínima por defecto. Para cambiarla usamos el programa sconsole.exe. • Creamos los grupos de hosts que sean necesarios. REMBO crea un grupo por defecto, además de otros dos grupos denominados ‘Admin’ y ‘Production’, llamado ‘Default’ que es el que utiliza REMBO en caso de que el cliente no pertenezca a otro grupo. Es muy recomendable, por cuestiones de seguridad, eliminarlo o asignarle una página segura. • Pueden definirse tres tipos de autenticación: • local: utiliza los usuarios definidos en el servidor local. • NT remoto: utiliza un servidor NT remoto (o Linux via SAMBA) • RADIUS: utiliza el protocolo Radius (Remote Authentication Dial-In User Service) típico de los IPS’s.
REMBO crea el servidor 3 ficheros de log donde almacena información sobre las incidencias que se producen: • boot.log: registra eventos relacionados con la secuencia inicial de arranque de cada cliente remoto PXE. Eventos típicos son peticiones DHCP, descargas (M)TFTP, etc. • nbp.log: registra eventos transaccionales entre un cliente de arranque remoto y el servidor. Tales eventos incluyen peticiones de autenticación, consultas a bases de datos, bloqueos de servidor, etc. • file.log: registra transferencias de archivos a y desde el servidor, incluyendo transferencias unicast y multicast. • El nivel de detalle de estos logs está controlado por sus correspondites ‘debuglevel’ o, a nivel global, por el parámetro ‘globaldebuglevel’ (de 0 a 6, de menos a más detalle) y puede ser modificado en la consola. • Los ficheros log pueden ser accedidos directamente en el servidor (en el subdirectorio ‘logs’), o remotamente usando la consola. Cuando se accede remotamente a grandes logs, solo las mil últimas entradas serán enviadas.
HERRAMIENTAS DE ADMINISTRACIÓN • SCONSOLE: permite administrar todos los parámetros de REMBO desde una consola Windows. Será la herramienta que vamos a utilizar. • RCONSOLE: herramienta de administración remota. Permite manejar equipos sin tener que estar frente a la máquina (análogo a ‘Terminal Server’ de Windows) Configuramos, para el cliente en concreto o para todo el grupo, el parámetro ‘RemoteConsole’ indicando la dirección IP del servidor y el puerto de conexión (generalmente el 4021). Ejecutamos RCONSOLE.EXE ubicado en el directorio rconsole/ e indicamos la IP del cliente al que queremos conectarnos y el puerto de conexión (generalmente el 4021)
TRABAJANDO CON WINDOWS 95/98 • ANTES DE EMPEZAR • Seleccionar una o varias máquinas ‘modelo’, que sirvan como base para las demás. • Estudiar el tamaño de las particiones del disco duro del cliente en función de los S.O. que queramos instalar. Dejar suficiente espacio al final del disco para ser utilizado como caché. • En la máquina modelo, instalar Windows 95/98 y el software necesario. Activar la obtención de los parámetros de red por DHCP (dirección IP, WINS y DNS) y dar valores a los campos: nombre del equipo, grupo de trabajo, etc. • Crear un usuario general para acceder a la máquina (p.e.: invitado) • Actualizar el S.O. empleando ‘Microsoft Windows Update’ y ejecutar, al menos una vez, todo el software instalado.
TRABAJANDO CON WINDOWS NT/2000/XP • ANTES DE EMPEZAR • Seleccionar una o varias máquinas ‘modelo’, que sirvan como base para las demás. • Estudiar el tamaño de las particiones del disco duro del cliente en función de los S.O. que queramos instalar. Dejar suficiente espacio al final del disco para ser utilizado como caché. • En la máquina modelo, instalar Windows NT/2000/XP y el software necesario en la primera partición del disco duro. Activar la obtención de los parámetros de red por DHCP (dirección IP, WINS y DNS) y dar valores a los campos: nombre del equipo, grupo de trabajo, etc. • Crear un usuario general, además del administrador del sistema, para acceder a la máquina (p.e.: usuario) con los privilegios deseados. • Actualizar el S.O. empleando ‘Microsoft Windows Update’ y ejecutar, al menos una vez, todo el software instalado. • Descomprimir y desencriptar el sistema empleando las órdenes: c:\>compact /u /a /s /i c:\>cipher /d /a /i /h /s:\
TRABAJANDO CON LINUX • ANTES DE EMPEZAR • Seleccionar una o varias máquinas ‘modelo’, que sirvan como base para las demás. • Estudiar el tamaño de las particiones del disco duro del cliente en función de los S.O. que queramos instalar. Dejar suficiente espacio al final del disco para ser utilizado como caché. • En la máquina modelo, instalar Linux y el software necesario. Activar la obtención de los parámetros de red por DHCP. • Crear un usuario general para acceder a la máquina (p.e.: invitado)
CREACIÓN DE IMÁGENES DE DISCO Y RESTAURACIÓN. CLONACIÓN La creación y restauración de imágenes de disco es una característica fundamental de REMBO. Permite la clonación de sistemas operativos de una forma muy eficiente, pudiendo clonar los siguientes: xx-DOS, Windows 95/98/Me, Windows NT/2000/XP y Linux. Existen dos métodos conocidos para la clonación de particiones de disco, clonación basada en sectores (sector-based), que puede dividirse en blind analysis o allocation-aware analysis, y clonación basada en estructura (structure-based) que es la empleado por REMBO. La clonación basada en estructura requiere un amplio conocimiento del sistema de ficheros que está instalado en el ordenador de referencia y la capacidad de reconstruir un sistema de ficheros completo en el ordenador destino. Este método trabaja con ficheros y directorios más que con sectores, como una utilidad de backup/restore. Las ventajas son múltiples: es más flexible ya que permite seleccionar qué ficheros guardar o restaurar (o cuales no); puede restaurar ficheros en un sistema de ficheros existente, sin tener que borrar los ficheros que ya existan; las imágenes de disco se pueden editar para borrar ficheros o directorios que no se quieren en el proceso de restauración; puede sincronizar más que clonar, esto es, los ficheros ya instalados en el ordenador destino que sean idénticos al de referencia no se copian.
CLONACIÓN INTELIGENTE: LA SINCRONIZACIÓN • La mayoría de las técnicas de clonación disponibles se usan para instalar un nuevo sistema operativo en máquinas cliente vacías. REMBO va un paso más allá con su modo de Sincronización, donde la clonación del disco no se limita a la mera utilización del S.O. • En lugar de realizar una restauración ciega de la imagen de disco, destruyendo todos los datos previamente almacenados en la partición destino, REMBO es capaz de restaurar los ficheros basándose en varias reglas: • En modo por defecto, el proceso de sincronización restaurará sólo los ficheros en los que el tamaño, la fecha o los atributos hayan cambiado. Esto es similar a una herramienta estándar de backup/restore. • En modo seguro, el proceso de sincronización restaurará todos los ficheros cuyo contenido haya cambiado. • En modo compatible, el proceso de sincronización restaurará todos los ficheros, emulando a una herramienta estándar de clonación. • Además se puede seleccionar uno de los siguientes modos para decidir qué hacer con los ficheros antiguos (ficheros que están en la partición destino pero no en la imagen) y con los ficheros nuevos (ficheros que están en la imagen pero no en la
partición destino): • En modo comparación: el proceso de sincronización no añadirá nuevos ficheros a la partición destino ni borrará ningún fichero de ella. REMBO sólo actualizará los ficheros que estén presentes tanto en la partición destino como en la imagen. • En modo añadir: se añadirán los nuevos ficheros a la partición pero no se borrarán los ficheros antiguos. Este modo es muy útil para estaciones de trabajo. • En modo completo: se añaden los ficheros nuevos a la partición destino y se borran los ficheros antiguos. La partición destino es una copia exacta de la imagen al final del proceso de restauración. Este es el modo por defecto.
CONCEPTOS AVANZADOS DE CLONACIÓN. IMÁGENES INCREMENTALES Y DIFERENCIALES • FILTRANDO FICHEROS CON IMÁGENES VIRTUALES • En algunas circunstancias se podría requerir hacer una copia sólo de un subconjunto de la partición de referencia, o filtrar algunos ficheros que no se quieren, con los ficheros de paginación de memoria de Windows 9x y Windows NT/2000/XP. • La imagen virtual es una copia de la estructura de directorios (sólo ficheros y directorios) de un sistema de ficheros existente. Esta imagen virtual puede ser modificada añadiéndole otro sistema de ficheros (fusión) o borrando ficheros o directorios. • El proceso de creación de una imagen de disco apartirde una imagen virtual es muy simple: • Crear una imagen virtual de la partición de referencia. • Opcionalmente, añadir otras particiones como un subdirectorio de la imagen virtual. • Borrar los ficheros y directorios no deseados, tales como ficheros de paginación o temporales. • Usar la sincronización para construir una imagen de disco a partir de la imagen virtual. • Cerrar la imagen virtual para liberar recursos del sistema.
IMÁGENES INCREMENTALES Y DIFERENCIALES Una imagen incremental es la diferencia entre dos sistemas de ficheros, en cuanto a ficheros/directorios añadidos (incremental, propiamente dicha) y ficheros/directorios borrados (diferencial) Esta diferencia se puede almacenar en una imagen de disco, creando una imagen de disco incremental. Las imágenes incrementales son útiles para crear paquetes de instalación de software, independientemente del hardware instalado. Por ejemplo, podríamos crear una imagen de un Windows 98 recién instalado y llamarla win98base. Entonces, crear una imagen incremental de la misma partición de referencia después de haber instalado MS-Office en el ordenador. La imagen incremental sólo contendrá los ficheros de MS-Office que estarán separados de la imagen base. Si repitiéramos este proceso para otros paquetes de software llegaríamos a tener una librería de software preparada para ser utilizada en cualquier equipo, ya que estas imágenes son independientes de la imagen base y por ello del hardware o software presente en el equipo destino. A lo anterior hay que añadirle un ‘pero’. Debemos tratar de manera independiente las entradas del registro que realice cada paquete de software, almacenándolas por separado para su posterior importación en el equipo destino.
IMÁGENES INCREMENTALES BÁSICAS • Son la forma más simple de hacer una imagen incremental. La diferencia entre el estado inicial y el nuevo estado, incluyendo ficheros de configuración, se almacena en un único fichero. En la restauración, los ficheros de configuración se reemplazarán por la versión almacenada en la imagen incremental. • Este método trabaja bien siempre y cuando fusionemos una única imagen incremental con la imagen base. Para fusionar más de una imagen incremental deben emplearse imágenes incrementales avanzadas. • IMÁGENES INCREMENTALES AVANZADAS • Si queremos fusionar varias imágenes incrementales con una imagen base, debes manejar los cambios de los ficheros de configuración de forma separada. Dependiendo del S.O. que estemos clonando tendremos que ejecutar pasos adicionales a la creación de imágenes incrementales: • para Windows 95/98/Me: los ficheros de registros se sacan de las imágenes incrementales, debiendo ser tratados de forma separada con un fichero patch de registro (.reg) para cada imagen incremental.
para Windows NT/2000/XP: los ficheros de registros se sacan de las imágenes incrementales, debiendo ser tratados individualmente para cada imagen incremental. Estos ficheros de registro (cinco en total) están almacenados en winnt/system32/config y hacen referencia a SYSTEM, SOFTWARE, SAM, SECURITY y DEFAULT. • En Linux: los ficheros de registros que afecten a mas de una imagen incremental deberán ser sacados fuera y tratados de forma separada con ficheros de texto patch diferenciales. • REMBO proporciona poderosas herramientas para la fácil creación de imágenes incrementales limpias, específicamente para Windows NT/2000/XP para los que la operación es más complicada.
CONSIDERACIONES GENERALES • Elección de una o varias máquinas que sirvan de “modelo” para nuestros equipos. • Estudio del tamaño necesario para las distintas particiones, así como el tipo y formato de las mismas. • Dejar espacio sin particionar al final del disco duro para ser empleado como partición caché. • Realizada la instalación del sistema operativo y del software, crear un fichero vacío llamado “rembo.bat” en el directorio raíz de la partición y añadir una línea al autoexec.bat para que ejecute este fichero. • Configurar los parámetros de red para el uso de DHCP.
CREACIÓN DE UNA IMAGEN BASE • Asegurarnos de que existe el fichero vacío rembo.bat en el directorio raíz de la partición y de que se ha añadido una llamada a este archivo en cualquier parte del autoexec.bat mediante la orden call rembo.bat • Empleando la consola interactiva o mediante un script en REMBO-C ejecutar las siguientes instrucciones: // Paso 1. Crear una imagen virtual del disco CreateVirtualImage(“win9x”,”disk://0:1”); // Paso 2. Eliminar el archivo de intercambio temporal de la imagen virtual if(FileExists(“link://win9x/windows/win386.swp”)) RemoveFile(“link://win9x/windows/win386.swp”); // Paso 3. Eliminar cualquier imagen previa a la que se está generando if(FileExists(“cache://global/hdimages/win9x/imagenbase98.img”)) RemoveFile(“cache://global/hdimages/win9x/imagenbase98.img”); // Paso 4. Crear un archivo a partir de la imagen virtual Synchronize(“link://win9x”,”cache://global/hdimages/win9x/imagenbase98.img”,”b“); // Paso 5. Liberar recursos FreeVirtualImage(“win9x”);
RESTAURACIÓN DE UNA IMAGEN BASE • Crear las particiones antes de restaurar la imagen de disco. No es necesario, aunque si recomendable, formatear las particiones ya que la imagen contiene el formato. // 1. Crear una partición de 2Gb FAT32 SetPrimaryPartitions(0,”FAT32:2000000 EMPTY:0 EMPTY:0 EMPTY:0”); // 2. Restaurar la imagen (previo formateo de la partición destino) RestoreDiskImage(0,1,”cache://global/hdimages/win9x/imagenbase98.img”); // o bien, sincronizarla Synchronize(“cache://global/hdimages/win9x/imagenbase98.img”,”disk://0:1”,”b”); • Cambiamos la identificación del equipo con la información que obtenemos del DHCP. // 3a. El nombre de la máquina está formado por los últimos bytes de la dirección IP. var ipa = StrParse(NetInfo.IPAddress,”.”); str hostname = “pc-”+ipa[2]+”-”+ipa[3]; • Añadimos la información correspondiente al fichero “rembo.reg” y “rembo.bat” para hacer el parcheo manual al registro de windows.
// 3b. Crear un parche del registro para establecer el nombre de la máquina CreateTextFile("disk://0:1/rembo.reg", "REGEDIT4\n\n" "[HKEY_LOCAL_MACHINE\\System\\CurrentControlSet" "\\Services\\VxD\\VNETSUP]\n" "\"ComputerName\"=\""+Hostname+"\"\n\n" "[HKEY_LOCAL_MACHINE\\System\\CurrentControlSet" "\\Services\\VxD\\MSTCP]\n" "\"Hostname\"=\""+Hostname+"\"\n\n" "[HKEY_LOCAL_MACHINE\\System\\CurrentControlSet" "\\control\\ComputerName\\ComputerName]\n" "\"ComputerName\"=\""+Hostname+"\"\n"); // 3c. Añadir una llamada al comando regedit en nuestro fichero rembo.bat CreateTextFile("disk://0:1/rembo.bat", "c:\\windows\\regedit" " /L:c:\\windows\\system.dat" " /R:c:\\windows\\user.dat" " c:\\rembo.reg"); // 4. Arrancar desde la partición del disco HDBoot(0,1);
CREACIÓN DE UNA IMAGEN INCREMENTAL BÁSICA • Una imagen incremental o diferencial contiene las diferencias entre dos estados de la partición. Si la imagen es incremental, al restaurarla, se añadirán los ficheros y entradas del registro nuevas que no figurasen en la imagen del disco; si la imagen es diferencial, al restaurarla, se eliminarán los ficheros y entradas del registro que no figuren en la imagen del disco. • No gestiona automáticamente las diferencias de los ficheros del registro, por lo que dará problemas si queremos combinar más de una imagen incremental Synchronize(“disk://0:1”, “cache://global/hdimages/win9x/imagenbase98.img”, “>cache://global/hdimages/win9x/imagenbase98.diff”);
RESTAURACIÓN DE UNA IMAGEN INCREMENTAL BÁSICA • Para restaurar la imagen incremental básica, hay que fusionarla con la imagen base. Para ello empleamos una imagen virtual a la que le añadiremos, como si se tratara de un directorio, la imagen incremental. En el script de restauración de la imagen base, el paso 2 sería reemplazado por estas líneas. // 1. Abrir los dos archivos de disco (base y diferencia) OpenArchive(“base”,”cache://global/hdimages/win9x/imagenbase98.img”); OpenArchive(“diff”,”cache://global/hdimages/win9x/imagenbase98.diff”); // 2. Crear una imagen virtual a partir del archivo base CreateVirtualImage(“win9x”,”arch://base”); // 3. Añadir la imagen incremental a la imagen virtual FileLink(“link://win9x”,”arch://diff”); // 4. Sincronizar el contenido del disco con la imagen virtual Synchronize(“link://win9x”,”disk://0:1”,”b”); // 5. Liberar recursos usados FreeVirtualImage(“win9x”); CloseArchive(“diff”); CloseArchive(“base”);
CONSIDERACIONES GENERALES • Elección de una o varias máquinas que sirvan de “modelo” para nuestros equipos. • Estudio del tamaño necesario para las distintas particiones, así como el tipo y formato de las mismas. • Dejar espacio sin particionar al final del disco duro para ser empleado como partición caché. • Realizar la instalación del sistema operativo en la primera partición del disco. • Descomprimir y desencriptar los ficheros de la partición. • Configurar los parámetros de red para el uso de DHCP.
CREACIÓN DE UNA IMAGEN BASE • Empleando la consola interactiva o mediante un script en REMBO-C ejecutar las siguientes instrucciones: // Paso 1. Crear una imagen virtual del disco CreateVirtualImage(“winnt”,”disk://0:1”); // Paso 2. Eliminar el archivo de intercambio temporal de la imagen virtual if(FileExists(“link://winnt/pagefile.sys”)) RemoveFile(“link://winnt/pagefile.sys”); // Paso 3. Eliminar cualquier imagen previa a la que se está generando if(FileExists(“cache://global/hdimages/winnt/imagenbasent.img”)) RemoveFile(“cache://global/hdimages/winnt/imagenbasent.img”); // Paso 4. Crear un archivo a partir de la imagen virtual Synchronize(“link://winnt”,”cache://global/hdimages/winnt/imagenbasent.img”,”b“); // Paso 5. Liberar recursos FreeVirtualImage(“winnt”);
RESTAURACIÓN DE UNA IMAGEN BASE • Crear las particiones antes de restaurar la imagen de disco. No es necesario, aunque si recomendable, formatear las particiones ya que la imagen contiene el formato. // 1. Crear una partición de 3Gb FAT32 SetPrimaryPartitions(0,”NTFS:3000000 EMPTY:0 EMPTY:0 EMPTY:0”); // 2. Restaurar la imagen (previo formateo de la partición destino) RestoreDiskImage(0,1,”cache://global/hdimages/winnt/imagenbasent.img”); // o bien, sincronizarla Synchronize(“cache://global/hdimages/winnt/imagenbasent.img”,”disk://0:1”,”b”); • Cambiamos la identificación del equipo con la información que obtenemos del DHCP. // 3a. El nombre de la máquina está formado por los últimos bytes de la dirección IP. var ip = StrParse(NetInfo.IPAddress,”.”); str hostname = “pc-”+ipa[2]+”-”+ipa[3]; NTChangeName(hostname);
La función de REMBO-C NTChangeName(str name) cambia, con una sola orden, todos los nombres locales NT. Es decir, equivale a reemplazar el nombre NetBios, el nombre del host y el logon en el dominio. NTChangeName(“paquito”); // equivaldría a las siguientes llamadas NTSetNetbiosName(“paquito”); // nombre NetBios NTSetHostName(“paquito”); // nombre del host NTSetWinLogonDomain(“paquito”); // logon en el dominio
CREACIÓN DE UNA IMAGEN INCREMENTAL BÁSICA • Una imagen incremental o diferencial contiene las diferencias entre dos estados de la partición. Si la imagen es incremental, al restaurarla, se añadirán los ficheros y entradas del registro nuevas que no figurasen en la imagen del disco; si la imagen es diferencial, al restaurarla, se eliminarán los ficheros y entradas del registro que no figuren en la imagen del disco. • No gestiona automáticamente las diferencias de los ficheros del registro, por lo que dará problemas si queremos combinar más de una imagen incremental Synchronize(“disk://0:1”, “cache://global/hdimages/winnt/imagenbasent.img”, “>cache://global/hdimages/winnt/imagenbasent.diff”);
RESTAURACIÓN DE UNA IMAGEN INCREMENTAL BÁSICA • Para restaurar la imagen incremental básica, hay que fusionarla con la imagen base. Para ello empleamos una imagen virtual a la que le añadiremos, como si se tratara de un directorio, la imagen incremental. En el script de restauración de la imagen base, el paso 2 sería reemplazado por estas líneas. // 1. Abrir los dos archivos de disco (base y diferencia) OpenArchive(“base”,”cache://global/hdimages/winnt/imagenbasent.img”); OpenArchive(“diff”,”cache://global/hdimages/winnt/imagenbasent.diff”); // 2. Crear una imagen virtual a partir del archivo base CreateVirtualImage(“winnt”,”arch://base”); // 3. Añadir la imagen incremental a la imagen virtual FileLink(“link://winnt”,”arch://diff”); // 4. Sincronizar el contenido del disco con la imagen virtual Synchronize(“link://winnt”,”disk://0:1”,”b”); // 5. Liberar recursos usados FreeVirtualImage(“winnt”); CloseArchive(“diff”); CloseArchive(“base”);