"Network/Remote Boot"Professor Adjunto do Depart amento de Engenharia Informática do ISEP Durante o arranque (inicialização) de um posto de trabalho, antes do arranque do sistema operativo ("boot"), são executados vários programas de inicialização residentes em ROM que fazem parte do BIOS do computador. Esta fase do arranque toma a designação de "pré-boot". Quando se adicionam ao barramento do computador outros dispositivos é conveniente que também estes possam definir programas a executar durante o "pré-boot". Assim existem espaços de endereço livre para este efeito:
Utilizando esta caracteristica é possível colocar uma ROM no computador de tal modo que este em lugar de efectuar o "boot" de forma tradicional (dispositivos locais), utilize serviços de rede para este efeito. A maioria das placas de rede possuem um "socket" livre para colocação de uma "EPROM" ("Erasable Programable ROM") e permitem definir o endereço de memória onde essa ROM será "colocada". A função do "software" residente nessa ROM pode ser muito variada. As ROMs de "boot" destinam-se a obter de um servidor de rede o sistema operativo para o "boot". Por isso contém um "driver" apropriado para a placa de rede, "software" de rede (IP/UDP/TCP, IPX/SPX, ...) e um cliente de rede para receber os ficheiros (TFTP, NFS, NCP, ...). Uma ROM de "boot" não pode simplesmente iniciar o "boot" quando é executada pelo BIOS, recorde-se que estas ROMs se destinam a inicializar dispositivos e como tal devem devolver o controlo ao BIOS sob pena de se comprometer todo o processo. Tipicamente, quando são executadas as ROMs de "boot" capturam ("desviam") uma ou várias das interrupções de "software" que são invocadas pelo BIOS no final do "pre-boot": 18h (antes de tentar o boot por A:) e 19h (depois de tentar o boot por A:). Na realidade a int 18h é uma reliquia do passado: destinava-se a invocar o interpretador BASIC. A especificação "Plug & Play" introduziu a possibilidade de um ROM se declarar especificamente como ROM de BOOT. Essa possibiliade foi mais tarde uniformizada com a "BIOS Boot Specification" (BBS). Um BIOS PnP BBS compativel cria uma lista de ROMs (associadas a dispositivos) que pretendem efectuar o "boot" e apresenta-a ao utilizador para que este possa optar. O primeiro ficheiro recebido da rede é um programa conhecido por "Network Bootstrap Program" (NBP) este programa é executado e assume o controlo das operações. Isto permite uma implementação muito mais flexivel do que se a funcionalidade do NBP fosse incluida na ROM. Porque a generalidade dos sistemas operativos não estão preparados para arrancar remotamente, nas implementaçães "diskless", o NBP cria um "ramdrive" onde coloca os ficheiros de arranque do sistema operativo (tipicamente coloca a imagem de uma disquete no "ramdrive"). BOOTP+TFTPEmbora existam várias soluções proprietárias, a mais divulgada utiliza os protocolos BOOTP e TFTP:
NetBoot e EtherBootO "software" NetBoot é um exemplo importante já que graças ao facto de usar "packet-drivers" permite criar EPROMS de "boot" para virtualmente qualquer placa de rede. O "software" Etherboot, derivado do anterior é menos flexivel, mas pode ser colocado em EPROMS mais pequenas, como por exemplo as 27xx64 com 8 Kb. Note-se que existem algumas placas de rede antigas que não suportam EPROMS maiores. Este "software" é "freeware" (GPL), e constitui-se numa boa solução para muitas situações, sendo compativel com a especificação BBS. A API disponibilizada por estas ROMs é muito limitada, disponibiliza apenas 3 funções acessiveis pela interrupção 78h: "Verificação de instalação", "Finalização", "Obter o endereço de acesso à API UNDI (Universal Network Driver Interface)". Especificação PXEA especificação PXE ("Preboot Execution Environment") foi desenvolvida pela Intel com contribuições de outros fabricantes. Trata-se de definir um "standard" para as ROMs de "boot". Se existir uma API bem definida e normalizada para as ROMs de "boot", então poderemos desenvolver NBPs PXE compativeis que funcionarão em todos os sistemas. Em termos de protolocos a especificação PXE utiliza o BOOTP/DHCP+TFTP, contudo define um vasto conjunto de extensões, por exemplo o TFTP "normal" limita o tamanho dos pacotes a 512 bytes, o "standard" PXE exige servidores TFTP especiais que suportam pacotes de 1408 bytes. O PXE também suporta TFTP em "broadcast" (MTFTP - "Multicast TFTP") para efectuar o "boot" simultaneo e sincronizado de um grande conjunto de postos de trabalho. Também relactivamente ao protocolo BOOTP a especificação PXE exige um servidor DHCP especial, com vários "TAGs" extra. As ROMs PXE não permitem o "boot" baseado nas interrupçães 18h ou 19h, exigem por isso que o BIOS seja BBS compativel. "PXE Split ROM Architecture"A especificação PXE utiliza uma arquitectura de ROM modular, na realidade existem tres partes distintas que podem ou não residir na mesma ROM física. Estas ROMs são:
A BC ROM é independente do "hardware" de rede, assim poderá ser incluido no BIOS do computador. A UNDI ROM contém o driver adequado para o "hardware" de rede, deve portanto estár colocado na placa de rede. A BUSD ROM é opcional, destinando-se apenas a placas de rede "CardBus". APIs PXEAs ROMs PXE disponibizam aos NBPs as seguintes APIs, que são aqui detalhadas a titulo de exemplo: Pre-Boot API
TFTP API
UDP API
UNDI API
A BC ROM implementa as APIs "Pre-Boot", "TFTP" e "UDP" devendo ser "removida" antes do "boot" do sistema operativo. Por outro lado a UNDI ROM que contém a interface com o "hardware" de rede deve manter-se para ser usada pelo sistema operativo. A BUSD API apenas existe quando se encontra instalada a BUSD ROM. Administração zeroA utilização destes métodos de arranque é muito vantajosa para os administradores de parques informáticos com elevado número de postos de trabalho:
Trata-se sem dúvida de uma solução "administração zero" muito tentadora, contudo temos de apontar alguns inconvenientes a ser solucionados:
Embora todos estes problemas possam ser resolvidos, adicionam alguma complexidade ao modelo inicial. Configuração dinâmicaO sistema operativo de um posto de trabalho com "remote/network boot" necessita de diversa informação sobre o "hardware" e a forma de o configurar correctamente. A configuração dinamica é uma operação que tem como objectivo definir de um modo automatizado a configuração da máquina. Esta operação deve ser realizada antes do "boot" pelo NBP ou durante o "boot" caso o sistema operativo suporte configuração dinamica. A solução que se pretende evitar é manter no servidor uma imagem especificamente configurada para cada posto de trabalho. Neste caso não há necessidade de qualquer configuração dinamica. Uma solução mais aceitável consiste em manter no servidor uma imagem para cada tipo de posto de trabalho (tipo de "hardware"). Nesta situação a configuração dinamica resume-se ao endereço IP e nome do posto de trabalho. A solução ideal seria manter no servidor apenas uma única imagem para todos os postos de trabalho. Isto implica um esforço de configuração dinamica muito significativo. Cada posto de trabalho possui um endereço MAC "gravado" na sua interface de rede, como cada endereço MAC é único é o valor ideal para utilizar como "indice" de uma base de dados onde se encontram os registos correspondentes às máquinas existentes. Em função do endereço MAC é necessário obter todos os outros parametros de configuração necessários ou escolher a imagem ou ficheiros correctos. "Remote/Network Boot diskless"Muitos anos atrás o "Remote/Network boot" teve origem nas máquinas "diskless". Trata-se de máquinas que não possuem disco para armazenar o S.O., como tal o NBP cria um "ramdrive" onde coloca os ficheiros necessários. Com o aumento da velocidade dos discos locais, redução do seu preço e aumento da sua fiabilidade, a solução "diskless" tornou-se menos atractiva. A introdução de mecanismos de "swap" em disco e aumento brutal do volume de ficheiros necessários aos sistemas operativos mais correntes tornou as configurações "diskless" muito complicadas sob o ponto de vista de eficiencia. As soluções "diskless" acrescentam contudo uma vantagem importante ao "Remote/Network boot": a ausencia de disco que se traduz por uma redução significativa no custo inicial de um PC (cerca de 1/6) e uma redução significativa na taxa de avarias do equipamento. A utilização actual de máquinas "diskless" tem duas aplicações possiveis:
Com a redução do preço da memória central (RAM) começa a ser atractiva a instalação de postos Win32 "diskless" de elevada performance baseados num "ramdrive" de grande dimensão. Actualmente o custo de um disco local corresponde a cerca de 128 Mb de RAM. Utilizando este "ramdrive" para instalar o Windows 98 num volume comprimido ("DrvSpace 3") obtem-se facilmente um disco de 250 Mb de capacidade. Com este espaço torna-se facil manter um posto de trabalho Windows 98 desde que as aplicações sejam instaladas em servidores de rede. "Remote/Network Boot" com disco localOs problemas resultantes da ausencia de disco local (postos de trabalho "diskless") podem ser resolvidos, simplesmente por adição de um disco local. Se numa implementação tradicional o NBP encarrega-se de criar um "ramdrive" onde coloca a imagem de "boot", neste tipo de implementação coloca directamente a imagem no disco. Existem actualmente diversos NBP's comerciais ou não, adaptados a estas tarefas, são programas que devem ter entre outras, além de compatibilidade PXE, as seguintes caracteristicas:
Além do NBP devem existir ferramentas de administração, nomeadamente para criar e gerir as imagens dos discos. BPBATCH (versão 3.20) O NBP "BPBATCH", desenvolvido pela "University of Geneva", é um bom exemplo de uma implementação não comercial. O NBP é na realidade um interpretador de comandos, depois de carregado o bpbatch" efectua o "download" (por TFTP) de um "script" (definido pelo TAG155 do bootp) e inicia a sua execução. A gestão de partiçóes é muito simples e baseia-se nos seguintes comandos:
O comando "SetPartitions" define a tabela de partições do disco (MBR), é usado um "string" com uma sequencia de identificadores de tipos de partição e respectivos tamanhos em Mb (ver exemplos abaixo). A sequencia especificada neste comando vai corresponder à númeração atribuida às partições, assim, como o número 0 está reservado para o MBR, a primeira partição especificada pelo comando "SetPartitions" terá o número 1. "FullUnzip" corresponde a uma cópia de sectores pelo que dispensa a formatação (comando "Clean Partitions"). O comando "IncrUnzip" descomprime ficheiros para uma partição já formatada, sem apagar os já existentes. Os tipos de partição suportados pelo "bpbatch" são: FAT16; EXT; BIGDOS; NTFS; FAT32; FAT32-LBA; BIGDOS-LBA; EXT-LBA; LINUX-SWAP; LINUX-EXT2. Na prática as operações são limitadas a apenas alguns tipos de partição. As operações FullUnzip e todos os manuseamentos de ficheiros individuais (IncrUnzip, Copy, Del, ...) estão limitadas a partições dos tipos FAT16/BIGDOS, FAT32 e LINUX-EXT2. As operações de limpeza de partições ("Blank Partition" e "Clean Partitions") são suportadas ainda para LINUX-SWAP e EXT. Um exemplo da sequencia de comandos para colocar Linux no disco local pode ser algo como: setpartitions "linux-ext2:992 linux-swap:32" fullunzip "linux.imz" 1 clean 2 Para MS-DOS ou Windows 95/98: setpartitions "bigdos:1024" setbootpart 1 fullunzip "dos.imz" 1 O "bpbatch" utiliza o cliente TFTP melhorado disponibilizado pela ROM PXE, mas também pode usar TFTP convencional. Os dados são transferidos pela rede sob a forma comprimida. A interface gráfica com o utilizador é funcional, mas não suporta rato. Como já foi referido existem comandos para gestão de ficheiros e directórios nas partições. Os ficheiros e directórios locais são referenciados na forma:
{:n}path/ficheiro
onde n representa o número da partição.
A configuração dinamica é conseguida de duas formas:
O "bpbatch" suporta autenticação de utilizadores atravez de um "gateway" instalado numa máquina linux. O comando CheckUser "user" "password" "domain"valida o utilizador usando esse "gateway" o dominio "Unix" corresponde a uma autenticação local/NIS, pode também ser usado um nome de dominio NT/Samba. Além deste comando de interface com o "gateway" existem comandos para cifragem e decifragem DES, bem como aplicação do algoritmo MD5. andre@dei.isep.ipp.pt http://www.dei.isep.ipp.pt/~andre |