WfM - Wired for Management - DEI | Departamento de ...
ISEP - Instituto Superior de Engenharia do Porto
Estudo de Mecanismos de Remote Boot
Projecto 5º Ano
Setembro de 2000
Índice
Índice I
Figuras IV
Agradecimentos V
CAPÍTULO 1 Introdução ao Remote Boot 1
Visão Contextual 1
Remote Boot - Introdução 1
CAPÍTULO 2 Remote Boot - Alguns Conceitos 7
Alguns Conceitos de Remote Boot 7
Uma Breve Introdução às Boot ROMs 7
O Processo de Remote Boot 8
Os Mecanismos de Remote Boot 9
CAPÍTULO 3 Mecanismos de Remote Boot 10
Tecnologias Netboot e Etherboot - Não baseadas em PXE 10
Uma Possível Implementação 12
BOOTP 12
TFTP 12
Network File System - NFS 13
A Criação da Boot Disk 14
A Solução X-Terminal 16
CAPÍTULO 4 Mecanismos PXE 21
WfM - Wired for Management 21
Desktop Management Interface (DMI) 22
Wake-on-Lan 23
PXE 23
A implementação nos servidores 24
A implementação nos clientes 24
A API PXE 24
BpBatch - Exemplo de Aplicação da Tecnologia PXE 26
Parte Cliente - Linux 27
♣ Diskless RB 27
♣ Disk-based RB 27
Parte Servidor - Linux 28
Servidor DHCP 28
Servidor TFTP 30
Parte Cliente - Windows 30
Parte Servidor - Windows 30
Servidor DHCP 31
Servidor TFTP 31
CAPÍTULO 5 Windows 2000 Server - RIS 33
Introdução 33
A Tecnologia Remote Boot ROM PXE e os Windows 2000 RIS 35
Pré-Requisitos 35
Placas de Rede suportadas pela RIS Boot Floppy 36
Remote Installation Services - RIS 37
A Instalação do RIS 37
Autorização do RIS no Active Directory 38
Configuração do RIS 38
Remote Installation Advanced Settings 40
Tab “New Clients” 41
Tab “Images” 42
Tab “Tools” 43
Preparação para Máquinas Clientes com Remote Installation 44
Início do Processo de Logon dos Clientes 45
Opções de Instalação da Parte do Cliente 45
Implementação de Restrições 47
Restrições nas Imagens do Sistema Operativo 47
Restrições em Instalações de Clientes 47
Outras Funcionalidades do RIS 49
Remote Installation Preparation Wizard 49
Remote Installation Boot Floppy 50
Conclusão 51
CAPÍTULO 6 Case Study - FEP 53
FEP - Faculdade de Economia do Porto 53
Necessidades 53
Descrição da Solução Adoptada 53
Os Resultados 54
Os Componentes do Sistema Remote Boot da FEP 55
Produtos Utilizados 56
O Remote Boot 57
Parte Cliente - Boot ROMs 58
Parte Servidor - A Organização no PITON 59
A Implementação 62
A Manutenção do Sistema de Remote Boot 69
Pontos Fortes do Sistema de Remote Boot da FEP 69
Pontos Fracos do Sistema Remote Boot da FEP 70
O Sistema Informático da FEP no Futuro 71
CAPÍTULO 7 Tecnologias Complementares 73
Contexto 73
Intel Rapid BIOS Boot 73
Windows Terminal Server (WTS) 73
CAPÍTULO 8 Conclusão 77
Bibliografia 78
ANEXO I Glossário de Termos Remote Boot 79
Figuras
fig. 1 A administração em remote boot 3
fig. 2 Remote Boot diskless 5
fig. 3 um programador de ROMs 8
fig. 4 Um sistema Wired for Management (WfM) 22
fig. 5 Desktop Management Interface 22
fig. 6 A API PXE 25
fig. 7 O processo de Remote Boot PXE 26
fig. 8 O processo RIS 34
fig. 9 Active Directory 39
fig. 10 Propriedades do Servidor RIS 40
fig. 11 Advanced Properties do RIS 40
fig. 12 Personalização da ID das máquinas clientes 41
fig. 13 As imagens de SO disponíveis 42
fig. 14 Definição de políticas de instalação no RIS 48
fig. 15 As políticas de instalação 48
fig. 16 Esquema da rede dos alunos da FEP 56
fig. 17 Modo de funcionamento do Bootware num ambiente RPL 59
fig. 18 As áreas das máquinas clientes no PITON 60
fig. 19 As “homes” dos alunos no PITON 61
fig. 20 O Remote Boot Manager do NT Server 4.0 62
fig. 21 Windows Terminal Services 75
Agradecimentos
Venho expressar nesta secção os meus sinceros agradecimentos a todas as pessoas que, de alguma maneira, contribuiram para a realização deste projecto.
Em primeiro lugar gostaria de agradecer ao Engº Paulo Ferreira, meu orientador, e ao Engº André Moreira do Instituto Superior de Engenharia do Porto, pela prestabilidade e interesse demonstrados sempre que necessitei de esclarecer dúvidas relacionadas com este trabalho, assim como pela orientação na elaboração deste relatório.
DO MESMO MODO GOSTARIA DE AGRADECER AO ENGº JORGE MADUREIRA, CHEFE DO DEPARTAMENTO DE INFORMÁTICA DA FACULDADE DE ECONOMIA DA UNIVERSIDADE DO PORTO, PELA SUA DISPONIBILIDADE NA EXPLICAÇÃO DOS PORMENORES DE IMPLEMENTAÇÃO DO SISTEMA REMOTE BOOT DA FEP.
INTRODUÇÃO AO REMOTE BOOT
Capítulo
1
Visão Contextual
A gestão e administração de redes locais sempre se revelou uma tarefa árdua e complexa, devido a vários factores, de diversas naturezas.
O mau uso do equipamento por parte dos utilizadores, o “crash” infelizmente regular de sistemas, aliados a orçamentos limitados, ao crescente tamanho das redes locais e todos os problemas de gestão que daí advêm, ao custo do hardware, entre outros factores, leva a muitas dificuldades na realização das tarefas do administrador de sistemas informáticos.
Se juntarmos a isto o número cada vez maior de sistemas operativos, software aplicacional, e a correspondente exigência de recursos destes mesmos, temos os ingredientes suficientes para fazer da actividade de administrador algo de não muito invejável.
Assim surgiram as condições necessárias a um novo conceito de concepção de redes locais - o Remote Boot.
Deste modo, propõe-se a capacidade de instalação de um sistema operativo sem a necessidade de visitar fisicamente cada máquina cliente, ou pelo menos reduzir o número de visitas. Simultaneamente, através de um melhor aproveitamento dos recursos, por vezes mesmo dos já existentes e “caducos”, obtem-se uma gestão mais eficiente, segura, fiável e facilitada do parque informático.
Remote Boot - Introdução
Um computador Remote Boot é uma máquina que não está totalmente dependente de recursos locais (quer de processamento, quer de armazenamento de dados, por exemplo), para arrancar um sistema operativo (SO), utilizando antes recursos remotos através da rede em que está inserido.
Para atingir esse objectivo, as máquinas clientes devem possuir um pedaço de código que lhes permita efectuar o arranque remoto do SO - o chamado bootstrap code - normalmente inserido numa Boot ROM na placa de rede. Esta possui os dados para contactar o servidor e obter os ficheiros necessários através da rede.
Através desta aproximação, obtêm-se ganhos em:
▪ custos de manutenção de software nas máquinas clientes, através da centralização da informação num servidor central (pode também ser mais de um, para distribuição de carga e outros motivos abordados mais adiante)
▪ versatilidade na utilização de sistemas operativos, ao tornar-se possível escolher a imagem do sistema operativo desejado para trabalhar. Isto é possível não só para o mesmo SO (cada imagem com aplicações de software diferentes), como para diferentes SOs. Exemplo: Arrancar com o Windows 95 com aplicações 3D; Outro exemplo: Arrancar com o Windows 95 ou Red Hat Linux 6.0;
▪ facilidade de recuperação de instalações de SO, quando uma instalação fica corrompida por algum motivo, basta realizar um reboot à máquina cliente, ou então realizar uma cópia no servidor da pasta de outra máquina cliente semelhante, com pequenas alterações - processo que é geralmente automatizado através de scripts
▪ tempo, pois a administração é central e muitas vezes dispensa mesmo a deslocação física até à máquina cliente - que por vezes poderá estar em outro edifício
▪ custos com pessoal, pois com a simplificação da administração/gestão do parque informático, diminui o número de homens/hora para realizar as tarefas
▪ em alguns casos, custos de hardware, pois permite o reaproveitamento de material informático já existente, por vezes mesmo o já considerado obsoleto. Isto é possível pois os sistemas Remote Boot em geral exigem menos das máquinas clientes, dado que grande parte do processamento é realizado remotamente - no(s) servidor(es)
▪ controlo do sistema, pois o sendo o arranque do sistema operativo remoto, limita as opções de arranque dos utilizadores às previamente definidas pelo administrador do sistema. Do mesmo modo, após o boot do SO, o utilizador possui apenas as permissões definidas centralmente pelo responsável pelo sistema
▪ diminuição de erros humanos, devido à automatização de muitos dos processos.
fig. 1
Existe em 2 sabores, cada qual com vantagens inerentes:
▪ com unidade de disco rígido local - melhor performance, menor tráfego na rede
▪ sem unidade de disco rígido local (diskless) - menor custo, ambiente de trabalho mais silencioso; particularidade: em ambientes inóspitos a discos - como ambientes fabris -, dados os seus componentes mecânicos e baixa tolerância a vibrações, é mais indicado, dada a robustez do sistema
Para uma máquina cliente realizar um arranque remoto do SO (Remote Boot) deve possuir:
▪ uma identidade única
▪ uma imagem de um sistema operativo
▪ um filesystem
Para que se consiga identificar inequivocamente o computador, é utilizado um pedaço de informação unívoco para todas as máquinas a nível mundial: o MAC address da sua placa de rede.
A imagem do sistema operativo reside no servidor (podem existir várias) e é transferida para o cliente.
Para operar, a máquina necessita de um filesystem, o qual pode ser remoto (ex:NFS) ou local (ex:FAT32, NTFS, EXT2, ...)
O processo de Remote Boot é, genericamente falando, dividido em 3 partes:
1. Recolha de informações sobre a configuração da máquina cliente; para tal, o cliente irá servir-se de um protocolo para estabelecer comunicação com o servidor, tal como o BOOTP ou DHCP, de modo a conseguir obter o conjunto de informações básicas para continuar o processo de arranque. Essas incluem, entre outras, o endereço IP da máquina cliente atribuído pelo servidor, a subnet mask, o gateway por defeito e a identificação do bootstrap program a carregar, assim como a localização deste (pode estar noutro servidor). Para contactar o servidor BOOTP ou DHCP, visto que a máquina cliente não sabe qual o seu endereço, é enviado um pacote em broadcast, ao qual o primeiro servidor disponível responde
2. Fazer o download do bootstrap program; Este irá ser mais tarde o responsável pelo lançamento do SO, e está guardado no disco do servidor. É transferido para o cliente a seu pedido, através do protocolo TFTP (uma versão ligeira do FTP, por motivos relacionados com o aproveitamento de recursos, bastante limitados nestas primeiras fases do processo) ou semelhante. O bootstrap program é um componente vital do Remote Boot, pois irá preparar o cliente para correr o sistema operativo
3. Execução do bootstrap program, que levará ao download do sistema operativo pré-definido pelo administrador, em alguns casos ao re-particionamento e formatação (tipicamente formatação rápida) do disco - no caso de este estar presente - e lançamento do S.O.
Um esquema possível de um sistema Remote Boot:
fig. 2
[pic]
Isto implica que num sistema Remote Boot existam pelo menos os seguintes componentes (ou equivalentes):
▪ uma ou mais máquinas clientes. Devem estar equipadas com BootROMs programáveis (EPROM, EEPROM, ...) ou utilizar uma outra aproximação (uma disquete de boot, por exemplo), com a informação necessária para que a BIOS do computador inicie o boot a partir de um device alternativo - a rede
▪ uma ou mais computadores servidores de remote boot
▪ infraestruturas de rede básicas (parte passiva:cablagens,... parte activa:switch/hub, ...)
▪ um servidor DHCP ou BOOTP para resolução de endereços e outros serviços
▪ um servidor de um protocolo de transferência de ficheiros (TFTP, MTFTP, ...) para o carregamento de um network bootstrap program (NBP), o qual contém a informação necessária para o arranque do sistema operativo
O próprio termo Remote Boot é bastante abrangente, compreendendo vários tipos de mecanismos e implementações. Neste documento será feita a análise de alguns destes, expondo as suas fraquezas e pontos fortes, e em alguns casos será realizada uma descrição do seu modo de implementação. Pretende-se assim que sirva como auxílio e ajude a compreender a lógica dos sistemas Remote Boot, quer para estudo das tecnologias, quer para aplicação prática.
mote Boot - Alguns Conceitos
Capítulo
2
Alguns Conceitos de Remote Boot
Neste capítulo são explicados sucintamente alguns processos e termos relacionados com Remote Boot, de modo a permitir uma melhor compreensão das secções seguintes
Uma Breve Introdução às Boot ROMs
Para o remote boot ser possível, é necessário que exista na placa de rede (ou NIC - Network Interface Card) um chip PROM (Programmable ROM) que contenha um programa que permita realizar o boot pela rede.
Existem outras maneiras de o fazer, como através de uma disquete de boot, mas para uma implementação séria esta é uma alternativa que não apresenta quer segurança, quer fiabilidade (no entanto para efeito de testes é um bom processo, pois simplifica bastante e é de aplicação imediata).
Para este tipo de utilização, temos 2 classes de PROMs disponíveis:
▪ as EPROM (Erasable Programmable ROM) - os bits são “escritos” pela injecção de electrões com uma voltagem elevada num transistor, onde os bits “0” são para escrever - não os bits “1” ao contrário do corrente em outras aplicações. Os electrões ficam aí “presos”, fazem com que o transistor conduza, originando a leitura dos “0s”. Para apagar a EPROM, fornece-se energia suficiente aos electrões para escaparem, destapando uma janela de quartzo no chip e bombardeando-o com radiação ultravioleta. Para prevenir um apagamento gradual ao longo dos anos, devido à luz do Sol e lâmpadas fluorescentes, esta janela possui uma protecção opaca para o uso corrente.
▪ as EEPROM (Electronically Erasable Programmable ROM) - onde se incluem as chamadas Flash PROM, trata-se uma tecnologia semelhante; aqui os electrões são “limpos” através de um sinal eléctrico. Possuem a vantagem de serem mais versáteis, mas obrigam a que o chip tenha circuitos extra para o processo de apagar.
O programa é inserido no chip através de um programador de ROMs (ver figura abaixo), no caso das EPROM e certas EEPROM. No caso das Flash ROM, é possível actualizar o chip apenas através de um utilitário de software, como correntemente se faz para actualizar as BIOS dos PCs.
fig. 3
[pic]
Nota Uma alternativa às PROMs embutidas em placas de rede é a colocação de uma placa ISA com um circuito só para o efeito, em adição ao adaptador de rede. Com isto vem o inconveniente de ocupar mais um slot no Bus ISA, para além de não poder funcionar com qualquer mecanismo de Remote Boot - a distribuição Etherboot, analisada mais à frente, permite este tipo de opção, mas obriga a conhecimentos de electrónica (só para entusiastas).
O Processo de Remote Boot
O processo de bootstrap em PCs, essencial para o Remote Boot, basea-se em um programa iniciar outro, que por sua vez irá iniciar outro ainda, cada um mais “inteligente” do que o precedente.
O primeiro destes é guardado em ROM num chip na BIOS do sistema - entra em acção mal o computador é ligado. O processo de Remote Boot não é diferente, excepto que em vez de passar o controlo para uma unidade típica, como seja o disco duro ou a drive de disquetes, inicializa a PROM embutida na placa de rede. A PROM contêm o código necessário para contactar um servidor e instalar uma imagem de boot em memória, reunindo as condições necessárias para o arranque de um sistema operativo completo.
As etapas (simplificadas) do processo são as seguintes:
1. A PROM é previamente programada através de um dos métodos atrás descritos, sendo inserido o código necessário do mecanismo de remote boot escolhido - o primeiro bootstrap.
2. Coloca-se a PROM no socket disponível para o efeito na placa de rede - virtualmente todas as placas de rede actualmente possuem este espaço. Isto tem como efeito um acréscimo das possibilidades da BIOS. A BIOS do PC permite que ao adicionar-se novos dispositivos ao sistema, estes possam correr pequenos programas de inicialização, estando pré-definido um espaço de memória na máquina para o efeito. Isto é perfeitamente visível quando se liga um PC: o código dos dispositivos é detectado - inclusivé o da PROM no NIC - e o primeiro ecrã a aparecer é o do fabricante da placa gráfica. Segue-se o POST (Power-On Self Test) e em seguida são inicializados os dispositivos - como a placa de rede, controladores SCSI, entre outros.
3. A PROM verifica a sua configuração, e dependendo desta, pode arrancar imediatamente pela rede, esperar por um pressionar de uma tecla, verificar a unidade de disco antes de arrancar, etc. Normalmente é tentado o boot pela rede de imediato.
4. O Remote Boot começa pelo contacto com um servidor DHCP ou BOOTP, através de um discovery em broadcast. O primeiro servidor a responder devolve à PROM as configurações de rede - endereço IP, default gateway, subnet mask, .... O servidor pode ser Windows NT, Unix, Novell, ou qualquer outro SO que suporte os protocolos standard da Internet.
5. Com esta informação, a PROM pode inicializar a sua própria pilha TCP/IP. Juntamente com as configurações IP, o servidor DHCP/BOOTP também disponibilizou o endereço IP do servidor de Remote Boot - o qual possui o Network Bootstrap Program (NBP) - e o download do NBP é iniciado via TFTP. O NBP é normalmente uma imagem de boot (pode também oferecer um menú com várias imagens possíveis a escolher) com o tamanho de uma disquete. Um RAMdisk é criado na máquina cliente e a imagem lá colocada (existem outros mecanismos, mas disso falaremos depois). Este RAMdisk é criado pois muitos SOs não estão preparados para arrancar em rede; se a máquina cliente possuir um disco rígido local, é também uma alternativa.
6. O PC é instruído a arrancar a partir da RAMdrive, como se trata-se da drive de disquetes. Após o boot, já existe um sistema operativo, o qual pode ser DOS, Windows 9x, Linux ou qualquer outro. O SO irá estabelecer contacto com um servidor e deixará de necessitar da RAMdrive, restaurando a drive de disquetes.
De notar que este é um procedimento base, e que cada uma desta etapas pode variar, dependendo do sistema em causa e do mecanismo de boot adoptado.
Os Mecanismos de Remote Boot
Existem vários mecanismos de Remote Boot no mercado, desde os freeware até às implementações comerciais, e começam já a desenhar-se alguns standards para esta tecnologia. Este estudo irá debruçar-se sobre alguns destes.
Capítulo
3
Mecanismos de Remote Boot
Neste capítulo são analisados vários pacotes de software para Boot ROMs, sendo apresentadas as suas características principais. Adoptou-se por uma abordagem mais virada para ambientes Linux, dado que os ambientes Windows são analisados em mais pormenor nos capítulos seguintes.
No final do capítulo 6, é apresentada uma tabela comparativa, para uma melhor análise e destaque das particularidades de cada tecnologia.
Os mecanismos de Remote Boot a seguir descritos encontram-se agrupados segundo o tipo de tecnologia empregado. Assim, obtemos 2 grupos:
▪ Grupo 1: Netboot, Etherboot – mecanismos não baseados em PXE
▪ Grupo 2: BpBatch – mecanismos baseados em PXE
Visto que os processo de instalação e configuração dos mecanismos de Remote Boot atrás mencionados são bastante semelhantes – pelo menos para sistemas Linux -, será feita uma descrição genérica para a sua implementação, optando-se antes por destacar as suas diferenças e particularidades, sempre que necessário. Assim, apresenta-se um guia de instalação/configuração para os mecanismos Netboot e Etherboot num ambiente Linux. No próximo capítulo, será analisada a tecnologia PXE, assim como mecanismos RB baseados no Preboot Execution Environment da Intel.
Tecnologias Netboot e Etherboot - Não baseadas em PXE
O primeiro passo é saber se as placas de rede que possuimos suportam a instalação de ROMs Etherboot ou Netboot.
A tecnologia ROM do Netboot possui a vantagem de utilizar packet drivers, o que faz com que seja possível a sua implementação em virtualmente qualquer placa de rede, dado que é prática comum os fabricantes os disponibilizarem.
O Etherboot, baseado no Netboot, também permite criar imagens para Boot ROMs, mas utiliza uma aproximação diferente do Netboot - built-in drivers em vez de packet drivers - o que significa que apenas é implementável num número reduzido de NICs (Network Interface Cards).
Apesar de não ser tão universal como o anterior, permite criar EPROMs de tamanho mais reduzido, até mesmo de apenas 8KB, o que faz com que se possa instalar mesmo nas placas mais antigas. No final deste capítulo encontra-se uma lista com algumas das placas suportadas pelo Etherboot.
Requisitos:
▪ Um bootstrap loader (normalmente colocado numa EPROM), embora também seja possível o arranque por disquete - o que servirá mais para testes do que para uma implementação “séria” - dado que também pode ser acedida pela BIOS para o boot
▪ Um servidor BOOTP ou DHCP, para a resolução de um endereços IP, entre outros serviços
▪ Um servidor TFTP para a transmissão de imagens do kernel, assim como outros ficheiros necessários ao boot
▪ Um servidor NFS, de modo a que se possa aceder a drives remotas de rede - para o caso de um boot Linux
▪ Um kernel Linux preparado para montar partições via NFS
Comparação Netboot / Etherboot
São mecanismos de remote boot semelhantes, no entanto possuem algumas diferenças. Assim, enquanto o Netboot suporta um maior número de placas de rede (NIC) devido ao facto de se encontrarem disponíveis packet drivers para quase qualquer placa; mas por outro lado, não permite a detecção automática de placas ISA, sendo necessário especificar pelo menos qual o IRQ e I/O address da placa na altura da programação da ROM. As suas imagens ROM são maiores, o que implica a exclusão de algumas placas de rede que não suportem essa exigência (para contornar um pouco este problema é possível armazenar as imagens em formato comprimido, mas nunca deverão ultrapassar os 32 ou 64KB de tamanho).
O Etherboot permite imagens ROM de dimensões realmente reduzidas (até 8Kb em formato comprimido!), o que faz com que virtualmente qualquer placa de rede suporte esse tipo de ROM, para além de permitir o auto-probe destas, facilitando a configuração. Isto torna-se importante se as placas de rede em causa forem antigas, pois muitas não suportavam mais do que essa quantidade de memória nas ROMs.
Estes argumentos fazem com que não exista “a” escolha acertada. Tanto o Netboot como o Etherboot poderão ser adequados, dependendo das características do hardware já existente. Inclusivé poderão ser utilizados de um modo complementar numa rede, de acordo com as particularidades de cada NIC.
Uma Possível Implementação
Antes de mais, é preciso instalar e configurar os serviços de rede necessários no servidor Linux, de modo a configurar os serviços de suporte ao Remote Boot. Esses serviços são o BOOTP (ou DHCP), o TFTP e o NFS.
BOOTP
No ficheiro /etc/bootptab é preciso criar uma base de dados com informações sobre as máquinas clientes remote boot. Esta contém linhas com o seguinte formato:
cltRB1.domain.pt:ha=006008C7A3D7:ip=192.168.1.10:bf=/tftpboot/vmlinuz.nb
e para cada máquina será necessária uma linha descritiva/identificativa com estes parâmetros. Além destes, outros poderão ser adicionados (ver man pages - bootp), mas para uma configuração básica são suficientes.
Nota Na instalação destes sistemas Remote Boot, embora não seja obrigatório utilizar endereços IP fixos, é aconselhável que assim o seja, pois permite um maior controlo e facilidade na identificação das máquinas clientes. Isto é aplicável no contexto de redes locais e partindo do princípio que temos endereços IP suficientes para todas as máquinas.
TFTP
Para inicializar o serviço TFTP, verificar que a seguinte linha de texto se encontra no ficheiro /etc/inetd.conf (possivelmente estará comentada):
tftp dgram udp wait root /usr/sbin/tcpd in.tftpd -s /tftpboot
Para utilizar este serviço, é necessário criar uma estrutura de directórios onde serão colocados os ficheiros de sistema relativos a cada uma das máquinas clientes. Esta estrutura consiste nos directórios base de uma distribuição do Linux, ou seja:
▪ /etc
▪ /sbin
▪ ...
Não são obrigatórios todos os directórios, apenas os vitais para o sistema, mas dado que o espaço ocupado por estes é bastante reduzido, o administrador pode dar-se ao luxo de desperdiçar um pouco de espaço em disco para simplificar a instalação.
Se o espaço em disco for um factor crucial, ou se o número de máquinas for muito elevado, uma alternativa - mais correcta - é colocar nos directórios das máquinas apenas os ficheiros de sistema que são alterados/escritos, e colocar os restantes directórios numa outra localização para partilha de todas as máquinas (apenas os ficheiros read-only, que não necessitam de escrita). Nesse caso serão colocado nos directórios das máquinas apenas os links para esse directório de partilha.
Será preciso proceder a algumas personalizações de determinados ficheiros para a máquina cliente, sendo aconselhável a criação de um script para a replicação para os restantes clientes (alguns scripts para estas tarefas já estão incluídos na distribuição do Etherboot, assim como documentação e uma secção de troubleshooting).
Principalmente por motivos de segurança, assim como de organização, o root filesystem das máquinas clientes Remote Boot não deve ser o mesmo que o root filesystem do servidor.
O kernel irá esperar encontrar os ficheiros relativos às máquinas clientes em /tftpboot/endereço_IP_maquina. Deve existir um directório por máquina, algo do género:
/tftpboot/192.168.1.10/
/tftpboot/192.168.1.11/
/tftpboot/192.168.1.12/
/tftpboot/192.168.1.13/
/tftpboot/192.168.1..../
Temos agora que configurar e inicializar os serviços NFS.
Network File System - NFS
Com este serviço podemos partilhar directórios remotos residentes em máquinas na rede, de modo a que possam ser acedidos pelo clientes Remote Boot.
Para o suporte a NFS, torna-se necessária a compilação do kernel com a opção “Mount root filesystem from NFS” seleccionada, assim como a opção “Get IP address from original BOOTP reply” (as descrições podem ser ligeiramente diferentes). O driver da placa de rede deve também ser compilado como parte do kernel, em vez de ser incluído como módulo.
No servidor, os daemons rcp.nfsd e rpc.mountd vem estar a correr. Para exportar os filesystems que desejarmos, neste caso as áreas das máquinas clientes, é necessário alterar o ficheiro /etc/exports no servidor - o qual controla quais os filesystems a exportar - para acrescentar os seguintes dados (será necessário repetir o procedimento para cada máquina):
/tftpboot/192.168.1.10 cltRB1.domain.pt(rw,no_root_squash)
O acesso read-write (rw) é necessário para o correcto funcionamento do sistema; o atributo no_root_squash, tal como se pode verificar nas man pages, faz com que o UID 0 (root) ao iniciar uma máquina tenha as suas permissões “divinas” propagadas a todas as partições remotas NFS na rede. Caso não seja especificado, o funcionamento normal de alguns daemons pode ser afectado, pois ficaria sem permissões de escrita.
Em seguida, reiniciar os serviços NFS - cada vez que o ficheiro /etc/exports é alterado, este procedimento é necessário para que os daemons NFS considerem a nova informação - do seguinte modo:
/etc/rc.d/init.d/nfs stop
/etc/rc.d/init.d/nfs start
ou mais simplesmente
/etc/rc.d/init.d/nfs restart
Para além destes áreas com os ficheiros de sistema, deve-se também exportar as áreas pessoais dos utilizadores, para que estes possam aceder aos seus dados e para que as suas configurações/personalizações do SO possam ficar armazenadas nas suas respectivas áreas. Os dados relativos às áreas dos users devem também estar definidas em /etc/exports e em /etc/fstab.
A Criação da Boot Disk
Para criar uma disquete de boot, a qual permitirá testar o sistema RB, um boot block especial é disponibilizado nas distribuições. Este é um pequeno programa de apenas 512 bytes, ao qual compete arrancar com o código que se lhe segue na disquete para a memória da máquina, e iniciar a sua execução. Para introduzirmos esse código – que é o driver Etherboot ou Netboot específico para a a placa de rede – basta concatená-lo com o boot block:
cat floppyload.bin modeloNIC.lzrom > dev/fd0
A imagem do SO, resultante da compilação do kernel, necessita ainda de um procedimento extra, derivado do facto de ser necessário um bootstrap program para a carregar na máquina cliente, numa fase em que ainda não existe sistema operativo. Assim, esta deve ser transformada numa tagged image, que não é mais do que a imagem do kernel com um header que contem informação adicional sobre onde colocar os bytes em memória, e qual o endereço de memória a ser utilizado para arranque do boot block.
Por exemplo, a tagged image conterá o ficheiro bzImage e opcionalmente o ficheiro initrd.gz (no caso da implementação de um RAMdisk);
Para a sua criação, pode-se utilizar o utilitário mknbi-linux, o qual vem com a distribuição do pacote Etherboot.
mknbi-linux -x -i rom -k bzImage -r initrd.gz \ -a "ramdisk_size=10240" -o /tftpboot/clientnbi
Ao que se seguem algumas perguntas,
e depois a atribuição de permissões de leitura para toda a gente
chmod a=r,u+w /tftpboot/vmlinuz.nb
A tagged image é colocada em /tftpboot com a mesma designação encontrada no ficheiro /etc/bootptab (ver secção BOOTP acima). Importante: não esquecer de colocar permissões de leitura para todos os utilizadores!
Concluída esta série de passos, é possível testar a configuração, procedendo com o arranque de um cliente Remote Boot. Na máquina cliente, deve aparecer uma ecrã semelhante a este:
Após um remote boot bem sucedido, o passo lógico seguinte será passar este código resultante para uma PROM na placa de rede, para uma solução mais duradoura e fiável.
Nota Não foi feita distinção entre este processo no Netboot e no Etherboot, dado que são configurações muito semelhantes
Resumidamente, após a instalação do sistema, devemos ter no servidor:
▪ um servidor BOOTP configurado e pronto para receber pedidos de clientes
▪ um servidor TFTP apropriadamente configurado
▪ um kernel configurado e compilado com as opções necessárias (NFS, ...) atrás referidas
▪ um estrutura de directórios para as máquinas clientes com uma instalação básica do Linux
▪ um servidor NFS devidamente configurado e com partições montadas para acesso remoto - tanto das áreas dos utilizadores como das máquinas clientes
Na altura em que este documento foi realizado, está em fase de desenvolvimento um outro mecanismo de Remote Boot baseado na tecnologia PXE - o NILO (Network Interface Loader) - mas ainda se encontra numa fase embrionária. É uma espécie de evolução do Etherboot, também freeware. Quem estiver interessado pode dar uma olhadela em nilo..
A Solução X-Terminal
Uma aplicação interessante de um mecanismo Remote Boot - como o Etherboot ou o Netboot -,especialmente em Linux, são os X-terminals.
O Linux possui a vantagem de ser um SO pensado de raíz para uma implementação distribuída e o sistema X-Windows não é excepção.
Através de uma aplicação - o XDM (X Display Manager) - a correr numa máquina remota é estabelecida uma ligação com um X-terminal, sendo apresentado um ecrã de login. Após o utilizador se ter autenticado na máquina remota, corre todas as aplicações remotamente.
Os X-terminals são máquinas tipicamente sem disco local, com adaptador gráfico e placa de rede.
Está desenhado desde o início para que as máquinas clientes X (as que contêm as aplicações) possam comunicar através da rede com o servidor X (X-Server). Deste modo o processamento é remoto, sendo realizado no cliente X, e ao servidor X compete apenas “digerir” e processar as primitivas gráficas enviadas pela máquina remota. O tráfego de rede consiste em comandos gráficos e respostas a estes mesmos, não em imagens, tornando-o menos pesado. Ex: desenhar janela nas coordenadas XY, ...
Nos X-terminals a prioridade é a interface com o utilizador, pois não realizam processamento local para além das rotinas gráficas - o que implica que devem ter uma boa placa gráfica para uma boa performance, acompanhada de um monitor com uma qualidade razoável, de preferência.
Vantagens:
▪ Diskless - menor TCO (Total Cost of Ownership), menor ruído no ambiente de trabalho, menor taxa de problemas locais, o software está completamente centralizado nos servidores
▪ Processamento distribuído - o X-terminal trata do processamento gráfico localmente e o enquanto que o restante processamento é realizado remotamente
▪ Reaproveitamento de material informático antigo, mesmo os antigos 386 (convém que sejam pelo menos 386DX) e 486
Desvantagens:
▪ A máquina remota (servidor de aplicações) fica com a carga de todas as máquinas. Logo para prevenir situações de sobrecarga, deve estar equipado com um CPU capaz e uma quantidade de memória razoável. Para compensar, as aplicações Linux possuem mecanismos para optimizar o uso da memória, através por exemplo da partilha do mesmo segmento de memória por várias instâncias de uma mesma aplicação, ou da manutenção em cache das libraries partilhadas. É também possível ter mais de um servidor remoto para servir um cluster de máquinas X, de modo a distribuir a carga de processamento.
Para a implementação de um sistema X, é necessário no entanto instalar e configurar alguns serviços de suporte. Esses podem ser:
▪ NIS ou Yellow Pages - para que os utilizadores possam efectuar a sua autenticação em qualquer X-terminal (uma única base de dados central para a autenticação e autorização, através da partilha do UUID de cada utilizador independentemente da sua localização)
▪ RSH (Remote Shell) - para a execução de comandos em máquinas remotas sem a necessidade de efectuar uma nova autenticação
▪ NFS (Network File System) - para o acesso a ficheiros em partições remotas, sem necessitar de uma nova autenticação
Para Saber Mais
nilo.
rmatik.uni-koeln.de/nais
etherboot.
han.de/~gero/netboot.html
dei.isep.ipp.pt/~andre/documentos
3COM
# 3Com503, aka Etherlink II, also /16 model
3c503 ns8390
# 3Com507 (i82586 based)
3c507 i82586
# 3c509, ISA/EISA
3c509
# 3c529 == MCA 3c509
3c529 3c509
# 3c59x cards (Vortex)
3c590 3c595 0x10b7,0x5900
3c595 3c595 0x10b7,0x5950
3c595-1 3c595 0x10b7,0x5951
3c595-2 3c595 0x10b7,0x5952
# 3C90x cards device IDs
# Original 90x revisions:
# 0x9000 : 10 Base TPO
# 0x9001 : 10/100 T4
# 0x9050 : 10/100 TPO
# 0x9051 : 10 Base Combo
# Newer 90xB revisions:
# 0x9004 : 10 Base TPO
# 0x9005 : 10 Base Combo
# 0x9006 : 10 Base TP and Base2
# 0x900A : 10 Base FL
# 0x9055 : 10/100 TPO
# 0x9056 : 10/100 T4
# 0x905A : 10 Base FX
# Newer 90xC revision:
# 0x9200 : 10/100 TPO (3C905C-TXM)
3c905-tpo 3c90x 0x10b7,0x9000
3c905-t4 3c90x 0x10b7,0x9001
3c905-tpo100 3c90x 0x10b7,0x9050
3c905-combo 3c90x 0x10b7,0x9051
3c905b-tpo 3c90x 0x10b7,0x9004
3c905b-combo 3c90x 0x10b7,0x9005
3c905b-tpb2 3c90x 0x10b7,0x9006
3c905b-fl 3c90x 0x10b7,0x900a
3c905b-tpo100 3c90x 0x10b7,0x9055
3c905b-t4 3c90x 0x10b7,0x9056
3c905b-fx 3c90x 0x10b7,0x905a
3c905c-tpo 3c90x 0x10b7,0x9200
Crystal Semiconductor CS89x0
cs89x0
Digital DE100 and DE200
depca depca
Intel Etherexpress Pro/100
eepro100 eepro100 0x8086,0x1229
SMC 83c170 EPIC/100
epic100 epic100 0x10b8,0x0005
Exos 205 (i82586 based)
exos205 i82586
Lance PCI PCNet/32
lancepci lance 0x1022,0x2000
Linksys LNE100TX and other NICs using this Tulip clone chip
lc82c115 tulip 0x11ad,0xc115
Netgear FA310TX and other NICs using this Tulip clone chip
lc82c168 tulip 0x11ad,0x0002
Tulip clones based on the ADMtek Centaur-P
admtek0985 tulip 0x1317,0x0985
Tulip clones based on the Macronix 987x5
mx987x5 tulip 0x10d9,0x0553
Davicom DM9102
davicom tulip 0x1282,0x9102
NE1000/2000 and clones (ISA)
ne ns8390
Novell NE2100 (Lance based, also works on NE1500)
ne2100 lance
NE2000 PCI clone (RTL8029)
nepci ns8390 0x10ec,0x8029
Winbond 86C940
winbond940 ns8390 0x1050,0x0940
Compex RL2000
compexrl2000 ns8390 0x11f6,0x1401
KTI ET32P2
ktiet32p2 ns8390 0x8e2e,0x3000
NetVin 5000SC
nv5000sc ns8390 0x4a14,0x5000
Racal-Interlan NI5210
ni5210 i82586
Racal-Interlan NI6510 (Lance based)
ni6510 lance
Base driver for Tulip clones
tulip tulip 0x1011,0x0002
# Tulip-Fast
tulipfast tulip 0x1011,0x0009
# Tulip+
tulip+ tulip 0x1011,0x0014
# Tulip 21142
tulip21142 tulip 0x1011,0x0019
Realtek
# Realtek 8029 (NE2000 PCI clone)
rtl8029 ns8390 0x10ec,0x8029
# Realtek 8139
rtl8139 rtl8139 0x10ec,0x8139
# SMC1211 (uses Realtek 8139 but with different IDs)
smc1211 rtl8139 0x1112,0x1211
Schneider and Koch G16
sk_g16
SMC9000
smc9000
Tiara, Fujitsu Lancard
tiara
Old base driver for Tulip clones
otulip otulip 0x1011,0x0002
Rhine-I, e.g. D-Link DFE-530TX
dlink-530tx via-rhine 0x1106,0x3043
# Rhine-II
via-rhine via-rhine 0x1106,0x6100
WD8003/8013, SMC8216/8416
wd ns8390
Winbond W89c840
winbond840 w89c840 0x1050,0x0840
Compex RL100-ATX
compexrl100atx w89c840 0x11f6,0x2011
Mecanismos PXE
WfM - Wired for Management
Capítulo
4
Esta é uma nova iniciativa levada a cabo pela Intel, apoiada por um conjunto cada vez maior de fabricantes de hardware, inclusivé por alguns dos seus concorrentes mais directos, como a AMD. Consiste numa especificação que pretende tornar-se um standard no mercado dos PCs. O seu objectivo é a integração num só standard - um standard aberto, ou seja, que permite a adição de funcionalidades por parte dos fabricantes - de um conjunto de tecnologias para a uniformização e a redução de custos com a gestão de redes.
Traz consigo a vantagem o facto de se basear em tecnologias já existentes, não obrigando a uma reformulação de sistemas, pois é compatível com os já existentes, adicionando-lhes funcionalidades extra de modo a criar um conjunto coeso e interligado de mecanismos.
As principais vertentes do WfM são:
▪ gestão preboot (PXE)
▪ gestão de informação (DMI)
▪ power management (ACPI)
▪ Wake up remoto de máquinas (Wake-on-LAN)
É constituída por vários componentes, sendo de destacar:
▪ tecnologia PXE (Preboot Execution Environment)- a base do WfM, permite o remote boot.
▪ Wake-on-LAN - permite iniciar a gestão remota de máquinas, mesmo com estas desligadas.
▪ Desktop Management Interface - permite gerir componentes de um sistema, guardando informação sobre estes.
fig. 4
[pic]
Desktop Management Interface (DMI)
Trata-se de um novo standard para permitir a gestão de componentes de PCs. Qualquer componente - disco duro, placa de rede, aplicação de software, ... - desenhado como DMI-compliant pode comunicar com aplicações de gestão/administração via DMI. Isto é, a tecnologia DMI serve de intermediária entre os componentes e as aplicações de gestão.
fig. 5
O seu objectivo é armazenar informações sobre os componentes, permitindo consultar e alterar essa informação.
O seu modo de funcionamento é realizado da seguinte maneira: a informação sobre cada componente é guardado num ficheiro do tipo Management Information Format (MIF) - todos os componentes têm o seu ficheiro próprio. Aqui são guardadas informações como a localização do componente, fabricante, data de instalação.
Quando é instalado suporte DMI para um componente, uma nova entrada é realizada na MFI Database, através do Service Layer (este é um software que pode fazer parte do SO, ou então é instalado como add-on; em DOS, é carregado no AUTOEXEC.BAT, como se de um driver se tratasse).
Um exemplo de uma aplicação de gestão DMI é a Intel LANDesk Manager 2.0.
Um problema que se destaca imediatamente é que apenas é possível praticar esta tecnologia em componentes e computadores relativamente recentes.
Wake-on-Lan
Uma workstation PXE-compliant possui um jumper na sua motherboard para permitir a ligação à placa de rede (pode não existir se esta se encontrar já embutida na própria motherboard), de modo a que mesmo que a máquina se encontre desligada, a NIC fique continuamente à escuta na LAN de um “magic packet” - o MAC address da placa repetido 6 vezes -, sinal de que a máquina se deve ligar automaticamente.
Assim que esta “acorda” - partindo do pressuposto de que o network boot foi previamente seleccionado na BIOS - o IPL(Initial Program Load) da máquina cliente utiliza o UNDI (Universal Driver Interface) para inicializar a placa de rede e realizar o boot.
Nota Para este procedimento ter sucesso é necessário que a máquina possua uma BIOS PXE, e que a opção PXE esteja activa na BIOS.
PXE
Esta tecnologia é baseada numa série de protocolos já existentes para a Internet, como sejam o TCP/IP, o DHCP e o TFTP. É também o componente principal da filosofia Wired for Management, servindo de pilar para os restantes componentes WfM.
Tem por objectivo definir um standard para a comunicação entre clientes e servidores, em particular a nível das boot ROMs.O seu processo de Remote Boot possuí muitas semelhanças com outros mecanismos de Remote Boot já analizados neste documento, dado que se baseia nos mesmos protocolos, no entanto possui algumas particularidades, especialmente a nível do DHCP e TFTP.
O PXE especifica extensões (TAGs) ao protocolo DHCP que poderão ser incompatíveis com alguns servidores DHCP; para contornar esse problema é disponibilizado, com a sua distribuição, um serviço “proxy DHCP”, o qual não atribui endereços IP aos clientes, mas permite o funcionamento normal do serviço DHCP e presta adições ao DHCPOFFER do servidor DHCP (será explicado em maior detalhe mais à frente).
No que toca ao protocolo TFTP, o PXE pede servidores TFTP especiais, com suporte para blocos com 1408 bytes ao contrário dos habituais 512 - o que torna a transmissão mais rápida com um meio fiável, como é o caso na maior parte das redes locais. Mas mais importante, também possibilita a utilização de um protocolo baseado no TFTP - o MTFTP, ou Multicast TFTP - o qual permite realizar o boot simultâneo de N máquinas numa rede, o que aliado ao Wake-on-LAN constitui uma ferramenta interessante.
Como é possível verificar, existe uma interligação entre os vários mecanismos WfM.
A implementação nos servidores
Do lado servidor devem estar disponíveis serviços que permitam o redireccionamento do cliente para o servidor de Boot, após a obtenção de um endereço IP. Existem 2 modos de os implementar:
o serviços DHCP e redireccionamento num só servidor - o servidor DHCP para além de atribuir endereços IP, acumula com o serviço de redireccionamento dos clientes; para atingir este objectivo, ou se modificam os servidores já existentes ou então estes são substituídos por novas versões.
o serviços DHCP e redireccionamento separados - é instalado um servidor PXE de redireccionamento (Proxy DHCP server), o qual apenas responde a clientes PXE, mas não atribui endereços IP aos clientes; mantém-se o servidor DHCP.
A implementação nos clientes
Os clientes devem possuir hardware com ROMs PXE, tanto na BIOS ROM da máquina, como na placa de rede (boot ROM). Em algumas máquinas existe uma única ROM PXE, pois a placa de rede está integrada na motherboard. No caso de não se verificarem estas condições, poderá eventualmente ser possível o remote boot do cliente através de uma disquete de boot, mas essa possibilidade está dependente do suporte do sistema operativo em causa (ex: ver secção Win2000 Remote Instalation Services).
A API PXE
Permite a interligação entre os clientes e os bootstrap programs, o código PXE no cliente disponibiliza uma série de serviços para uso da BIOS ou de um NBP. Está dividida em 4 categorias:
o Preboot API - constituída por várias funções de controlo gerais
o TFTP API - relativa ao protocolo TFTP, estabelecimento e encerramento de sessões, leitura e escrita de pacotes
o UDP API - relativa ao protocolo UDP, estabelecimento e encerramento de ligações, leitura e escrita de pacotes
o UNDI API - controlo básico de funções Input/Output através do NIC do cliente. Permite a utilização de drivers universais para NICs que implementem esta API.
fig. 6
[pic]
A API UNDI vai trazer consigo a independência do fabricante e modelo da placa de rede, desde que este esteja conforme com as especificações PXE. Esta é uma das grandes vantagens desta tecnologia - um standard universal para todas as placas.
O Processo de Remote Boot num sistema que utilize a tecnologia PXE é basicamente o seguinte:
fig. 7
[pic]
BpBatch - Exemplo de Aplicação da Tecnologia PXE
O BpBatch é um mecanismo de remote boot baseado na tecnologia PXE que, como os outros já aqui referidos, permite a realização de uma série de procedimentos num computador cliente aquando do boot, antes do arranque do sistema operativo. Estes procedimentos podem ser vários, como particionar um disco, autenticar utilizadores, ou a criação de um interface gráfico para apresentação de opções de boot.
Um dos seus principais atributos é a possibilidade de cópia (clonagem) de uma imagem de partição de disco para utilização num cluster de máquinas. Assim, é possível através de uma imagem criada e optimizada, distribuir e instalar a mesma numa série de computadores, através da rede.
Resumidamente, as suas principais potencialidades são:
▪ Apresentação de interface gráfica para os utilizadores - com suporte para altas resoluções, até 1600x1200
▪ Operações de baixo nível no disco - com bom desempenho, permite formatações rápidas de partiçoes (FAT16, FAT32, Linux EXT2 e Linux Swap), e outras operações. Para além destas, permite realizar operações de alto nível, como copiar e mover ficheiros, criar directórios, ...
▪ Autenticação de utilizadores - possui um servidor de autenticação (STFTP), o qual suporta vários protocolos, de destacar o NIS e o NT
▪ Replicação de imagens de disco - permite restaurar uma nova partição na máquina cliente, a partir de uma imagem armazenada numa partição escondida do disco. Segundo o fabricante, esta operação é realizada em menos de 1 minuto, o que a provar-se, é uma excelente performance. Não obriga a uma nova transferência da imagem pela rede, a menos que a imagem de referência no servidor tenha sofrido alguma alteração, o que contribui para a redução do tráfego na rede.
Dadas estas características, rapidamente se depreende que o Bpbatch está mais pensado para Remote Boot com máquinas clientes detentoras de uma unidade de disco local, no entanto também é possível em máquinas diskless - embora essa não seja a configuração mais comum.
Seguem-se descrições conceptuais das principais particularidades de implementação deste mecanismo de Remote Boot, organizadas por SO.
Parte Cliente - Linux
▪ Diskless RB
Existem duas aproximações para a configuração RB, na criação de um root filesystem:
1. Utilizar um RAMdisk (initrd) - permite uma melhor performance, e reduz o tráfego na rede, quando comparado com o NFS-root. Como o seu tamanho é limitado, é necessário realizar uma selecção criteriosa dos ficheiros a lá colocar - devem lá estar os ficheiros necessários ao arranque de um cliente básico, assim como alguns dos ficheiros mais utilizados.
Todos os restantes ficheiros devem ser montados através de NFS.
2. Utilizar um filesystem remoto (NFS-root)
▪ Disk-based RB
Se o cliente possui uma unidade de disco local, isso traz consigo uma série de vantagens, especialmente em performance e redução do tráfego de rede. Existem 3 aproximações para a configuração com disco, no contexto de Remote Boot:
1. Como cache para o kernel e para as imagens RAMdisk
2. Como cache para um filesystem remoto (NFS)
3. Como um gigante RAMdisk - sendo feita uma limpeza e refresh do conteúdo da partição a cada reboot. O Bpbatch consegue taxas de escrita num filesystem ext2 de cerca de 3MB/seg.
Parte Servidor - Linux
Como em todos os outros mecanismos RB já analisados, é necessário instalar e configurar um servidor DHCP (ou BOOTP, embora o DHCP seja aconselhável pois permite opções mais avançadas), um servidor TFTP e um servidor NFS.
Servidor DHCP
Um servidor DHCP recente é a melhor opção, como o ISC DHCP 2.0, o qual vem por exemplo com as distribuições do RedHat Linux 5.x e superior. Caso contrário, é só fazer o download a partir de .
Após a sua instalação, para alterar a configuração, basta editar o ficheiro /etc/dhcpd.conf.
Como já foi referido atrás, uma Boot ROM PXE exige alguns parâmetros específicos para DHCP. Se estiverem ausentes, o processo de boot não será possível. Esses parâmetros são:
▪ Informação IP - endereço IP, default gateway, subnet mask
▪ Informação relativa à BootROM - endereço IP do servidor e nome do ficheiro de boot (NBP); este mais tarde será descarregado via TFTP do servidor e executado.
▪ Informação específica PXE
É ainda possível definir uma série de informações a serem utilizadas pelo SO iniciado pela bootROM PXE, como o hostname, o servidor DNS, o servidor NIS, ...
Segue-se a título demonstrativo o conteúdo de um ficheiro de configuração do ISC DHCP 2.0, com algumas das configurações mais importantes em destaque:
#
# DHCP configuration file. ISC DHCP server v2.0
#
#
# Global parameters
#
# Use declaration identifier as hostname
use-host-decl-names on;
#
# Shared-network definition
#
shared-network companynet {
#
# Company-wide parameters
#
option domain-name "";
#
# Subnet definition
#
subnet 192.168.1.0 netmask 255.255.255.0 {
#
# Subnet-specific information
#
# Default gateway
option routers 192.168.1.1;
# DNS server
option domain-name-servers 192.168.1.2;
#
# PXE group declaration
#
group {
#
# PXE specific parameters
#
# Infinite lease time
default-lease-time -1;
# TFTP server IP address
next-server 192.168.1.2;
# Name of the bootstrap program
filename "bpbatch";
# Vendor class setup for PXE
option dhcp-class-identifier "PXEClient";
# Vendor-specific parameters
# Since we do not use PXE parameters in
# this example, we set this option to
# 01:04:00:00:00:00 which means 'NULL parameter'
option vendor-encapsulated-options 01:04:00:00:00:00;
# BpBatch specific parameters
option option-135 "bpbscript";
# User-level parameters (opt 128 to 135 free for use)
option option-132 "workgroup";
#
# PXE hosts
#
host cliente_pxe1 {
hardware ethernet 00:54:55:56:67:68;
fixed-address 192.168.1.100;
}
}
host cliente_pxe2 {
hardware ethernet 00:54:55:56:67:69;
fixed-address 192.168.1.101;
}
}
}
}
Nota No parâmetro # Name of the bootstrap program, o nome do ficheiro de boot implica o tipo de serviço TFTP associado. Ou seja, “bpbatch“ implica um serviço TFTP normal na porta 69, “bpbatch.P” um serviço TFTP com suporte para large packets na porta 59, ...
Servidor TFTP
Na realidade, deve ser utilizado um servidor TFTP “vitaminado”, de modo a permitir uma transferência mais rápida de blocos de dados. Estes normalmente suportam também MTFTP, que traz consigo uma redução do tráfego gerado na rede - no entanto o BpBatch não tira proveito disso pois não utiliza o protocolo MTFTP. Para Linux, temos pelo menos 2 servidores TFTP avançados: o do Incom/Bootix e o “Intel TFTP for Linux”.
O servidor avançado de TFTP da Incom incorpora as seguintes características:
▪ serviço de TFTP standard na porta 69
▪ serviço enhanced para large blocks na porta 59
▪ MTFTP
Para configurar este servidor, basta definir um directório para o armazenamento dos ficheiros para download e arrancar com o daemon TFTP. Isto pode ser realizado da seguinte maneira:
tftpd.incom -c 64 -d /tftpboot -h -i 0 -k 5 -l /var/log/tftp.log -r
-s 1408 59 -v 2
Nota Este servidor da Incom não pode ser inicializado através do inetd, ao contrário dos outros já estudados.
Parte Cliente - Windows
As opções aqui são as mesmas do que as apresentadas para a parte cliente no Linux, as verdadeiras diferenças estão no servidor.
Parte Servidor - Windows
Do mesmo modo que o Linux, o Windows NT também pode ser utilizado como servidor de Remote Boot, com serviços de DHCP e TFTP.
Servidor DHCP
É aconselhável utilizar o servidor DHCP original do Windows NT. O primeiro passo a tomar após a sua instalação é a definição de um scope de endereços IP, dentro do qual o serviço DHCP pode atribuir dinamicamente IPs a clientes que o requisitem. Para a definição de IPs estáticos, basta criar reservations.
Recomenda-se o download do pacote “Intel PXE Product Development Kit (PDK) for Windows” em pois inclui uma série de serviços para o Windows NT. Com a instalação do PDK, é também dispensado o serviço Proxy DHCP; para o desactivar, basta ir aos “Services” e fazer Disable em “Intel boot services”.
Os parâmetros necessários para o serviço DHCP são os mesmos necessários para o ambiente Linux, ou seja:
▪ Informação IP - endereço IP, default gateway, subnet mask
▪ Informação relativa à BootROM - endereço IP do servidor e nome do ficheiro de boot (NBP); este mais tarde será descarregado do servidor via TFTP e executado.
▪ Informação específica PXE
Quanto à informação IP, o endereço IP a atribuir às máquinas clientes, assim como a subnet mask já se encontram definidos aquando da criação do scope. O mesmo se pode aplicar ao default gateway, o qual é definido no DHCP Server (nas “Administrative Tools”).
Uma nota é de realçar: o servidor TFTP tem de estar presente na mesma máquina que corre o servidor DHCP. Isto devido a limitações do servidor DHCP, o qual não permite o acesso ao parâmetro DHCP bootfilename, não permitindo por tabela que se modifique o endereço IP do servidor que contem o bootfilename; o que acontece então é que coloca o seu próprio endereço IP - o do servidor DHCP - nesse campo, logo obrigando a que o servidor TFTP esteja no mesmo computador (ou então a um grande malabarismo!).
Servidor TFTP
Pelo menos 2 servidores avançados TFTP encontram-se disponíveis para o Windows NT: o “Incom/Bootix TFTP server” e o “Intel TFTP server”, sendo o último o mais recomendado, além do mais encontra-se já incluído no package “Intel PXE PDK for Windows”.
A configuração do TFTP é realizada no Registry, através da modificação das keys. As keys a alterar encontram-se descritas na documentação do PXE PDK. Para se definir a localização dos ficheiros para download via TFTP, é preciso alterar a key:
HKEY_LOCAL_MACHINE\SOFTWARE\Intel\PXE\MTFTPD\BASE_DIR
Nota O nome do ficheiro de boot implica o tipo de serviço TFTP associado. Ou seja, “bpbatch“ implica um serviço TFTP normal na porta 69, “bpbatch.P” um serviço TFTP com suporte para large packets na porta 59, “bpbatch.B” large packets na porta 69 (com opção blksize)
Para Saber Mais
Uma descrição mais detalhada de todo o processo de instalação e configuração do BpBatch, quer para Windows, quer para Linux, está disponível no “Linux Remote Boot Mini-Howto” em cuiunige.ch/info/pc/remote-boot/howto.html ou numa das várias distribuições do SO Linux (RedHat, Debian, ...).
Outras fontes de informação:
- Preboot Execution Environment Specification (PXE), Intel Corporation, 1999
developer.
SeS Windows 2000 Server - RIS
Capítulo
5 indows 2000 Server - RIS
Introdução
O sistema operativo Microsoft Windows 2000 Server traz consigo, como componente opcional, o conjunto de serviços “Remote Installation Services (RIS)”. No entanto, trata-se de uma aproximação diferente das analisadas nos outros capítulos deste documento; Primeiro, porque é apenas uma solução parcialmente remote boot, isto é, o mecanismo de remote boot do Win2000 é um meio para atingir um fim - a instalação remota de SO’s. Segundo, porque obriga a que as máquinas clientes possuam uma unidade de disco local - no entanto é realizado remote boot sempre que uma máquina cliente é ligada - dado que o sistema operativo fica instalado localmente, mas com a possibilidade de a qualquer altura ser modificada a imagem do SO.
Assim, apenas no caso de se pretender um nova configuração do SO se justifica que se efectue remote boot para o carregamento de uma nova imagem do SO, ou então no caso de se verificarem danos na instalação local.
Neste Capítulo, descrevem-se as funcionalidades do RIS, sendo de notar que todas as informações aqui descritas foram fornecidas pela Microsoft, em acréscimo a alguma implementação prática.
fig. 8
Esquema Geral do Processo de Instalação Remota do Windows 2000
[pic]
1. O cliente PXE envia um pacote DHCP discover para encontrar o servidor DHCP e o servidor RIS
2. O servidor DHCP devolve um endereço IP para o cliente
3. O servidor RIS devolve o endereço IP do servidor de boot (TFTP)
4. O cliente PXE contacta o servidor de boot TFTP - neste caso é a mesma máquina que o servidor RIS
5. O servidor de TFTP envia o “Microsoft Client Installation Wizard” ao cliente
6. O cliente envia a informação necessária para a sua autenticação, para o servidor RIS
7. O servidor verifica quais as instalações possíveis para aquele utilizador (aquelas a que o utilizador possui permissões), através de uma pesquisa no Active Directory
8. É devolvido um menu de imagens de SOs
9. O utilizador escolhe a imagem desejada e a instalação toma início
A Tecnologia Remote Boot ROM PXE e os Windows 2000 RIS
Os Remote Instalation Services socorrem-se do protocolo DHCP e da tecnologia PXE para iniciar o processo de remote boot dos computadores clientes.
De um modo simplificado, processo desenrola-se da seguinte maneira:
Quando uma máquina cliente é ligada, vai requerer um endereço IP, o qual lhe é atribuído pelo servidor de DHCP, assim como o endereço IP do servidor RIS e o nome da imagem de boot que o cliente necessitará para iniciar o processo de boot; juntamente com o pedido inicial, o cliente remote boot envia também o seu identificador únivoco (GUID ou UUID), o qual será utilizado para verificar a sua identificação no Active Directory pelo servidor RIS, para detectar se essa a máquina cliente já alguma vez realizou o processo de instalação.
Se o GUID / UUID da máquina não for encontrado no Active Directory e a opção de “Respond to clients requesting service” (responde ao pedido de qualquer máquina, conhecida ou não) foi seleccionada na configuração do RIS, então é realizado o download do “Client Installation Wizard” para o cliente remote boot via TFTP (Trivial File Transfer Protocol) após o cliente ter carregado em F12.
Se, no entanto, o servidor estava configurado para apenas responder a máquinas previamente conhecidas, o download não é possível, assim como a instalação do sistema operativo.
Todo este processo é repetido sempre que um cliente remote boot pede um boot de rede.
Nota Durante este processo inicial de remote boot, não existe qualquer tipo de protecção de dados, como por exemplo a encriptação de dados, o que deve ser tomado em conta.
Pré-Requisitos
Software (Servidor)
É necessário que os seguintes serviços estejam previamente instalados:
- Domain Name Service (DNS) Server;
- Dynamic Host Configuration Protocol (DHCP) Server;
- Active Directory Service (AD);
Hardware (Servidor)
- Processador Pentium ou Pentium II 200 MHz recomendado (P166MHz mínimo)
- Com serviços adicionais instalados, como Directory Service, DHCP, DNS, a quantidade mínima de memória RAM exigida varia entre 96MB e128MB, como requisitos mínimos
- Unidade Disco de 2GB mínimo para a RIS directory tree, preferencialmente SCSI, nesse caso obviamente será necessário acrescentar um controlador SCSI
- Placa de rede 10 ou 100 Mbps, sendo recomendados os 100Mbps, dado o intenso tráfego nestes sistemas remote boot
Hardware (Cliente)
- Processador Pentium 166MHz
- 32 MB memória RAM
- Unidade de Disco 1,2 GB
- boot ROM PXE baseada em DHCP, versão .99c ou superior; como alternativa um placa de rede suportada pela RIS floppy (ver abaixo)
Placas de Rede suportadas pela RIS Boot Floppy
- 3COM
o 3c900 (Combo e TP0)
o 3c900B (Combo, FL, TPC, TP0)
o 3c905 (T4 e TX)
o 3c905B (Combo, TX, FX)
- AMD
o AMD PCNet e Fast PCNet
- Compaq
o Netflex 100 (NetIntelligent II)
o Netflex 110 (NetIntelligent III)
- Digital Equipment Corporation (DEC)
o DE 450
o DE 500
- Hewlett-Packard (HP)
o HP Deskdirect 10/100 TX
- Intel Corporation
o Intel Pro 10+
o Intel Pro 100+
o Intel Pro 100 B (incluíndo os modelos E100)
- SMC
o SMC 8432
o SMC 9332
o SMC 9432
Remote Installation Services - RIS
Cumpridos os pré-requisitos atrás descritos, torna-se possível a instalação dos serviços RIS/RB.
Assume-se que já estão instalados e configurados o serviço de DNS, num domain controller (caso ainda não o seja, utilizar a aplicação DCPROMO para realizar a promoção ao servidor) e o serviço de DHCP devidamente autorizado no Active Directory (caso contrário não conseguirá atribuir endereços IP aos clientes).
De notar que o RIS depende do Active Directory (AD) em vários aspectos, desde a localização de máquinas clientes até aos servidores RIS existentes. Por esse motivo, este serviço tem de estar instalado num servidor Windows 2000 com acesso ao Active Directory, quer seja um domain controller ou simplesmente um servidor pertencente a um domain com acesso ao AD.
Nota Ao longo deste capítulo, sempre que se encontrar uma referência a máquina cliente ou computador cliente, significa, respectivamente, máquina cliente de remote boot e computador cliente de remote boot (apenas por questão de conveniência).
A Instalação do RIS
Trata-se de um processo relativamente simples, no entanto merece alguns comentários. Os passos principais são os seguintes:
1. No command prompt digitar RISETUP.EXE, o que irá dar início a um wizard
2. É pedida a localização do servidor, pelo que se deve identificar o path completo de destino dos ficheiros RIS a instalar.
Nota A unidade de disco destino tem de estar formatada como NTFS, e não pode ser a mesma onde está instalado o Windows 2000 Server; além destas restrições, deverá também conter espaço suficiente (mínimo 800MB - 1GB) para conter um CD completo do Windows 2000 Professional
3. Em seguida coloca-se uma opção:
“Respond to clients requesting service” – logo após a conclusão do processo de setup, o RIS começa de imediato a aceitar pedidos de máquinas clientes. Por defeito não se encontra activa, pois é mais comum configurar após o Setup.
“Do not respond to unknown client computers” – caso a anterior seja seleccionada, permite filtrar as máquinas que tentam aceder ao servidor, atendendo apenas às já conhecidas. Por outras palavras, só as máquinas constantes do Active Directory são consideradas. Isto não é só uma forma de autenticação, mas também permite a coexistência de vários sistemas remote boot numa mesma rede física, dado que possui a propriedade de ignorar as máquinas que não constam da sua lista.
4. Em seguida, é pedido o disco do Windows 2000 Professional, seguido da descrição para o directório dos ficheiros a copiar para o remote installation server. Este irá ficar abaixo na hierarquia do directório escolhido atrás no passo 2. Exemplo: D:\RemoteInstall\win2000pro
Nota O RIS apenas suporta a instalação do sistema operativo Windows 2000 Professional nos clientes!
É pedido um descritor e um texto de ajuda para a identificação do tipo de imagem criado, algo do género: “Windows 2000 Professional – Alunos do DEI”. Este será o descritor que irá aparecer nas máquinas clientes aquando do client installation wizard (OSCHOOSER), no início do processo de remote boot.
Aqui termina o processo de instalação do RIS.
5. Agora é necessário autorizar o RIS server no Active Directory, caso contrário os clientes não conseguirão comunicar com o servidor. No entanto, este passo apenas é necessário no caso de o RIS não ter sido instalado num servidor DHCP já existente e autorizado no Active Directory. Caso contrário a próxima secção pode ser ignorada.
Autorização do RIS no Active Directory
O RIS permite o controlo dos servidores RIS presentes na rede, indicando quais e que clientes servem.
Após realizar o logon como administrador do domain em causa, iniciar o DHCP Manager. Escolher a opção “Manage Authorized Servers” após carregar com o botão direito do rato em DHCP e seleccionar “Add” para introduzir o endereço IP do servidor RIS. E pronto!
Configuração do RIS
Para iniciar, arrancar com o Directory Management snap-in a partir do RIS server console. Em seguida, fazer “Start Menu—Programs--Administrative Tools—Active Directory Users and Computers”
fig. 9
Aparece o seguinte ecrã:
Agora:
1. Após localizar o objecto que representa o servidor RIS, seleccionar as “Properties” do objecto.
2. Seleccionar o tab “Remote Install”. Agora aparecem as opções que permitem definir como o servidor RIS irá reagir aos pedidos das máquinas clientes.
fig. 10
Como é possível verificar, algumas destas opções já nos foram apresentadas durante a configuração inicial do RIS, tendo já sido descritas anteriormente:
“Respond to clients requesting service” – o RIS começa de imediato a aceitar pedidos de máquinas clientes, apresentando-lhes as opções de possíveis instalações de SO’s.
“Do not respond to unknown client computers” – caso a anterior seja seleccionada, permite filtrar as máquinas que tentam aceder ao servidor, atendendo apenas às já conhecidas. Só as máquinas constantes do Active Directory são consideradas.
“Verify Server” – inicia um processo de diagnóstico à integridade do servidor RIS, o que deve ser efectudo sempre que se apresentarem suspeitas sobre o seu estado.
“Show Clients” – mostra a lista das máquinas clientes actuais, permite fazer pesquisas de segundo vários critérios, como nome, domínio, etc. Para além das máquinas clientes permite também pesquisar impressoras, pastas, entre outros.
“Advanced Settings” – permite definir uma série de parâmetros relativos ao modo de configuração das máquinas clientes - ver destaque a vermelho na imagem anterior.
Esta última merece alguma atenção, pelo que a secção seguinte é dedicada a essa matéria.
fig. 11
Remote Installation Advanced Settings
Este é o ecrã inicial:
Tab “New Clients”
O administrador tem a possibilidade de definir alguns valores por defeito relativamente às configurações remotas das máquinas clientes. Uma política de atribuição automática de nomes pode ser estabelecida à priori, providenciando ao computador cliente um nome único na rede; isto é realizado através da opção “Client Computer Naming Format”, estando várias possiblidades disponíveis (ex: Username, MAC address, ...) para além de ser possível realizar uma personalização mais completa (botão “Customize...”) - ver destaque na imagem acima - com combinações de campos, como é possível ver abaixo:
fig. 12
Outra funcionalidade disponibilizada é a possibilidade de pré-definir um directory service container no Active Directory, onde todas as contas de instalações remotas de clientes são criadas. Estas podem ser organizadas de 3 modos:
• “Default directory service location” - atribui um objecto do tipo computer account na localização “Active Directory -- Computers”; a máquina cliente torna-se membro do mesmo domain que o servidor RIS
• “Same location as the user setting up the computer” - o objecto computer account relativo à maquina cliente é criado no mesmo container do utilizador no Active Directory
• “A specific directory service location” - a mais usual; o administrador cria um container para todos os computadores clientes (computer account objects) no Active Directory que utilizam o servidor RIS
fig. 13
Tab “Images”
Serve para realizar a gestão das imagens de sistemas operativos disponíveis nos servidores RIS, sendo possível acrescentar, apagar ou modificar as propriedades das imagens (as propriedades que podemos alterar são apenas os descritores das imagens). As imagens podem ser de 2 tipos:
Cd-based - é simplesmente uma cópia do CD do Windows 2000 Professional, sem aplicações ou personalização de configurações, tal como é realizado na instalação inicial do RIS (ver acima)
Remote Installation Preparation (RIPrep) - trata-se de uma possibilidade muito interessante, dado que é possível configurar uma máquina “a gosto”, não só relativamente a aspectos relacionados com o SO, mas também aplicações de software e em seguida criar uma imagem do sistema para armazenamento no servidor, para uso posterior em máquinas clientes. Assim que o administrador acaba de configurar uma máquina modelo, com as configurações e instalações de software desejadas, basta correr o utilitário RIPrep.exe para criar uma imagem no servidor RIS (mais explicações acerca deste processo serão dadas mais à frente no documento).
De notar que é necessária alguma cautela na gestão das imagens, para por exemplo não se apagar uma imagem que ainda está a ser utilizada por máquinas clientes.
Tab “Tools”
Permite que os fabricantes de software e hardware desenvolvam ferramentas de pre-boot para uso com o RIS. Para se adicionar uma nova ferramenta, é necessário que os fabricantes forneçam um programa de setup para colocação dos ficheiros em \RemoteInstall (a pasta onde se encontram os ficheiros do RIS). Após isso, a descrição da ferramenta irá constar na tab “Tools” e poderá ser utilizada.
Isto é interessante pois permite que sejam desenvolvidas ajudas para a administração, como criação de automatismos de manutenção, troubleshooting, actualizações de BIOS, entre outros.
Preparação para Máquinas Clientes com Remote Installation
A máquina cliente deve possuir, acima de todos os requisitos, uma remote boot ROM baseada na tecnologia PXE. Caso contrário, só será possível implementar o sistema se a placa de rede for uma das constantes na lista de placas suportadas pela RIS boot disk, a qual está referida no início deste capítulo.
Relativamente aos utilizadores, devem possuir as permissões necessárias para efectuar a instalação remota do sistema. Isto é o mesmo que dizer que têm de ter direito de “Logon as a Batch Job”, sendo na situação mais normal atribuído a todos os utilizadores (“Everyone”) inclusivé os próprios administradores. Uma outra alternativa será atribuir esse direito apenas a alguns utilizadores previamente seleccionados.
O processo para a atribuição destes direitos segue as seguintes etapas:
1. No utilitário “Active Directory Users and Computers” presente em “Administration Tools” carregar com o botão direito em “Domain Controllers”, seguidamente em “Properties” e “Group Policy”
2. Após seleccionar “Default Domain Controllers Local Policy”, fazer “Edit”, o que irá fazer aparecer uma nova janela - “Group Policy”
3. Dentro da pasta “Computer Configuration”, abrir “Windows Settings”, seguidamente “Security Settings”, “Local Policies” e por fim “User Rights Assignment”. Agora carregar com o botão direito em “Log on as a Batch Job” e escolher “Security”. Neste momento podemos finalmente seleccionar a conta “Everyone” e “Administrators”, ou então as contas que entendermos convenientes, e acrescentá-las à lista.
Nota Estas modificações não têm efeito imediato, podendo levar até algumas horas para serem consideradas pelo sistema. Para evitar esta situação, assim como um reboot (o qual também resolve o problema, mas pode não ser conveniente), basta executar o seguinte comando:
Secedit /refreshpolicy MACHINE_POLICY
para que as alterações às políticas sejam aplicadas imediatamente.
Torna-se também necessário atribuir permissões para que os utilizadores possam criar e gerir contas no domain a que pertencem. Mais uma vez, vamos ter de colocar essa informação no Active Directory.
Para tal:
1. Em “Active Directory Users and Computers”, localizar o container definido anteriormente para a criação das contas pelo serviço RIS. Por defeito, estas são criadas no container “Computers”
2. Carregar com o botão direito em “Domain Name” e seleccionar “Delegate Control”, o que irá fazer arrancar um wizard. Este irá perguntar quais os users que deverão possuir permissões, sendo normalmente “Everyone”; Escolher a opção “Join a Computer to the Domain” e finalizar, neste momento os clientes seleccionados já têm poderes para gerir as contas por si criadas - e só essas - dentro do seu container no Active Directory.
Início do Processo de Logon dos Clientes
Logo ao arranque da máquina, aparece uma indicação para carregar em F12 para iniciar o download do wizard de instalação do cliente. No caso de ser a primeira vez que o computador arranca em remote boot, esta fase é obrigatória, dado que o disco está em “branco”; caso contrário pode ser utilizada para carregar uma nova versão/imagem do sistema operativo.
Uma vez carregado o wizard, pode iniciar-se a instalação da imagem do Windows 2000 Professional. A primeira imagem é a de um ecrã de boas-vindas, o qual pode ser personalizado - com o logotipo da organização, por exemplo - podendo conter também algumas instruções sobre o processo de instalação que se seguirá ou alguma advertência aos utilizadores (ou qualquer outra informação que se considerar relevante).
Nesta etapa, o RIS permite ainda uma opção bastante interessante: a possibilidade de escolha da versão da língua do sistema operativo. Obviamente, isto terá de ser configurado previamente, através da edição de um ficheiro de texto (o RIS traz consigo um sample file para o efeito, chamado Multilng.osc) do sistema.
Como em qualquer outro sistema, é depois realizada a sua autenticação e autorização, através da introdução do seu username, password e domain. Se estas operações obtiverem sucesso, é efectuado o logon do utilizador e o RIS vai verificar quais as permissões que ele possui, consultando as Group Policies definidas anteriormente.
O wizard apresenta então as opções personalizadas disponíveis ao utilizador para a instalação do SO.
Opções de Instalação da Parte do Cliente
São 4 as opções de instalação da parte do cliente, cada qual com características adequadas a diferentes contas e grupos de utilizadores.
As opções são determinadas pela Group Policy do RIS em conjunto com as contas dos utilizadores e grupos a que pertencem. Deste modo é possível definir grupos com acesso a todas as opções (ex:pessoal da secção de informática) e outros com acesso mais restrito, (como poderá ser desejável para os utilizadores comuns) dado que simplifica o processo de instalação.
Em seguida são analisadas as várias opções:
1. Automatic Setup - O wizard salta imediatamente para o menu de escolha da imagem do SO, avançando a fase de escolha do tipo de opção de instalação. Por defeito, esta é a definida para os utilizadores; para facilitar o processo, o RIS permite a utilização de setup answer files (*.sif), as quais permitem a realização de uma instalação completa sem qualquer intervenção por parte do utilizador. Assim, o administrador pode disponibilizar várias versões da mesma imagem do SO, cada qual adaptada às necessidades de cada tipo de utilizador. Exemplo: uma instalação com display a 1280x1024 a 32 bits cor para pessoas do departamento de design, outra com display a 800x600 a 32 bits cor com funcionalidades para pessoas incapacitadas… Cada uma destas imagens deverá ser acompanhada por uma descrição clara, a qual pode também ser definida pelo administrador.
2. Custom Setup – O mesmo que a anterior, com a diferença de que permite que um administrador prepare uma máquina cliente para outra pessoa, sem haver problemas com o automatic naming definido no servidor RIS. Como o nome atribuído à máquina pode ser constituído pelo username e/ou outro campo qualquer (MAC address, IP, …), sendo baseado no logon efectuado na máquina, evita que a máquina fique com o nome do administrador. Logo, com a opção de instalação “Custom Setup”, o processo de atribuição de nome à máquina torna-se manual, assim como a localização no Active Directory onde serão armazenados os dados relativos à conta do computador em causa.
3. Restart a previous setup attempt – Se por algum motivo uma instalação for interrompida, basta fazer um reboot, carregar em F12 após o arranque e seleccionar esta opção para recuperar a instalação, não sendo necessário introduzir novamente os dados.
4. Maintenance and troubleshooting – Dá acesso a ferramentas disponibilizadas por fabricantes de software/hardware, para a realização de tarefas de manutenção, diagnóstico e resolução de problemas, entre outros. Neste momento existem pelo menos 2 disponíveis no mercado pela AMI (Pre OS AMIDIAG) e pela Phoenix Technologies (Preboot Agent v3.0).
Implementação de Restrições
Restrições nas Imagens do Sistema Operativo
O RIS permite que o administrador conceba o sistema de modo a que não seja necessária a intervenção do utilizador durante o processo de instalação, logo limitando as opções do utilizador.
Do mesmo modo, através da definição de permissões de contas ou grupos nos ficheiros do tipo unattended answer files (*.sif), os quais ficam associados a uma imagem do SO, é possível estipular que opções ficam disponíveis. Assim é possível escolher quais as imagens que o utilizador, ou grupo de utilizadores, pode visualizar e instalar.
Para restringir:
1. Na unidade de disco onde foi instalado o Remote Installation Service, ir ao path \RemoteInstall\Setup\OSLanguage\Images\OSImageName\Templates
2. Seleccionar as properties desta pasta e, para restringir acesso à imagem, seleccionar os grupos de utilizadores que se deseja privar da utilização da imagem (ou simplesmente “Everyone”) e seleccionar a opção Remove.
3. Em seguida, fazer Add dos utilizadores que deverão ter acesso à imagem em causa (ex: “Administrators”)
Restrições em Instalações de Clientes
Para restringir as opções de instalação dos clientes, é preciso definir as Group Policies pretendidas no servidor RIS. Para tal:
1. Localizar o container no Active Directory onde as policies do RIS estão definidas. Salvo alguma alteração, este estará dentro do objecto Default Domain Policy.Carregar com o botão direito no domain root name e em seguida em Properties
2. Seleccionar a tab “Group Policies”; Seleccionar o objecto Default Domain Policy e seguidamente em “Edit”
3. Seleccionar “User Configuration”, e, dentro da hierarquia deste, abrir a pasta “Windows Settings”; seleccionar a opção “Remote installation Services”
[pic]
fig. 14
4. Carregar no ícon “Choice Options”; agora é possível visualizar uma nova janela - “Choice Options Properties”. Como é possível verificar, é possível definir 3 diferentes tipos de políticas para cada tipo de instalação:
fig. 15
As políticas são as seguintes:
• “Allow” – os utilizadores podem utilizar esse tipo de instalação
• “Don’t Care” – transfere a definição da política para a hierarquia superior; por exemplo, a política definida no domain passa a ser a adoptada também para as opções de instalação.
• “Deny” – esse tipo de instalação é negado aos utilizadores
Outras Funcionalidades do RIS
Remote Installation Preparation Wizard
O Remote Installation Preparation Wizard (RIPrep.exe) é uma funcionalidade bastante poderosa do RIS, com bastante aplicação prática. Consiste basicamente na criação de uma máquina modelo para disseminação pela organização.
Isto é, após a configuração de uma workstation cliente com uma instalação do Windows 2000 Professional, através do processo de remote installation/remote boot, de instalar na máquina todo o software que se considerar útil, assim como definir personalizações do sistema (ex: definições proxy server no IE, desktop, background, …) é possível em seguida criar uma imagem dessa instalação para armazenamento no servidor RIS pretendido, para futura replicação para outras máquinas.
Assim podemos ter imagens prontas a ser instaladas, guardadas no servidor RIS, com uma imagem para uso da secção de contabilidade, outra para o gabinete de engenharia, outra imagem ainda para o gabinete de design, …
Uma outra grande vantagem desta aplicação é o facto de não ser necessária que as futuras máquinas destino da imagem modelo criada (as outras workstations) possuam o mesmo hardware que a máquina origem. A única condição é que têm de possuir o mesmo tipo de drivers na Hardware Abstraction Layer (HAL), ou seja, ambos têm de ser baseados na tecnologia ACPI (Advanced Configuration and Power Interface) ou então têm de ser os 2 não-baseados em ACPI. Durante o processo de instalação, a aplicação RIPrep utiliza a tecnologia Plug’n’Play para verificar as diferenças existentes entre o hardware.
Como é fácil de verificar, todos estes factores trazem consigo uma enorme poupança de tempo e conduzem a uma imensa redução na carga de gestão e administração do parque informático.
Em mais pormenor, o processo (o qual é bastante simples) consiste em:
1. Instalar o Windows 2000 Professional numa máquina cliente através do processo de RIS/Remote-Boot;
2. Instalar todo o software considerado importante e configurar o sistema com as definições pretendidas;
3. Testar a configuração final e verificar a funcionalidade do sistema;
4. Arrancar com a aplicação RIPrep. Esta encontra-se em \\NomedoServidorRIS\RemoteInstall\Admin\RIPrep.exe. Em seguida arranca um wizard para a colocação da imagem, o qual irá perguntar o nome do servidor RIS, a designação a dar à imagem e a descrição respectiva;
5. Após todos os dados terem sido introduzidos, toma início a replicação da imagem para o servidor. A partir desse momento, qualquer cliente remote boot da organização pode utilizar essa nova imagem para instalação local (desde que não sejam especificadas restrições).
Nota Após a imagem ter sido criada e replicada no servidor RIS, não pode mais ser modificada.
Como limitações deste sistema temos que a aplicação RIPrep só suporta a replicação de imagens que tenham sido criadas em máquinas com um disco de uma única partição, com o Windows 2000 Professional. Tanto o SO como o restante software têm de residir na unidade de disco C:.
Remote Installation Boot Floppy
Em computadores que não possuam uma placa de rede com DHCP remote boot ROM PXE, existe o recurso a uma boot floppy para efectuar o processo de remote boot. No entanto, isto só é possível com alguns modelos de placas de rede (ver lista de pré-requisitos acima).
Para utilizar esta aplicação, basta ir à pasta \RemoteInstall\admin no servidor RIS, onde se encontra o ficheiro RBFG.exe, executá-lo e seguir as instruções. Ao arrancar o utilitário, também é possível verificar quais as placas suportadas em “Adapter List”.
Conclusão
Este tipo de solução talvez seja mais adequado para organizações com um certo orçamento, dado que é mais dispendiosa, quer em termos de hardware, quer software.
No entanto parece ser estável e tem a vantagem de possuir por trás de si a assistência da Microsoft (o que pode ser bom ou mau, dependendo do ponto de vista), e o facto de ser uma solução pensada de raíz, em vez de ser uma adaptação de um sistema, traduzindo-se em maior fiabilidade e estabilidade.
Como principais desvantagens, podemos apontar: o custo elevado das licenças de software quer do S.O. (cerca de 34 cts por estação de trabalho, fora a licença do servidor, a preços de Agosto de 2000), quer das aplicações a utilizar, dado que não se consegirá arranjar tão facilmente ferramentas “free software“ como no caso do Linux, por exemplo. No entanto no caso de instituições de ensino, como as Universidades, conseguem-se preços mais reduzidos através de licenças especiais; a pouca facilidade no reaproveitamento de equipamento informático já existente, devido às exigências mais elevadas de hardware, o que poderá levar em alguns casos à necessidade de um orçamento mais alargado; o facto de as máquinas clientes terem de possuir uma unidade de disco local (esta “desvantagem” é um pouco discutível, dado que se trata de uma diferente abordagem, logo com diferentes características). O facto de obrigar ao recurso de um disco local pode encarecer o sistema, mas por outro lado este facto traz consigo um ganho em performance e a diminuição do tráfego em rede, o que não é de desprezar.
Por fim, uma das grandes limitações é que apenas máquinas relativamente recentes, dada a juventude da tecnologia PXE da Intel, poderão tirar proveito desta solução - mas isto não inclui todos os PCs - sendo necessário consultar as características técnicas dos computadores para sabermos se são compatíveis ou não. No entanto, esta é uma tecnologia em grande expansão e cada vez mais comum.
Como alternativa, existe suporte para máquinas sem esse tipo de tecnologia, desde que possuam uma placa de rede constante da lista descrita no início deste capítulo - em ”Placas de Rede suportadas pela RIS Boot Floppy” - que tal como a descrição indica, implica um arranque via disquete. Segundo dados disponibilizados pela Microsoft, apenas esses equipamentos são garantidos.
Por outro lado, apresenta aspectos bastante positivos: estabilidade; suporte e assistência por parte de uma companhia de software renomada e conceituada; versatilidade do parque informático, permitindo a coexistência do sistema RIS/Remote Boot do Windows 2000 com outros sistemas RB já existentes; e, acima de tudo, uma grande centralização na gestão e administração do parque informático, a qual aliada à facilidade de instalação e implementação do sistema, lhe confere algumas vantagens comparativamente a outras aproximações.
Esse é, aliás, um dos grandes problemas dos sistemas remote boot em geral - a grande personalização destes em relação ao parque informático - assim como os problemas e/ou complicações despoletadas por máquinas clientes com diferentes configurações de hardware. O Windows 2000 parece resolver, pelo menos em parte, este problema, ao permitir que diferentes máquinas de diferentes componentes/fabricantes façam parte do sistema de RIS/RB sem que para tal seja necessário um esforço adicional - não esquecendo no entanto que o hardware tem de preencher os requisitos da “lista”.
Para Saber Mais
Case Study - FEP
Capítulo
6
FEP - Faculdade de Economia do Porto
A necessidade de disponibilizar aos alunos meios informáticos actuais, oferecendo as últimas aplicações disponíveis no mercado, a par das dificuldades inerentes ao controlo de aplicações e ficheiros existentes em cada uma das máquinas, obrigou o serviço de informática da faculdade de economia a repensar a forma de configuração dos computadores pessoais. Assim foi estudada e implementada uma configuração de remote boot que tornou possível a gestão centralizada de todas as máquinas, aplicações, utilizadores e ficheiros da rede.
Necessidades
Actualizar as aplicações de produtividade pessoal, oferecendo todas as funcionalidades disponíveis, e permitir aos administradores da rede um controlo total das aplicações e dos ficheiros instalados.
Descrição da Solução Adoptada
Utilização de computadores pessoais sem disco e com placa de rede PCI Fast Ethernet preparada para iniciar remotamente o Windows 95. Configuração do servidor principal da rede com Windows NT 4.0 Server e serviço de Remote Boot, de forma a guardar nos seus discos todos os ficheiros referentes a cada um dos 62 PCs disponíveis no Serviço de Informática.
Criação no servidor de um esquema de pastas que permita o armazenamento independente de:
▪ Dados referentes à etapa de arranque de cada PC.
▪ Ficheiros do Windows 95 a serem carregados e executados durante a inicialização e funcionamento do Windows 95.
▪ Ficheiros das aplicações instaladas em cada um dos PCs.
▪ Pastas para cada utilizador, individuais e seguras, onde é guardado o perfil do utilizador e os seus ficheiros pessoais.
Desenvolvimento de mecanismos para facilitar:
▪ A migração dos dados já existentes no sistema antigo.
▪ A criação dos utilizadores e dos grupos.
▪ A criação das pastas dos utilizadores, atribuindo direitos e permissões individualizadas.
▪ A atribuição/remoção a cada utilizador/grupo de direitos para a execução de determinadas aplicações e implementação das configurações inerentes.
▪ A limpeza de ficheiros desnecessários que vão sendo criados no sistema.
A Faculdade de Economia da Universidade do Porto tem cerca de 2500 utilizadores do sistema informático, entre docentes, alunos e funcionários.
O Serviço de Informática é responsável pela manutenção de todos os sistemas informáticos da instituição, alguns dos quais se encontram nas salas do Centro de Informática e nas salas de aulas, onde existem no total 62 computadores pessoais. Estes computadores são destinados aos alunos, que neles trabalham durante as aulas de Informática, e onde elaboram os seus trabalhos durante o restante tempo.
Foi, como tal, necessária a disponibilidade de aplicações de produtividade pessoal (Microsoft Office 97), ferramentas de prevenção e uso geral (McAfee VirusScan 3.1.0, WinZip 6.2 e Adobe Acrobat Reader 3.0), aplicações para acesso à Internet e leitura de email (Netscape Navigator 3.0 Gold e Eudora Light 1.5.2) e aplicações específicas (The SAS System 6.12, Econometric Views 2.0, RATS for Windows 4.20, Primavera Contabilidade 1.50 e diversas bases de dados de informações).
Nota O sistema entrou em funcionamento em 1997
Os Resultados
Segundo o responsável pelo Serviço de Informática da Faculdade de Economia do Porto, “Um dos aspectos essenciais é permitir aos alunos o acesso a estas aplicações num período de tempo normal, sem que haja atrasos devido ao facto de estarem a carregar tudo pela rede, a partir do servidor.”, o que levou à adopção de placas de rede 3Com Etherlink XL, que seguem as especificações PCI e Fast Ethernet e garantem performance superior.
Os resultados em termos de desempenho foram bastante satisfatórios, garantindo tempos de resposta, mesmo com todas as máquinas ligadas, similares aos de instalações locais. O tempo total de arranque de um máquina remote boot é de cerca de 52 seg, desde o POST (Power-On Self Test) até o sistema estar completamente operacional.
De forma a salvaguardar todas as configurações das máquinas e das aplicações foi implementada uma política de segurança que “esconde” todos os recursos da rede, inclusive os que estão a ser utilizados pelo sistema, “mostrando” ao utilizador apenas as drives “a:”, “u:” e “l:”, que identificam respectivamente a unidade de disquetes, a home do utilizador e a pasta pública no servidor.
Para apoiar a criação e gestão dos utilizadores, assim como das aplicações instaladas, foi desenvolvida uma aplicação que permite, a partir de um ficheiro de texto ou das contas que já estão no sistema, a inclusão de utilizadores em grupos e a atribuição (ou remoção), a esses grupos ou a utilizadores individuais, das permissões necessárias para executarem as aplicações que forem indicadas, assim como a instalação e gestão das próprias aplicações que vão sendo necessárias.
Como resultado obteve-se um sistema seguro – com um downtime muito perto do zero -, actual, estável e com uma gestão totalmente centralizada.
Os Componentes do Sistema Remote Boot da FEP
Todos os PCs clientes remote boot são idênticos, com as seguintes características:
▪ Processador Intel Pentium a 166Mhz
▪ 16MB memória RAM
▪ Diskless
▪ Drive disquetes 3½
▪ Monitor 15’’ digital
▪ Placa de rede 3COM Fast Etherlink XL c/ boot ROM BootWare da Lanworks Technologies
Características do servidor remote boot (PITON):
▪ Dual pentium pro 200Mhz
▪ 128MB memória RAM
▪ Disco - 3 unidades lógicas em configuração RAID 2:
❑ sistema – 2GB
❑ shares remote boot – 8GB
❑ àreas dos utilizadores – 58GB
Características da rede:
▪ Ethernet 100Mbps
▪ FDDI ring na ligação entre servidores/switches
fig. 16
Produtos Utilizados
- Microsoft Windows NT Server
- Microsoft Exchange Server 5.0
- Microsoft Windows 95
- Microsoft Access
- Microsoft Word
- Microsoft Excel
- Microsoft PowerPoint
- McAfee VirusScan
- McAfee Netshield
- Netscape Navigator
- WinZip
- The SAS System
- Econometric Views
- Eudora Light
- RATS
- Primavera Contabilidade
- Adobe Acrobat Reader
- SPSS
O Remote Boot
No Windows NT 4.0, assim como no 3.51, o serviço de Remote Boot suporta workstations MS-DOS, Windows 3.1 e Windows 95 como clientes. No entanto não suporta clientes Windows 3.11 for Workgroups, Windows NT Workstation ou OS/2.
Os “Remote Boot Services” funcionam providenciando 2 recursos ao servidor:
1. um boot block, o qual contêm toda a informação necessária para iniciar o cliente ao arranque (boot).
2. O perfil de Remote Boot, o qual define o ambiente do sistema operativo após o arranque
No ambiente Windows NT Server 4.0 com clientes Remote Boot Windows 95, a sequência de boot é a seguinte:
1. Quando um cliente remote boot é ligado, a placa de rede inicia e envia um broadcast contendo uma frame FIND, a qual possui o ID da placa cliente (MAC address);
2. O Remote Boot Service recebe a frame FIND e verifica se existe alguma placa na sua base de dados com aquele ID;
3. Se não existir, mas o prefixo da placa de rede é reconhecido pelo Remote Boot Service, este serviço regista-o mas não efectua o boot. Para se realizar o boot do cliente, é necessário transformar este ID da placa num registo de workstation através do “Remote Boot Manager” presente nas “Administrative Tools” do NT Server. Se o ID já existir na base de dados, o Remote Boot Service devolve um frame do tipo FOUND contendo o ID da placa de rede do servidor para a ROM BootWare no cliente;
4. O BootWare do cliente aceita a primeira frame FOUND que recebe, em seguida envia a frame SEND FILE REQUEST para o ID da placa de rede do servidor que lhe enviou a frame;
5. Quando o Remote Boot Service recebe a frame SEND FILE REQUEST, serve-se de frames FILE DATA RESPONSE para enviar o bootstrap program em blocos para o BootWare cliente. O registo respeitante à workstation na base de dados de Remote Boot especifica qual o tipo de bloco a enviar (MS-DOS, Windows 3.1 ou Windows 95). Após o início da transmissão, o cliente irá incrementar um número no ecrã por cada bloco recebido. Quando o BootWare do cliente recebe o último FILE DATA RESPONSE, limpa o ecrã e transfere a execução para o entry point do bootstrap program;
6. O BootWare faz o boot do sistema operativo especificado no bootstrap program; se se tratasse de um cliente MS-DOS ou Windows 3.1, este seria o final do processo básico de boot;
7. Como se trata de um cliente Windows 95, o processo continua. Neste momento o cliente está a correr o Windows 95 em real mode, utilizando os ficheiros no servidor de remote boot. Para concluir o boot do Windows 95, o cliente:
a. cria um RAMdrive - se a workstation possuisse disco poderia utilizá-lo, mas não é esse o caso
b. copia os ficheiros do SO real mode do servidor para a RAMdrive
c. carrega os drivers de rede do Windows 95 e estabelece uma ligação com o servidor (PITON), o qual possui uma pasta específica por máquina cliente, com os ficheiros de sistema necessários
Parte Cliente - Boot ROMs
Foram adquiridas placas de rede 3COM Etherlink XL 3C905-TX, versão PCI, às quais foram acrescentadas boot ROMs do tipo Flash ROM com o software Bootware da LanWorks Technologies para permitir o arranque remoto do sistema operativo.
As boot ROMs das placas foram programadas para realizarem o remote boot não em TCP/IP, mas sim com o protocolo “Remote Program Load” (RPL). Isto porque o serviço de Remote Boot do NT 4.0 assim o exige, assim como o suporte a NetBEUI. A comunicação com o servidor é em seguida realizada sobre NetBEUI, o que conduz a que mesmo que o servidor de DHCP esteja em baixo, as máquinas clientes RB consigam arrancar com o Windows 95, sofrendo apenas a restrição óbvia de não poderem aceder à Internet. Do mesmo modo, foram programadas para que o default boot device fosse Network.
Para a programação do chip, foi utilizado o utilitário DOS “BootWare EtherLink PCI Configuration Utility” - BWUPDATE.EXE - fornecido com o chip da LanWorks, o qual está preparado para as placas de rede do tipo 3C59X/3C90X da 3COM, as quais equipam todos os clientes RB da FEP.
A seguir podemos ver a comunicação efectuada pelas máquinas do ponto de vista do Bootware (o mecanismo de RB), no início do processo de remote boot:
fig. 17
[pic]
Parte Servidor - A Organização no PITON
O Servidor de remote boot está dividido em 3 unidades lógicas em RAID, seguindo a seguinte estrutura lógica:
1. Sistema – 2GB (C:)
A Base de dados de Remote Boot utilizada pelo Windows NT Server está contida em 2 ficheiros, SYSTEM.MDB e RPLSVC.MDB, localizados no directório \\systemroot\RPL.
O acesso à base de dados é possível através do utilitário “RPLCMD.EXE”, executado na linha de comandos, ou então pelo mais amigável “Remote Boot Manager” do NT Server.
A criação ou modificação de boot blocks (ou bootstrap programs pode ser tornada mais simples através de script files (*.RPL), os quais redireccionam para o utilitário RPLCMD.EXE na linha de comandos. Deste modo é possível definir qual o bootstrap program a utilizar, o directório onde se encontram os ficheiros de configuração das máquinas clientes, entre outras configurações.
2. Shares remote boot – 8GB (D:)
Cada máquina cliente remote boot possui a sua pasta no servidor, apresentando a seguinte estrutura
fig. 18
[pic]
Nas pastas RB## estão colocados os ficheiros:
▪ de sistema do Windows 95, basicamente o directório /WINDOWS encontrado nas instalações normais do Win95;
▪ de inicialização e configuração (incluindo o WIN.INI e o SYSTEM.INI), do Registry (SYSTEM.DAT); este último possui a parte do Registry com os dados sobre os programas instalados além de dados vários sobre o sistema
▪ O directório de Spool para impressão
▪ ficheiros temporários e swap
3. Àreas dos utilizadores – 58GB (E:)
fig. 19
[pic]
Nesta unidade estão armazenadas as áreas pessoais dos utilizadores, assim como o ficheiro USER.DAT - trata-se da parte complementar do Registry respeitante às personalizações dos utilizadores (desktop, cores de background, ...)
No PITON está instalado o componente “Remote Boot Services” do Windows NT Server 4.0, o qual permite realizar a parte da implementação da solução Remote Boot do lado do servidor. Abaixo é possível ver o aspecto deste gestor de serviços remote boot:
[pic]
fig. 20
O sistema remote boot é de mais fácil implementação se todas as máquinas clientes possuirem hardware semelhante, mas no caso contrário é possível a existência de imagens separadas para diferentes tipos de máquinas, as quais são associadas a grupos de máquinas identificadas pelos seus MAC addresses.
A Implementação
Para oferecer o serviço de Remote Boot aos clientes Windows 95, foi necessário proceder às seguintes etapas, pela ordem descrita:
▪ Instalar o Server-Based Setup (SBS) no servidor
▪ Instalar uma máquina “protótipo” Windows 95 (1º cliente) no Servidor
▪ Instalar os restantes clientes
▪ o servidor DHCP já se encontrava instalado
1. Instalação do server SBS
1. Na máquina que será o servidor de SBS, é necessário criar um directório shared com pelo menos 90MB de espaço livre, podendo possuir qualquer nome. Em seguida atribuir permissões read-only para os utilizadores e full access para os administradores.
2. Instalar um cliente Windows 95 na rede, o qual será usado para configurar o servidor SBS.
3. Nessa máquina cliente, inserir o CD-ROM do Windows 95 e ir até ao directório \ADMIN\NETTOOLS\NETSETUP; arrancar com NETSETUP.EXE
4. Na janela do Server-Based Setup, definir o path para o servidor SBS. Ex: \\PITON\DIRSHARES\RPL\WIN95; em seguida fazer Change Path e carregar em Install.
5. Agora aparece uma série de janelas para completar as seguintes acções:
1. Definir uma install policy, a qual serve para especificar como os utilizadores podem instalar o Win95 a partir do servidor; como se trata de um sistema de Remote Boot, escolher a opção Server.
2. Definir a path fonte para os ficheiros do Win95 (neste caso, o CD no cliente).
3. Inserir o CD Key. O Server-Based Setup copia os ficheiros do Win95 para o directório shared do servidor SBS.
4. No servidor de Remote Boot, colocar o CD ou disquete com o ficheiros do “Windows NT Remote Boot for Windows 95” na drive correspondente. Nessa drive, ir para o directório \UPDATE\WIN95 e correr o ficheiro “WIN95SRV.BAT” para actualizar os ficheiros do Win95 para remote boot. Exemplo:
d:\
cd \update\win95
win95srv.bat dest
(dest é o directório shared no servidor SBS)
2. Instalação do Primeiro Cliente Win95 “Protótipo” no Servidor
Para realizar a instalação do Windows 95 no primeiro cliente é preciso realizar o boot em MS-DOS 6.2x, correr o Windows Setup no cliente, e finalmente copiar os ficheiros para o directório da máquina cliente no servidor Remote Boot.
Após a instalação do primeiro cliente, para instalar os restantes basta que se utilize o SBS para criar uma cópia modificada do directório da máquina “protótipo”, sem necessidade de correr novamente o Windows Setup.
No entanto, é necessário que o primeiro - e só o primeiro - utilize uma placa de rede ISA para o arranque remoto, assim como um slot PCI livre para posterior instalação de uma placa de rede PCI (a definitiva).
Como já foi dito, cada máquina cliente possui um directório no servidor RB, o qual contém as suas configurações específicas e outros dados. Mais concretamente, e a título de exemplo, estão lá os ficheiros:
▪ De inicialização e configuração (incluindo o WIN.INI e o SYSTEM.INI), do Registry (SYSTEM.DAT)
▪ O directório de Spool para impressão
▪ O Swap file, directório TEMP
Para estabelecer uma pasta para os directórios das máquinas RB, é suficiente criar uma pasta shared num servidor e atribuir permissões de leitura/escrita apenas para o utilizadores que irão usufruir da máquina, assim como para os administradores.
Nota A Localização física dos directórios das máquinas clientes RB pode ser no servidor SBS, no próprio servidor Remote Boot ou em qualquer outro servidor da rede (no caso da FEP, existe um único servidor para todos estes serviços - o PITON). Desse modo, é possível obter uma distribuição da carga por várias máquinas, desde que estas possuam suficiente espaço em disco e tenham a correr o protocolo NetBEUI. A única condição é que esses directórios não podem ser subdirectórios da pasta SBS no servidor SBS.
3. A Instalação da Máquina Cliente
1. Arrancar o novo cliente em MS-DOS 6.2x
2. Utilizar o comando net logon para realizar o logon no servidor SBS (com uma conta que possua permissões para leitura no servidor e de escrita para o directório da máquina cliente RB, onde ficarão os ficheiros do Win95 desta máquina);
3. Sincronizar a data e hora do cliente com o(s) servidor(es).
4. Utilizar o comando net use para mapear drives para o servidor SBS e para a localização do directório da máquina no servidor. A drive C: será um disco virtual mapeado para o servidor de Remote Boot (parte deste); caso existisse disco local tomaria a designação D: E: … consoante o número de partições existentes; Uma outra letra é reservada para a RAMdrive durante o processo de boot; As restantes ficam disponíveis para o uso que convier. Um uso possível seria:
net use f:\\servidorSBS\win95_share
net use g:\\serv_areas_maquinas\dir_maquina
5. Em seguida, ir para a drive mapeada para o servidor SBS e correr o Setup do Windows 95 do seguinte modo:
setup /t:path_temporario
sendo que path_temporario é um path para colocação de ficheiros temporários durante a instalação. Deste modo, pode-se fazer algo do género:
setup /t:g:\rb01.tmp
considerando que G: é a drive que mapeia o directório shared da máquina cliente no servidor RB, podemos assim armazenar ficheiros temporários.
Nota Não apagar este directório até a conclusão da instalação.
6. O Setup inicia e apresentam-se algumas decisões:
1. Escolher “Set Up Windows to run from a network server” no Server-Based Setup, caso seja perguntado.
2. Na próxima janela, “Startup Method”, escolher “Start Windows from the network (remote boot server)”
3. Em “Machine Directory”, ao perguntar onde instalar o Windows 95, indicar o path para o directório shared (remoto) da máquina em questão. Ex: g:\rb01.
4. Em “Setup Options” escolher Custom
5. Em “Analyzing Your Computer”, escolher “No, I want to modify the hardware list” e, em seguida, excluir o máximo possível de hardware e tipos de hardware. Se a autodetecção sofrer um crash, repetir o processo de setup e excluir mais items da autodetecção (um facto que poderá fazer surgir alguns problemas é se a placa de rede estiver configurada para o IRQ 2 ou 3, o que por vezes cria conflitos com a detecção das portas série).
6. Em “Select Components”, não seleccionar a opção Communications.
7. Em “Network Configuration”, verificar que a placa de rede está presente e possui todos os protocolos de rede necessários (TCP/IP, NetBEUI), caso contrário acrescentar. Verificar também que o workgroup do cliente é o mesmo do servidor SBS e do servidor com as àreas Remote Boot dos clientes.
7. Concluída a configuração do Windows 95, fazer reboot ao cliente (este não vai já arrancar com o Windows 95, falta ainda concluir mais alguns passos na instalação).
8. No servidor Remote Boot, arrancar com o “Remote Boot Manager”, presente nas “Administration Tools”. Criar um profile para o cliente Win95; Em “Configuration”, escolher a configuração Windows 95 correspondente à da placa de rede do cliente.
9. Editar o registo da workstation cliente para atribuir o profile Win95 respectivo.
1. Ainda no servidor Remote Boot, correr o batch file RPL\BIN\WIN95CLT.BAT do modo seguinte:
cd systemroot\rpl\bin
win95clt.bat dir_maquina \\servidorRB nomeprofile
onde
dir_maquina é o path para o directório da máquina cliente,
servidorRB é o servidor de Remote Boot / RPL e
nomeprofile é o nome do profile Win95 associado ao cliente
exemplo:
cd winnt\rpl\bin
win95clt.bat \\piton\rb\rb01 \\piton win95profile
Este batch file (WIN95CLT.BAT) copia ficheiros de boot Windows 95 específicos de cada cliente do directório da máquina cliente para o directório RPL\RPLFILES\PROFILES\nomeprofile no servidor Remote Boot
2. No servidor SBS, editar o ficheiro MACHINES.INI no directório SBS, acrescentando as seguintes linhas:
[ID placa de rede]
SYSDATPATH = g:\dir_maquina_shared
g = \\serv_areas_maquinas\dir_maquina
ID placa rede é o ID da placa de rede, especificado no registo remote boot da workstation, para o cliente em causa;
\dir_maquina é a localização do directório da máquina cliente no servidor das àreas;
\\serv_areas_maquinas\dir_maquina_shared representa a letra do drive atribuído ao directório dir_maquina
Exemplo:
[02608C8EAA2D]
SYSDATPATH = g:\rb01
g = \\piton\rbs
3. Fazer reboot ao cliente Windows 95. Finalmente, a máquina cliente irá realizar o boot e completar o setup do Windows 95.
4. O Logon da Máquina Cliente
Ao realizar o boot, a máquina cliente pede 2 vezes um remote boot logon, pedindo um username e respectiva password. O primeiro é pedido ainda no modo DOS, de modo a permitir que se aceda ao servidor de Remote Boot, e o segundo é pedido numa dialog box do Windows, como usual para o acesso em rede.
Assim que o Windows 95 termina de arrancar, o drive C: não se encontra atribuído, embora tenha sido utilzado durante o processo de remote boot. Na FEP, encontram-se atribuídos os seguintes drives:
▪ A: drive disquetes 3½
▪ L: pasta Public (servidor SPIDER)
▪ U: àreas dos users (PITON)
▪ V: programs (PITON)
Nota Até este momento, o remote boot é realizado utilizando apenas a placa de rede ISA. Os procedimentos necessários para o RB com placas PCI encontram-se descritos no passo 5.
5. A Instalação de Clientes Windows 95 com Placas de Rede PCI
Na implementação do sistema remote boot na FEP, foi necessário um certo jogo de cintura. O Serviço de Informática pretendia utilizar placas de rede 3COM PCI, e segundo a Microsoft e a própria 3COM, não é possível implementar um sistema Remote Boot em NT Server com este tipo de placas - supostamente só seria praticável com placas ISA - devido à falta de suporte do NT Server 4.0.
O “truque” para tornar possível o Remote Boot em Windows 95, utilizando placas de rede PCI, é realizar um update ao Registry das máquinas clientes com informação acerca das placas PCI antes de se realizar o Remote Boot.
Para realizar o update ao Registry a maneira mais fácil é deixar que o Windows o faça - vantagem de ser um sistema operativo plug’n’play -, quando um novo device é detectado, o Registry é automaticamente actualizado com a nova informação com informação sobre o hardware.
O Windows 95 só inicializa devices PCI no segundo boot do sistema, no entanto ao realizar o remote boot do Win95, a placa tem de estar inicializada já no primeiro boot.
Isto obrigou o recurso a métodos menos ortodoxos, os quais se encontram descritos em seguida:
a) Verificar a possibilidade de implementação do sistema RB com um cliente possuindo uma placa de rede ISA (aproximação “oficial”) - os passos 1 a 4 descritos anteriormente - Foi testado e funcionou.
b) Para confirmar se realmente não seria possível, foi realizada a implentação do sistema RB com um cliente possuindo uma placa de rede PCI (aproximação “não-oficial”). Foi testado e não funcionou.
c) Instalação na mesma máquina cliente RB uma placa de rede ISA e uma placa de rede PCI sem a boot ROM. A placa ISA respondeu e efectuou o boot remoto do SO com sucesso. O Windows detectou a placa PCI e instalou o device driver correspondente. Foi realizado um reboot à máquina e verificaram-se todas as configurações de rede relativas à placa de rede PCI.
d) Colocar o CD do Win95 no leitor da máquina cliente e correr o utilitário \ADMIN\NETTOOLS\NETSETUP\NETSETUP.EXE.
▪ Na janela do Server-Based Setup, definir o path para o servidor SBS. Ex: \\PITON\DIRSHARES\RPL\WIN95; em seguida fazer Change Path.
▪ Clicar em Add. Em “Set Up Machine”, escolher “Set Up One Machine” e escrever:
o Computer name: nome do cliente (identificador único), ex: RB02
o Path to machine directory: \\PITON\RB\RB02
o Existing machine directory: \\PITON\RB\RB01
o e carregar em OK.
e) Copiar o conteúdo do directório RB01 para RB02. Copiar também o driver NDIS para este directório.
f) De seguida, é necessário editar os seguintes ficheiros:
❑ MSDOS.SYS
❑ PROTOCOL.INI
❑ SYSTEM.DAT
▪ Ir para o subdirectório da máquina cliente no servidor.
▪ Fazer o update ao PROTOCOL.INI, introduzindo as informações relativas ao driver e removendo qualquer configuração relativa a IRQs e IOs.
▪ Fazer o update ao MSDOS.SYS, introduzindo o novo path para o directório da máquina cliente (ex:RB02) no campo WinDir.
▪ Editar o SYSTEM.DAT; visto que se trata de um ficheiro binário, é preciso realizar os seguintes procedimentos:
regedit /L:system.dat /E registry.txt
edit registry.txt
Nota O utilitário REGEDIT deve ser corrido no modo DOS, e não numa sessão de DOS debaixo de Windows 95.
▪ Editar o REGISTRY.TXT, substituindo todas as ocorrências do antigo path do directório da maquina cliente para o actual. Mudar também o driver NDIS para o novo driver NDIS, utilizado pela placa de rede PCI.
Para actualizar as mudanças ao SYSTEM.DAT, fazer:
regedit /L:system.dat /C registry.dat
▪ Remover os atributos hidden, system e read-only do ficheiro SYSTEM.DAT.
g) Na máquina cliente, retirou-se a placa de rede ISA, mantendo-se apenas a placa de rede PCI, desta vez já com a boot ROM. O remote boot funcionou com sucesso!
Visto todas as máquinas clientes possuirem hardware semelhante, bastou replicar o directório para todas as outras máquinas clientes Remote Boot, utilizando-se para o efeito um ficheiro batch que mudava automaticamente todas as ocorrências do nome do directório (RB02,RB03,...RB##) - pois este é agora o único dado que os distingue - sem a necessidade de se instalar previamente uma placa ISA.
A partir daqui, as instalações ocorreram sem problemas, tendo sido efectuado o remote boot com sucesso em todos os 62 clientes.
A Manutenção do Sistema de Remote Boot
O sistema não exige uma manutenção pesada, esta limita-se quase ao processo de limpeza de ficheiros temporários dos directórios das máquinas RB no servidor. Para o efeito existe um batch file (CLEANRBS.BAT), o qual varre os directórios RB## e apaga o “lixo” deixado pelo sistema, de modo a optimizar os recursos de armazenamento do servidor.
Pontos Fortes do Sistema de Remote Boot da FEP
Como é possível verificar, o processo de implementação do sistema é bastante trabalhoso e demorado. No entanto, após a instalação, verificou-se ser bastante estável e fiável. No período de funcionamento, que conta já com 3 anos, surgiram apenas 3 problemas, nenhum deles relacionado com o RB:
▪ Um cabo do sistema RAID que se desligou por não se encontrar aparafusado
▪ Um double-click num ficheiro de configuração do Registry durante uma operação de rotina no servidor, que modificou do Registry do servidor, o qual foi recuperado através de Backups. De relevar que ao executar o ficheiro inadvertidamente, o sistema operativo não pede nenhum tipo de confirmação, pelo que fica o aviso à navegação.
▪ O controlador do sistema RAID avariou, levando consigo os 2 discos de sistema – original e replicação – forçando a um Restore.
No entanto não se observou nenhum problema relacionado com o sistema remote boot, desde a sua instalação inicial.
Pontos Fracos do Sistema Remote Boot da FEP
O principal inconveniente deste sistema está na instalação de novas aplicações, pois trata-se de um processo muito trabalhoso e exigente. Não é possível simplesmente correr o programa de setup no servidor e torná-lo disponível para os clientes, dada a arquitectura do sistema.
Assim sendo, para instalar um novo programa para uso das máquinas remote boot, é necessário:
1. Instalar o software numa workstation seguindo os passos normais da instalação
2. Concluído este passo, copiam-se a imagem do novo programa para o servidor, para a imagem da máquina RB, no drive de shares remote boot do PITON; será necessário depois replicar esta imagem para todas as máquinas (cada máquina possui uma pasta no servidor - ver esquema abaixo). Simultaneamente, é realizado um registo de todas as alterações ao Registry efectuadas pela nova instalação, utilizando-se para o efeito um aplicação que efectua um rastreio das modificações.
3. Esta é a parte problemática do processo. As alterações são replicadas para todas as máquinas RB, nas suas pastas representativas no PITON, com o cuidado de se verificar dependências do novo programa - tais como letras de drives -, o que torna o processo trabalhoso e sujeito a problemas. Isto faz com que a instalação fique dependente dos requisitos e características de cada programa; surgiram alguns casos em que simplesmente não foi possível a instalação - como com o Internet Explorer, segundo a própria Microsoft, a instalação em remote boot do IE é impraticável, como se comprovou.
Verifica-se também uma certa saturação da rede, em situações de grande afluência nas salas dos alunos, devido ao facto de o Windows 95 utilizar o servidor como se se tratasse de um disco local (para swap file, …). Isto leva a que se verifiquem alguns picos de saturação na rede local – estamos a falar de 62 clientes para um servidor – cenário que é atenuado pelo facto de se tratar de uma rede a 100Mbps.
Isto acontece pois apesar de todas as máquinas clientes têm ligação ao servidor a 100Mbps, como já foi referido, depois verifica-se um bottleneck em situações de maior tráfego na comunicação switch-servidor RB, a qual também se realiza a 100Mbps.
Numa situação mais próxima da ideal, esta deveria realizar-se numa ordem de grandeza maior, ou seja, a largura de banda da interface entre o switch e o servidor deveria ser aumentada dos actuais 100Mbps para 200, 300Mbps - através da adição de novas interfaces de rede no switch e no servidor - ou mesmo para 1Gigabps, o que obrigaria a um novo tipo de interface - como as do tipo FDDI.
No entanto, mesmo nas situações de grande utilização, o desempenho é muito aceitável.
A rede remote boot da FEP entrou em funcionamento apenas a 10Mbps, configuração com a qual se sentia uma quebra significativa na performance, tendo então sido realizado o upgrade para 100Mpbs - da parte do equipamento activo de rede, já que as placas 3COM usadas eram já 10/100Mbps - trazendo consigo uma maior fluidez e desempenho substancial da rede remote boot.
O Sistema Informático da FEP no Futuro
Está prevista a passagem actual sistema informático da FEP com Windows NT Server 4.0 para Windows 2000 Advanced Server, encontrando-se já em fase inicial de testes.
| |NetBoot |EtherBoot |BpBatch (PXE) |Bootware(*) |
|Plataformas |Desde Intel 8088, mas optimizado para|Desde Intel 8088, mas optimizado para|Intel Pentium e superior |Desde Intel 8088 |
|(só Intel ou equivalente) |386 e superior |386 e superior |(PXE-compliant) | |
|Principais SO’s suportados - clientes|Linux, MS-DOS, Win95 |Linux, MS-DOS, Win95 |Linux, MS-DOS, Win95 |Linux, Win95, MS-DOS |
|SO’s suportados - servidor(es) |Linux, Windows NT |Linux, Windows NT |Linux, Windows NT |Linux, Windows NT |
|Suporte placas rede |ISA, PCI, packet drivers |ISA, PCI, built-in drivers |PCI |ISA, PCI, EISA |
| | | | |(específico para modelo ou família de|
| | | | |modelos) |
|Principais protocolos utilizados |BOOTP, TFTP, TCP/IP |BOOTP, TFTP, |DHCP, TFTP, TCP/IP |RPL e NetBEUI |
| | |TCP/IP | |(tb. possível com TCP/IP) |
|Licença |Grátis (GPL) |Grátis (GPL) |Comercial - Grátis só para uso |Comercial |
| | | |pessoal | |
|Tipo RB |tipicamente diskless |tipicamente diskless |tipicamente disk-based |disk-based / diskless |
Capítulo
7
Tecnologias Complementares
Contexto
Nesta secção são descritas algumas tecnologias, que apesar de poderem não estar directamente ligadas a sistemas Remote Boot, podem auxiliar ou melhorar a qualidade dos serviços por estes prestados. Inserem-se portanto num contexto mais alargado, o da gestão e da optimização do desempenho de sistemas informáticos, no qual se incluem também obviamente os mecanismos de Remote Boot.
Intel Rapid BIOS Boot
Trata-se de uma optimização da BIOS da máquina, a qual diminui significativamente o tempo de espera pelo boot do PC - redução no tempo de pre-boot até 80%!. Isto é conseguido através da paralelização de tarefas, eliminação de código redundante, redução de informação herdada por BIOS mais antigas e por uma optimização no uso do hardware, assim como um cuidado acrescido na sua configuração de modo a obter os melhores resultados.
Tudo isto sem se cortar em qualidade e fiabilidade, assim como nas características da máquina. Esta tecnologia apresenta vantagens óbvias para uma rede Remote Boot (e não só) ao cortar uma fatia do tempo de espera pelo arranque da máquina - e poupar a paciência do utilizador.
Para um arranque do SO mais rápido:
▪ BIOS é optimizada através da tecnologia Rapid BIOS Boot
▪ Configuração de hardware
o optimização dos tempos de spin-up dos discos e CD-ROM
o inicialização e sincronização da placa gráfica e monitor
o ordem de boot - Disco, CD-ROM em vez de termos Floppy, Disco, CD-ROM
Windows Terminal Server (WTS)
Permite o suporte multi-user num único servidor baseado em tecnologia NT, providenciando suporte para que vários utilizadores realizem logon no servidor e possam correr aplicações remotamente.
A arquitectura define que as aplicações correm no Windows Terminal Server, e apenas as operações gráficas são transmitidas ao WBT (Windows Based Terminal).
Esta solução permite a sua implementação num sistema Remote Boot, em que a máquina cliente RB funciona apenas como um terminal - após ligar a máquina é estabelecida ligação com o servidor e aparece uma janela de login - ou simplesmente como uma aplicação a correr numa janela de uma máquina cliente ligada à rede, após o arranque de um SO (O windows 98, por exemplo).
É o correspondente Windows ao X-Windows (solução X-terminal) das plataformas Unix.
A Microsoft disponibiliza 2 sistemas operativos com suporte para serviço de terminais: O Windows NT 4.0 Terminal Server e o Windows 2000 Server e Advanced Server
Windows Terminal Server para o Windows NT 4.0
Esta versão é baseada no código fonte do Windows NT 4.0, foi desenvolvida pela Citrix Corporation, a qual comprou os direitos do código fonte para o efeito. Consequentemente, a Microsoft comprou os direitos pelas modificações introduzidas pela Citrix e lançou uma versão baseada nessa - o Windows NT 4.0 Terminal Server Edition.
Como este é baseado no código da Citrix, os SOs Windows NT 4.0 Server e Windows NT 4.0 Terminal Server Edition possuem um código fonte base diferente (embora sejam praticamente iguais) e são 2 produtos distintos - isto implica, por exemplo, que os service packs de um não sirvam para o outro e vice-versa.
O WTS é baseado em 4 pontos:
o Terminal Server - um kernel com suporte para multi-user com capacidade de servir de host para várias sessões simultâneas de diferentes utilizadores
o Remote Desktop Protocol (RDP) - o protocolo que permite a comunicação entre o Terminal Server e os clientes, transportando dados do teclado e rato do cliente para o servidor e rotinas gráficas no sentido inverso (a representação da interacção)
o Thin Client - a máquina cliente, a qual não necessita de muitos recursos, podendo correr outros SOs
o Administration Tools - para além das administrative tools já presentes no Windows NT Server, são adicionadas: Terminal Server (TS) License Manager, TS Client Creator, TS Client Connection Configuration e TS Administration Tools para a gestão das sessões dos clientes. São também adicionados 2 novos objectos, “Session” e “User”, ao Performance Monitor para uma melhor avaliação da carga do servidor
Windows 2000 Terminal Server
Com o seu sistema operativo mais recente, a Microsoft disponibiliza de raíz o serviço de terminais, integrando-o completamente no Windows 2000 - tanto na versão Windows 2000 Server como na versão Windows 2000 Advanced Server.
Basta instalar o serviço “Terminal Server” e o SO torna-se um Terminal Server. Os clientes suportados são:
o Windows 3.1
o Windows 9x
o Windows NT
o Windows 2000
o Windows CE
o Mac (*)
o Unix (*)
Através da utilização de alguns add-ons disponíveis no mercado, como o Metaframe, é possível integrar clientes MAC e Unix num ambiente Terminal Server.
O software para a instalação nos clientes é fornecido com o sistema operativo, sendo de fácil implementação.
(*) Nota Necessário um add-on, não é disponibilizado de raíz
fig. 21
[pic]
Breve Análise
Dado que se trata de um ambiente multi-utilizador, existem algumas questões que podem afectar o sistema e o desempenho das aplicações.
Um dos principais problemas desta solução é o facto de muitas aplicações (a maior parte) que não sejam terminal-environment-aware, ou seja, não tenham sido desenhadas a pensar neste tipo de ambiente, apresentarem problemas. Estes problemas são devidos ao facto de a generalidade das aplicações necessitarem de uma área de trabalho para funcionarem correctamente, para ficheiros temporários, declaração de variáveis de sistema, etc, o que obriga a cuidados especiais na sua instalação; por exemplo, a instalação do Office 2000 no Windows 2000 com Terminal Services deve ser acompanhada do Resouce Kit da Microsoft.
A solução X-Windows apresenta bastante semelhanças, mas possui a vantagem de ser para além de uma aplicação, um verdadeiro paradigma de distribuição cliente/servidor, apresentando melhor suporte para as aplicações, as quais são pensadas de base para um ambiente distribuído.
O WTS é no entanto facilmente expansível, de fácil implementação e suporta vários tipos de clientes.
Capítulo
8
Conclusão
O orçamento das organizações para o sector das tecnologias de informação é esperado que alcance várias metas, mas duas são de realçar - a fiabilidade e segurança do sistema. Outras são esperadas, como a inovação, uma boa gestão de recursos e eficiência, mas a última coisa que se quer é uma rede de computadores instável em que não se pode depositar confiança.
Uma das maneiras de atingir esse objectivo é através da centralização na gestão e administração de redes informáticas. Esta necessidade é cada vez mais evidente, dadas as crescentes dimensões e exigências das redes, juntamente com o aumento da complexidade destas e a grande variedade de software disponível.
As tecnologias que permitem realizar esta metodologia de administração, quer se trate de Remote Boot ou outra tecnologia, ocuparão um lugar de crescente importância no futuro, assim como já acontece hoje.
A contribuir para a implementação de redes Remote Boot no futuro, especialmente as configurações diskless, temos o crescente aumento da largura de banda das NICs e restante equipamento de rede, a preços cada vez mais baixos. As placas 100Mbps são já uma norma corrente, permitindo taxas de transferência de até 12.5MB/seg, e dentro de alguns anos podemos esperar uma baixa, cada vez mais significativa, de placas a 1Gbps - com taxas de transferência até 125MB/seg, o que irá abrir portas a soluções cada vez mais interessantes e versáteis.
Bibliografia
developer.
dei.isep.ipp.pt/~andre/documentos
etherboot.
rmatik.uni-koeln.de/nais
han.de/~gero/netboot.html
nilo.
rmatik.uni-koeln.de/nais
han.de/~gero/netboot.html
- Bootware User Guide, Lanworks Technologies
- Preboot Execution Environment Specification (PXE), Intel Corporation, 1999
Anexo
I
Glossário de Termos Remote Boot
|Termo |Descrição |
|BIOS |Basic Input Output System |
| |Programa utilizado em PCs, localizado num chip ROM na motherboard; é o primeiro programa a |
| |arrancar no computador, inicializa os vários dispositivos presentes no computador e controla o |
| |fluxo de dados entre estes e o SO, entre outras funções (poupança de energia, ordem de busca de|
| |dispositivos de arranque, controle da temperatura interna da máquina, ...) |
|BOOT ROM |Chip numa placa de rede, o qual contêm normalmente o software necessário para inicializar um |
| |cliente remote boot; trabalha conjuntamente com a BIOS da máquina e providencia uma base de |
| |comunicação através de um protocolo para a realização dos seus propósitos |
|BOOTP |Boot Protocol |
| |Protocolo que permite que um computador obtenha as suas configurações de rede, assim como |
| |outras informações |
|broadcast |No contexto de redes informáticas, consiste na transmissão de mensagens de um endereço na rede |
| |para todos os endereços na rede. |
|DHCP |Dynamic Host Configuration Protocol |
| |Protocolo similar ao BOOTP, no entanto mais evoluído, pode ser considerado como sendo uma |
| |extensão a este último; permite a atribuição dinâmica de endereços de rede |
|EEPROM |Electronically Erasable Programmable ROM |
| |Chip de ROM programável (PROM) o qual pode ser apagado e reutilizado; O acto de apagar a |
| |informação é realizado através de um sinal eléctrico. |
|EPROM |Erasable Programmable ROM |
| |Chip de ROM programável (PROM) o qual pode ser apagado e reutilizado; O acto de apagar a |
| |informação é realizado pela exposição à luz UV, através de uma janela de quartzo no chip. |
|Etherboot |Um mecanismo de Remote Boot freeware |
|Ethernet |Tecnologia de transmissão de dados numa LANs, de grande popularidade e divulgação; está |
| |especificada nos standards IEEE 802.x. Existem várias larguras de banda - Ethernet 10Mbps, Fast|
| |Ethernet 100Mbps e GigaEthernet; os dispositivos de rede estão conectados por cabos e competem |
| |por acesso utilizando Carrier Sense Multiple Access with Collision Detection (CSMA/CD) |
|Flash ROM |Flash Read-Only Memory |
| |Por vezes chamada de “Flash RAM”, é um tipo de memória não volátil, com fornecimento de energia|
| |constante (normalmente uma pequena bateria ou pilha) que pode ser apagada e reprogramada em |
| |unidades de memória chamadas blocks. É uma variante das memórias EEPROM. Um dos seus usos mais |
| |frequentes é servir de suporte para a BIOS dos PCs. |
|GUID |Global Unique IDentifier |
| |O mesmo que UUID |
|LAN |Local Area Network |
|LOM |Lan-On-Motherboard |
| |Conceito de integração de um NIC na Motherboard. |
|MAC address |Media Access Control Address |
| |Endereço de 48 bits constante em placas de rede Ethernet que as identifica unívocamente a nível|
| |mundial; para tal, a cada fabricante é atribuído um bloco de endereços, sendo o endereço |
| |constituído por 6 números em hexadecimal, separados byte a byte. |
|MTFTP |Multicast Trivial File Transfer Protocol |
| |Uma extensão do protocolo TFTP, com suporte para multicast. |
|multicast |No contexto de redes informáticas, consiste na transmissão de mensagens de um endereço na rede |
| |para múltiplos endereços - específicos - na rede. |
| | |
|NBP |Network Bootstrap Program |
| |Programa com o objectivo de lançar um sistema operativo; num contexto de remote boot, é |
| |realizado um download do Bootstrap program a partir de um servidor de rede; por vezes tem a |
| |designação de boot block ou simplesmente de bootstrap program ou ainda de bootloader. |
|NDIS |Network Driver Interface Specification |
| |Norma do Windows, a qual define como deve ser efectuada a comunicação entre protocolos de |
| |comunicação (como o TCP/IP) e as placas de rede (ou NICs) |
|NetBEUI |NetBIOS Extended User Interface |
| |Protocolo desenvolvido pela IBM, sendo mais tarde adoptado pela Microsoft para o SO Windows. |
| |Permite o estabelecimento de comunicações Client/Server assim como Peer-to-Peer, sendo de |
| |simples configuração e rápida comunicação; é indicado apenas para LANs pequenas, devido a |
| |motivos de performance; por si só não permite o routeamento de pacotes, sendo muitas vezes |
| |utilizado em conjunto com outros protocolos como o TCP/IP ou IPX/SPX para ultrapassar essa |
| |limitação |
|Netboot |Um mecanismo de Remote Boot freeware |
|NFS |Network File System |
| |Serviço disponível em sistemas Unix e similares, baseado na arquitectura cliente/servidor, o |
| |qual permite que um computador aceda a ficheiros numa máquina remota, como se estes estivessem |
| |no próprio computador. |
|NIC |Network Interface Card |
| |Circuito numa placa que é instalado num computador para permitir a sua ligação a uma rede. Esta|
| |é desenhada especificamente para a tecnologia de transmissão da rede - ex: Ethernet, Token Ring|
| |- e fornecem uma ligação dedicada e permanente à rede. |
|NIS |Network Information System |
| |Sistema de administração e informação para LANs. Cada cliente ou servidor possui informações |
| |sobre todo o sistema, deste modo um utilizador pode realizar login em qualquer host e obter |
| |acesso a ficheiros em qualquer outra máquina com apenas um username e password. |
|OS |Operating System |
|Power Management |Tecnologia que permite que um sistema consuma menos energia quando não utilizado, mas fique |
| |operacional após “acordar”. |
|PROM |Programmable Read-Only Memory |
| |Chip de ROM programável. |
|Proxy DHCP |“Falso” servidor DHCP; extende o serviço DHCP no contexto da tecnologia PXE. |
|PXE |Preboot Execution Environment |
| |Tecnologia desenvolvida pela Intel, parte integrante da filosofia Wired for Management; é uma |
| |interface standard cliente/servidor que permite que computadores numa rede ainda sem SO |
| |realizem Remote Boot e seja configurados remotamente por um administrador. |
|RARP |Reverse Address Resolution Protocol |
| |Protocolo que permite que um computador descubra os seus parâmetros de rede, através da cache |
| |do protocolo ARP (Address Resolution Protocol) num servidor gateway; |
|Remote Boot machine |Computador que não depende totalmente de recursos locais para arrancar um sistema operativo, |
| |utilizando antes recursos remotos através de uma rede (normalmente uma rede local) |
|RIS |Remote Installation Services |
| |Conjunto de serviços disponibilizados pelo Windows 2000 Server, com o objectivo de realizar |
| |instalações remotas do sistema operativo Windows 2000 Professional em máquinas clientes remote |
| |boot |
|RPL |Remote Program Load |
| |Protocolo originalmente definido pela IBM que permite que workstations realizem o download de |
| |ficheiros de um servidor (de ficheiros) |
|TCO |Total Cost of Ownership |
| |Custo total de uma série de factores associado ao tempo de vida útil de um produto ou |
| |equipamento - incluindo compra de hardware e software, instalação, serviços, assistência, |
| |upgrades, treino, “downtime” e outros factores. |
|TCP/IP |Transmission Control Protocol / Internet Protocol |
| |Protocolo base para comunicação na Internet e em redes locais (Intranets) e de maior porte |
| |(Extranets). |
|TFTP |Trivial File Transfer Protocol |
| |Protocolo para a transferência de ficheiros através de uma rede, pode ser visto como uma versão|
| |ligeira do conhecido FTP; não é muito eficiente nem versátil, mas devido ao seu diminuto |
| |tamanho foi o escolhido para sistemas remote boot, dado que consegue caber na ROM de uma placa |
| |de rede. Não possui autenticação, utiliza o protocolo UDP em vez do TCP/IP para simplificação |
|UNDI |Universal NIC Driver Interface |
| |API que disponibiliza uma interface independente do dispositivo (NIC) para o NBP. |
|unicast |No contexto de redes informáticas, consiste na transmissão de mensagens de um endereço na rede |
| |para outro endereço na rede. |
|UUID |Universal Unique IDentifier |
| |Identificador único gerado pelo utilitário GUIDGEN; utilizado para identificar inequivocamente |
| |uma máquina numa rede. |
|Wake-on-LAN |Tecnologia que permite que um computador, enquanto desligado, possa ser “acordado” remotamente,|
| |através de um sinal difundido pela rede. |
|WAN |Wide Area Network |
|WfM |Wired for Management |
| |Standard desenvolvido pela Intel, baseado na tecnologia PXE, com o objectivo de facilitar a |
| |gestão de máquinas numa rede e reduzir o TCO de produtos informáticos, compreendendo vários |
| |mecanismos: de poupança de energia, gestão de informação, gestão preboot, entre outros. |
|XDM |X-Windows Display Manager |
-----------------------
fig. 4 - Um sistema Wired for Management (WfM)
DMI
Componente
DMI-compliant
Aplicação Gestão
DMI-compliant
fig. 5 - Desktop Management Interface
fig. 6 - A API PXE
fig. 7 - O processo de Remote Boot PXE
configs básicas da rede
configs PXE para o RB
para endereços IP estáticos
MAC address e IPs dos clientes
directório para downloads TFTP
path do ficheiro de log
através da porta 59
suporte para large packets (1408 bytes)
verbosidade máxima
Características dos Diferentes Mecanismos de Remote Boot
quadro I - Algumas características dos diferentes mecanismos Remote Boot
MAC address (identificador unívoco)
nome da máquina cliente
imagem SO
a ser utilizada
IP a atribuir à máquina cliente
Kernel image file name = bzImage
Output file name = /tftpboot/vmlinuz.nb
Ramdisk image file name = initrd.gz
Kernel command line = "auto rw root=/dev/nfs nfsroot=kernel \ nfsaddrs=rom ramdisk_size=10240"
Disk loader for net boot
Uncompressing... done
.
.
Found packet driver at int 60
Free memory: 31
.
.
BOOTP: Sending request (press ESC to abort): .ok
Local IP: 192.168.1.15
Server IP: 192.168.1.2 (192.168.1.2)
File name: /tftpboot/vmlinuz.nb
.
.
Uncompressing Linux... Ok, booting the kernel.
Anexo - Lista das placas suportadas pelo Etherboot
Nota Esta lista não significa que apenas estas NICs suportam Etherboot, mas sim que estas garantidamente permitem a sua implementação. Podem existir mais placas que o realizem.
fig. 3 - um programador de ROMs
SEM REMOTE BOOT
Ligar à Rede
Boot
Ligar o PC
início da
administração
COM REMOTE BOOT
Boot
Ligar o PC
Ligar à Rede
início da
administração
fig. 2 - Remote Boot diskless
Orientador:
Engº Paulo Ferreira
Realizado por:
André Teixeira David - i930465
(*) analisado no capítulo FEP case study
fig. 8 - O processo RIS
fig. 9 – Active Directory
fig. 10 – Propriedades do Servidor RIS
fig. 11 – Advanced Properties do RIS
fig. 12 – Personalização da ID das máquinas clientes
Fig X – Lista de imagens de Sos disponíveis
fig. 13 – As imagens de SO disponíveis
Fig X – As políticas de instalação
fig. 14 – Definição de políticas de instalação no RIS
fig. 15 – As políticas de instalação
fig. 16 -Esquema da rede dos alunos da FEP
[pic]
fig. 17 - Modo de funcionamento do Bootware num ambiente RPL (Remote Program Load)
fig. 18 - As áreas das máquinas clientes no PITON
fig. 19 - As “homes” dos alunos no PITON
fig. 20 - O Remote Boot Manager do NT Server 4.0 Server
fig. 21 - Windows Terminal Services
Introdução ao Remote Boot
Mecanismos de Remote Boot
Mecanismos PXE
Windows 2000 Server - RIS
Case Study - FEP
Tecnologias Complementares
Conclusão
Glossário de Termos Remote Boot
Remote Boot - Alguns Conceitos
fig. 1 - A administração em remote boot
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.