Sistema de Boot Remoto

Universidade Federal de Santa Maria - UFSM Núcleo de Ciência da Computação - CCC Centro de Tecnologia - CT Administração da Rede - ADMREDE

Sistema de Boot Remoto: Instalação, Configuração e Geração de Imangens de Sistemas Operacionais

Diego Luís Kreutz [email protected]

1

Conteúdo 1

Introdução

3

2

Servidor DHCP 2.1 Atualização automática do arquivo de configuração . . . . . . . . 2.2 Geração automática dos menus . . . . . . . . . . . . . . . . . . .

3 6 6

3

Servidor TFTP

7

4

Bpbatch 4.1 Aumentando capacidade dos menus . . . . . . . . . . . . . . . . 4.2 Utilizando direntes tipos de menus . . . . . . . . . . . . . . . . .

8 8 9

5

Imagens Windows 5.1 Instalação e configuração do sistema . . . . . 5.1.1 Rede . . . . . . . . . . . . . . . . . 5.1.2 Autenticação de usuários e Domínios 5.2 Geração da imagem . . . . . . . . . . . . . .

6

7

Imagens Linux 6.1 Instalação e configuração do sistema . . . 6.1.1 Instalando software adicional . . . 6.1.2 Serviços . . . . . . . . . . . . . . 6.1.3 Rede . . . . . . . . . . . . . . . 6.1.4 Autenticação de usuários . . . . . 6.1.5 Montagem automática . . . . . . 6.1.6 Demais configurações . . . . . . 6.2 Compilando o Kernel . . . . . . . . . . . 6.3 Scripts de Atualização . . . . . . . . . . 6.4 Armazenando o /usr num servidor NFS . 6.5 Geração da imagem do sistema . . . . . . 6.6 Atualização dos menus e teste da imagem 6.7 Cuidados adicionais . . . . . . . . . . . . 6.7.1 Sistema de arquivos de rede . . . Conclusão

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . . .

10 10 10 12 14

. . . .

. . . .

. . . . . . . . . . . . . .

14 . 15 . 15 . 17 . 19 . 19 . 23 . 24 . 27 . 28 . 28 . 29 . 30 . 30 . 31 31

2

1

Introdução

A instalação, atualização e manutenção de vários laboratórios temáticos são tarefas que muitas vezes tomam uma considerável fatia de tempo dos administradores da rede. Foi com o objetivo de simplificar e agilizar estas tarefas que surgiram processos como o de boot remoto. Dentro deste contexto o objetivo deste trabalho foi analisar, testar e apresentar os principais passos para a instalação de um servidor de boot remoto. Além disso, mostrar os passos, idéias e problemas na geração e manutenção das imagens dos sistemas e apresentar soluções para alguns dos problemas mais comuns em um sistema de boot remoto que utilize o bpbatch [7]. As próximas seções apresentam uma descrição dos passos para a instalação de um servidor DHCP [4] e de um servidor TFTP [5]. Na sequência é brevemente apresentado o bpbatch e os processos, problemas, sugestões e soluções para a geração de imagens de Windows e de Linux.

2

Servidor DHCP

O papel essencial do servidor DHCP1 , no processo de boot remoto, é fornecer as configurações da máquina e indicar qual é o arquivo bpbatch[2] que será carregado. As configurações incluem parâmetros como endereço IP, nome, servidor DNS2 , Gateway, máscara de rede e nome do domínio. Abaixo segue um exemplo de configuração do servidor DHCP. # If you are using ISC DHCP 3.0, the syntax is slightly different. # Here is an example of a DHCP 3.0-compatible configuration : # DHCP configuration file for DHCP ISC 3.0 & BpBatch #################### ## Global options ## #################### option option option option option

subnet-mask 255.255.255.0; option-134 "nome-do-computador-text"; routers 192.168.100.1; domain-name-servers 192.168.100.2; domain-name "dominio.intranet.br";

subnet 192.168.100.0 netmask 255.255.255.0 { # Arquivo Bpbatch que sera carregado filename "bpbatch.P"; # IP’s dinamicamente alocados range 200.18.42.28 200.18.42.31; 1 2

Dinamic Host Configuration Protocol Domain Name Service

3

default-lease-time 120; max-lease-time 120; ## GRUPO: Laboratorio 1 ## group { # Nome do arquivo de menu do grupo option option-135 "-w menuLaboratorio1"; # Maquinas que compoem o grupo do laboratorio 1 host maquina01 { hardware ethernet 00:A0:D9:C1:D7:84; fixed-address 192.168.100.20; option option-134 "maquina01"; } host maquina02 { hardware ethernet 00:A0:D9:C1:D7:64; fixed-address 192.168.100.21; option option-134 "maquina02"; } } ## GRUPO: Laboratorio 2 ## group { # Nome do arquivo de menu do grupo option option-135 "-w menuLaboratorio2"; # Maquinas que compoem o grupo do laboratorio 2 host computador01 { hardware ethernet 00:A0:D9:C1:B7:84; fixed-address 192.168.100.40; option option-134 "computador01"; } host computador02 { hardware ethernet 00:A0:D9:C1:B7:64; fixed-address 192.168.100.41; option option-134 "computador02"; } } }

Para iniciar o servidor DHCP, supondo que o binários esteja no diretório /bootRemoto/, é simples. Basta digitar /bootRemoto/dhcpd. Provalvelmente, o arquivo /etc/dhcpd.conf deverá existir, ou seja, configurações semelhantes as acima deverão estar presentes neste arquivo. Outro arquivo que poderá também ser requisitado é o arquivo /var/lib/dhcp/dhcpd.leases. Caso você for utilizar algum servidor DHCP já compilado, efetuando a simples cópia do binário, talvez seja necessário a criação do diretório /var/lib/dhcp/ e posteriormente o arquivo dhcpd.leases. Normalmente o mode de depuração do servidor DHCP é a opção -d. Exemplo: /bootRemoto/dhcpd -d -d -d -d. 4

Exemplo de um arquivo de menu (menuLaboratorio1.bpb). InitGraph Set IsoLatin = "off" # Imagem de fundo da tela inicial de menu (boot.gif) Drawgif "boot.gif" # Numero de itens Set MenuNum=4 # Posicao inicial do menu na tela Set X=270 Set Y=260 # Itens que aparecerao no menu Set MenuItem="LinuxGentoo Windows98+OfficeXP Windows98Only BootLocal" Set CurrentItem=1 :menu DrawWindow $X $Y 245 261 DrawText ($X + 10) ($Y+2) " Opçoes de Boot" White Set i=1 # Desenha o menu :loop Set j=($i - 1) DrawText ($X + 10) (($Y+10) +($i*15)) "$MenuItem"{$j} White Set i=($i+1) if $i 1 Set CurrentItem = ($CurrentItem - 1) if "$key" == "^N" if $CurrentItem < $MenuNum Set CurrentItem = ($CurrentItem + 1) if "$key" == "\r" Set ExitMenu = "OK" if "$ExitMenu" != "OK" goto menu # Desvia para a if $CurrentItem if $CurrentItem if $CurrentItem if $CurrentItem

opcao selecionada pelo usuario == 1 goto a1 == 2 goto a2 == 3 goto a3 == 4 goto a4

:a1 hidelog clean 0 setpartitions "linux-ext2:1900" fullunzip "/imagens/Laboratorio1/linux/Gentoo.imz" 1 linuxboot "/imagens/Laboratorio1/linux/GentooKernel" "root=/dev/hda1" goto menu

:a2 showlog clean 0 setpartitions "BIGDOS:1900" SetBootPart 1 fullunzip "/imagens/Laboratorio1/windows/Windows98+OfficeXP.imz" 1 patch "altera.ref" "{:1}windows/altera.reg" copy "autoexec.ref" "{:1}autoexec.bat" HideBootProm hdboot:0

5

goto menu :a3 showlog clean 0 setpartitions "BIGDOS:1900" SetBootPart 1 fullunzip "/imagens/Laboratorio1/windows/Windows98Only.imz" 1 # Atualizacao de registro e configuracao do windows patch "altera.ref" "{:1}windows/altera.reg" copy "autoexec.ref" "{:1}autoexec.bat" HideBootProm hdboot:0 goto menu # Boot local :a4 SetBootPart 1 HideBootProm hdboot:0 goto menu

2.1 Atualização automática do arquivo de configuração Utilizando um arquivo de entrada que descreve os grupos, nomes das máquinas, endereços IP e hardware ethernet é possível facilmente construir um Shell Script que gere automaticamente o arquivo de configuração. Essa mesma entrada de dados pode ser utilização para gerar as tabelas de DNS, por exemplo. Abaixo segue um exemplo simples de um modelo de arquivo que poderia ser utilizado para tanto. A seguir, é apresentado o conteúdo do suposto arquivo de entrada "maquinas.txt". # Grupo|Nome|EnderecoIP|EnderecoEthernet|Aliases # LABORATORIO 1: inicio LABORATORIO1|maquina01|192.168.100.20|00:A0:D9:C1:D7:84|LABORATORIO1|maquina02|192.168.100.21|00:A0:D9:C1:D7:64|nfs-tmp # LABORATORIO 1: fim # LABORATORIO 2: inicio LABORATORIO2|computador01|192.168.100.40|00:A0:D9:C1:B7:84|LABORATORIO2|computador02|192.168.100.41|00:A0:D9:C1:B7:64|# LABORATORIO 2: fim

No exemplo apresentado, informações como aliases somente seriam úteis para a geração das tabelas de DNS. Este é apenas um simples e básico exemplo. Seu melhoramento e aperfeiçoamento parte da criatividade e necessidade de cada um.

2.2 Geração automática dos menus O mesmo é válido para os menus. A partir de uma estruturação simples dos diretórios de imagens é possível criar rapidamente um Shell Script básico que gere automaticamente os menus para cada conjunto de máquinas. É por isso, 6

por exemplo, que as imagens dos laboratórios 1 e 2 estão sub-divididas em dois diretórios, linux e windows. Pode ser observado, na seção 2, que o nome que aparecerá no menu é igual ao nome do arquivo da imagem, retirando-se apenas a extensão .imz. Com isso, não mais é necessário alterar manualmente os menus a cada inclusão de uma nova imagem. Além disso, é possível a programação do Shell Script para a geração de um menu com as opções clean 1 e clean -1. Essas duas opções, juntamente com a opção clean 0 limparão a partição de cache, a partição de sistema e o MBR. Algunas vezes isso pode ser necessário, principalmente em laboratórios cuja cache do disco local das máquinas não seja o suficiente para alocar todas as imagens. Logo, quando da alteração e/ou inclusão constante de imagens é aconselhável uma "limpeza geral"de vez em quando. Para evitar problemas como estouro de cache. Exemplo de uso (limpeza da cache, MBR e partição de boot): Set CurrentItem=1 if $CurrentItem == 1 goto a1 :a1 hidelog clean 0 clean 1 clean -1 setpartitions "linux-ext2:1900" fullunzip "/imagens/Laboratorio1/linux/Gentoo.imz" 1 linuxboot "/imagens/Laboratorio1/linux/GentooKernel" "root=/dev/hda1" goto menu

Contendo apenas isso dentro do menu provocará a carga automática da imagem Gentoo e limpará a MBR, a cache e a partição de boot.

3

Servidor TFTP

O servidor TFTP3 será quem enviará arquivos como o bpb.P e as imagens propriamente dita às máquinas clientes. Sua instalação e configuração é bastante simples. Em [2] é possível encontrar uma versão do TFTPD para o sistema de boot remoto. Mas, pode ser utilizado praticamente qualquer versão que acompanha a distribuição do Linux que estiver rodando no servidor. Exemplo de inicialização do servidor tftp: /bootRemoto/tftpd -v 0 -d /bootRemoto/ -l /bootRemoto/tftpd.log -s 1408 59 &

-v 0 : valor de exibição de mensagens igual a zero; 3

Trivial File Transfer Protocol

7

-d /bootRemoto/ : diretório de boot remoto (que contém arquivos como os do Bpbatch e demais arquivos especificados no DHCP); -l /bootRemoto/tftpd.log : arquivo de log; -s 1408 : tamanho dos pacotes de dados; 59 : porta. O diretório /bootRemoto/ deverá conter arquivos como o bpbatch.ovl, bpbatch.hlp, bpbatch.P e os arquivos de menu como especificados na configuração do servidor DHCP.

4

Bpbatch

Bpbatch é uma linguam interpretada que permite a configuração e criação de menus para o processo de boot remoto. Em conjunto com o servidor TFTP, especifica e inicia a carga da imagem escolhida pelo usuário. Na seção 2 é apresentado um exemplo de um arquivo de menu que utiliza a sintaxe e os recursos do sistema Bpbatch. Maiores informações podem ser encontradas em [7, 2, 6].

4.1 Aumentando capacidade dos menus Um problema que pode surgir é a falta de espaço para exibir os vários nomes de imagens no menu. O sistema bpbatch limita suas variáveis a 13 elementos, ou seja, pode-se colocar apenas 13 nomes em uma lista de nomes de um menu. Uma maneira de resolver isso é criando-se duas variáveis que conterão o nome das imagens. Na seção 2 é apresentado um exemplo de configuração de um menu bpbatch. Para implementar a solução de duas listas de variáveis basta fazer alguns ajustes. Abaixo seque uma exemplificação de uma alteração que torna possível manter o menu gráfico aumentando o número de elementos. Isso por que uma outra solução seria um menu em modo textual, menos limitado ao número de elementos suportados por um variável. InitGraph Set IsoLatin = "off" Drawgif "boot.gif" Set MenuNum1=12 # numero de itens da primeira lista Set MenuNum=15 # numero de itens total Set MenuNum2=2 # numero de itens da segunda lista Set X=300 Set Y=240

8

Set MenuItem1="Linux+Gnome Linux+Khoros Linux+WindowMaker Windows98+Delphi4 Windows98+Arena3.1 Windows98+Homesite Windows98+JDK1.3 Windows98+Office Windows98+Rose Windows98+SystemOnly Windows98+Xilinx BootLocal" # nomes da primeira lista Set MenuItem2="Windows98+Toolbook BootLocal" # nomes da segunda lista Set CurrentItem=1 :menu DrawWindow $X $Y 200 240 DrawText ($X + 10) ($Y+2) " Set i=1

Opçoes de Boot" White

:loop # desenha a primeira lista Set j=($i - 1) DrawText ($X + 10) (($Y+10) +($i*15)) "$MenuItem1"{$j} White Set i=($i+1) if $i Configurações -> Painel de Controle -> Rede -> TCP/IP ou Explorer -> Ambiente de Rede -> Propriedades -> TCP/IP. Gateway: número IP do gateway; Configuração WINS: Utilizar DHCP; Endereço IP: Obter automaticamente; Configurações DNS: Ativar DNS; • Host: imagem (nome ficticio); • Domínio: nome do domínio (ex.: intranet.br); • Ordem servidor DNS: endereço IP do servidor primário, endereço IP do servidor secudário, . . . ; Normalmente essas configurações são obtidas automaticamente do servidor DHCP. Mas, em alguns casos, pode ser necessário configurá-las. 10

WindowsXP Caso exista um servidor DHCP funcionando na rede, e atendendo a pedidos de máquinas clientes, o WindowsXP sairá funcionando. Isso por que pode-se selecionar em tempo de instalação a opção de utilizar servidor DHCP, ou seja, obter IP dinamicamente. O WindowsXP permite que a máquina ingresse em um domínio também em tempo de instalação. O que pode ser prático e desejável. Nao obtando pela opção de configuração via DHCP, durante o processo de instalação, é possível configurar o WindowsXP após instalado. Para tanto, basta setar as opções Obter um endereço IP automaticamente e Obter o endereço dos servidores DNS automaticamente no painel de Propriedades de Protocolo TCP/IP (Ambiente de Rede -> Propriedades -> TCP/IP). Para incluir o WindowsXP em um domínio basta ir em Meu Computador -> Propriedades -> Nome do Computador -> Alterar. Será solicitado um usuário, senha e um domínio. O usuário deve ser o super usuário do domínio. Se for um servidor samba, deve existir algum usuário que tenha permissão para incluir máquinas no domínio. Supondo que esse usuário seja o "root"do samba. Neste caso, normalmente pode-se manter esse usuário bloqueado por medidas de segurança. Para liberá-lo, basta digitar o comando smbpasswd -e root na máquina que contém o servidor samba. Também sua senha pode ser trocada a cada vez que o usuário for utilizado. Isso pode ser feito pelo mesmo comando sem a opção -e. Além disso, deve existir uma linha, como a que segue, no arquivo de configuração do samba, que permite que o usuário root inclua máquinas no domínio. add user script = /usr/sbin/useradd -d /dev/null -g 100 -c "Maquina Do Dominio do Samba-s /bin/false -M %u Agora, basta fornecer o nome de usuário "root", sua senha e o nome do domínio samba. Exemplo: Nome do Usuário: root Senha: ******* Domínio: SAMBA-CCC Após incluida a máquina no domínio é recomendável que se bloqueie o usuário root do samba através do seguinte comando smbpasswd -d root Além disso, a linha add user script = /usr/sbin/useradd -d /dev/null -g 100 -c "Maquina Do Dominio do Samba-s /bin/false -M %u também pode ser comentada, evitando que alguém descubra a senha de root e ou consiga incluir uma máquina no domínio tendo acesso a dados de usuários da rede.

11

5.1.2 Autenticação de usuários e Domínios Para completar a configuração da imagem são ainda necessárias algumas configurações referentes a autenticação, logon, preferências e domínios. As próximas seções apresentam maiores detalhes. É necessário a realização de algumas alterações no registro do Windows para que o sistema de autenticação e validação funcione. No caso do Windows98 e Windows98SE pode ser utilizado o aplicativo poledit.exe, disponível no CD de instalação do windows (CDROM:\tools\reskit\netadmin). Já no WindowsXP existe o aplicativo gpedit.msc (Inicar -> Executar -> gpedit.msc). Windows98 Execute o aplicativo poledit.exe. Após, siga os passos: Arquivo -> Abrir Registro -> Computador Local -> Rede. Agora, altere as seguintes opções: 1. Controle de Acesso; (a) Em nível de usuário; Nome do Autenticador: Nome do domínio (ex.: SAMBA-CCC); Tipo de Autenticação: Servidor/Estação de trabalho Windows NT; 2. Logon; (a) Manchete de Logon; Legenda: Nome ou tipo da máquina; Texto: Nome da Imagen que será gerada; (b) Requer Validação; 3. Cliente para Rede Windows; (a) Logon no Windows NT; Domínio: Nome do domínio (ex.: SAMBA-CCC); (x) : Exibir confirmação de logon no domínio; (x) : Desativar cache de senha de domínio; (b) Grupo de Trabalho; Grupo de trabalho: Nome do grupo de trabalho (ex.: SAMBA-CCC); 4. Senhas;

12

(a) Ocultar senhas de compartilhamento com asteriscos; (b) Desativar cache de senhas. Agora falta ainda alterar as diretivas de sistema. Para tanto, execute o seguinte: Arquivo -> Abrir Registro -> Computador Local -> Sistema. Agora, altere as seguintes opções: 1. Ativar perfis de usuário; 2. Caminho da rede para a instalação do Windows; Caminho: \\servidorRemoto\diretorio (ex.: \\samba\install\win98cabs); 3. Executar; 4. Executar serviços. WindowsXP Para configurar o WindowsXP pode-se utilizar o regedit e o gpedit.msc. Utilizando o regedit (Iniciar -> Executar -> regedit), altere o valor do parâmetro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\netlogon\parameters\"RequireSignOrSeal" para zero. Agora, abra as diretivas locais de segurança (Iniciar -> Configurações -> Painel de Controle -> Ferramentas administrativas -> Diretivas de seguranca local). Ative as seguintes opções: 1. Membro de domínio; (a) assinar digitalmente dados do canal seguro (sempre que possível); (b) criptografar dados do canal seguro (sempre que possível); (c) criptografar ou assinar digitalmente os dados de canal seguro (sempre); (d) requer uma chave se sessão de alta segurança. 2. Desligamento; (a) limpar arquivo de paginação de memória virtual; 3. Controlador de domínio; (a) recusar alterações de senha de conta de computador;

13

Por fim, execute o gpedit.msc (Iniciar -> Executar -> gpedit.msc). Vá em Diretiva Computador local -> Configuração do computador -> Modelos administrativos. Ative os seguintes items: 1. Sistema; Perfis de usuário: Excluir cópias em cache de perfis móveis;

5.2 Geração da imagem Faça o download do aplicativo "mrzip"[1, 7] e do exemplo de configuração para a geração de imagens Windows. Copie os arquivos mrzip.exe e windows.mrz para a pasta temporária onde será armazenada a imagem criada. Normalmente é utilizado um diretorio "unidade:\temp"(ex.: "c:\temp"). Configure o arquivo "windows.mrz"de acordo com seus critérios e necessidades. Apos configurado o arquivo mrz (no nosso caso "windows.mrz"), basta abrir um prompt do DOS, ir ateh o diretório temporário, onde esta o mrzip.exe e o windows.mrz, e digitar: mrzip windows (onde windows eh o nome do arquivo de configuracao sem a extensao mrz) Apos gerada a imgem basta envia-la ao servidor tftp, incluir na lista dos menus apropriados e testa-la.

6

Imagens Linux

O processo de instalação e configuração de imagens de sistemas operacionais Linux pode ser uma tarefa levemente mais trabalhosa que o processo de uma imagem Windows. Isso por que existem uma série de detalhes que tornam as imagens de sistemas Linux mais fáceis de gerenciar e atualizar. Esta vantagem tem um preço. A primeira imagem gerada do sistema dará um bom trabalho. No entanto, atualizações, configurações e instalações de software adicionais será muito mais simples e prática. As próximas seções descrevem os passos para a instalação, configuração e geração de imagens Linux baseadas na distribuição RedHat 8.0. Isso se deve ao fato se esta ter sido escolhida como a distribuição padrão dos laboratórios do Curso de Ciência da Computação. Entre os quesitos levados em consideração no processo de escolha desta distribuição estão a facilidade de instalação e configuração, as características tipicas de uma distribuição destinada a redes de computadores. Entretanto, apesar dos novos sistemas de atualização e instalação de pacotes, como o apt-get para rpm’s, está se pensando em deixar de utilizar a distribuição 14

RedHat e utilizar a distribuição Debian ou Mandrake. Esse fato é devido principalmente ao novo sistema de atualização e registro da RedHat. Ou seja, esta distribuição Linux está se tornando cada vez mais corporativa e, de certa forma, fechada. Mas, por outro lado, seria interessante manter essa distribuição ja que um dos papeis de um curso de ciência da computação é a formação de profissionais qualificados para o mercado de desenvolvimento de soluções para os mais diversos problemas. Neste contexto, praticamente está em pauta a questão corporativa. Logo, a distribuição RedHat, bem como a Suse, são as que estão apresentando maior aceitação e utilização dentro desse nicho de mercado.

6.1 Instalação e configuração do sistema Por uma questão de praticidade e agilidade opta-se pela instalação completa do Linux. Isso é facilmente atingível com a distribuição RedHat. Baste escolher instalação personalizada (custom) e selecionar a opção instalar todos os pacotes ((x) Everything). Quanto ao processo de partição, devido a utilização do boot remoto e novamente por uma questão de praticidade, cria-se somente uma única partição capaz de alocar todos os dados dos pacotes que serão instalados. Na versão 8.0 do RedHat isso quer dizer que serão necessários aproximadamente 5 Gigabytes de espaço em disco. Parece muito. Mas, como será visto mais adiante, a imagem final do sistema terá apenas uma ou duas centenas de Megabytes. Isso por que o diretório /usr será copiado para um servidor NFS e posteriormente importado pela imagem do sistema. Após a instalação inicia-se o processo de configuração e atualização do sistema. Um primeiro passo é a instalação de pacotes de software ou aplicativos que não venham por padrão na distribuição do Linux utilizada. Um segundo passo é a habilitação/desabilitação de serviços e sub-sistemas. Por fim, é necessário configurar a rede adequadamente, o sistema de autenticação de usuários, o kernel, os pontos de montagem de sistemas de arquivos remotos e a geração, teste e armazenamento da imagem propriamente dita. 6.1.1 Instalando software adicional Numa rede acadêmica pode ser necessário a instalação de software que não venha junto com a distribuição Linux. Esse é um fato comum de ocorrer devido a grande variedade de sistemas e aplicativos para os mais variados fins e desejos dentro de um meio acadêmico que preze a pesquisa, didática e desenvolvimento das capacidades dos estudantes. A instalação desse tipo de software adicionais, compilado ou através de pacotes, deve ser estruturado de tal forma que futuras atualizações não necessáriamente 15

necessitem a re-instalação destes aplicativos adicionais. Esse objetivo pode ser facilmente atingível através da instalação de todo software adicional em uma única localização. Um exemplo seria a instalação no diretório /usr/local/programas. Esse diretório conteria todos os aplicativos e bibliotecas adicionais a distribuição padrão do Linux em utilização. No caso de sistemas compilados o interessante seria utilizar a opção estática caso presente. Isso evitaria futuros problemas de incompatibilidade de bibliotecas, por exemplo. Problema não tão incomum quanto da atualização ou troca de versão do sistema. Com um diretório padrão definido para a instalação de aplicativos adicionais fica fácil e prático o gerenciamento, atualização e configurações posteriores. No entanto, é preciso não esquecer que estes aplicativos não estarão por padrão inclusos, acessíveis, aos usuários. A variável de ambiente PATH, que contém os caminhos que busca e localização de arquivos binários (executáveis), não incluí diretórios como /usr/local/programas/bin. Neste caso é necessário incluir diretamente no arquivo padrão de configuração do shell, como o /etc/bashrc, ou fazer os links necessários para diretórios como o /usr/local/bin e /usr/bin, que são setador por padrão como diretórios de busca de arquivos executáveis. O processo de criação de links pode ser simples e praticos. Um simples comando como ln -s /usr/local/programas/bin/* /usr/local/bin seria o suficiente para cria uma referência de arquivo no diretório /usr/local/bin para todos os executáveis contidos no diretório /usr/local/programas/bin. Ou, no caso da modificação da variável PATH, bastaria incluir uma linha do genero export PATH=$PATH:/usr/local/programas/bin no arquivo /etc/bashrc, arquivo de configuração do shell bash, e nos demais arquivos de configuração dos demais shells. No entanto, esse processo não garantiria que todos os usuários teriam sua variável PATH devidamente setada. Pois cada usuário pode especificar a ordem de verificação e utilização do arquivo de configuração do shell que melhor lhe convier. Exemplos simples de software adicional desejado por professores e estudantes de computação podem ser: Cnet: simulador de redes e protocolos; Interbase: sistema de gerenciamento de banco de dados; Khoros: ambiente de manipulação e processamento de imagens; Java: plataformas de desenvolvimento e execução de aplicações Java, como a da SUN, IBM, entre outras; Acrobat: visualizador de arquivos pdf; Navegadores: navegadores como o Links, Opera e Mozzilla; 16

GNUstep: plataforma de desenvolvimento de aplicações dinâmicas baseadas na linguagem de programação Objective-C; Pajé: ferramenta de visualização de aplicações paralelas; CORE: ambiente de desenvolvimento e execução de aplicações heurísticas; TKgate: simulador de circuitos digitais; Mancha: simulador do processador ipotético Mancha; Gcc: diferentes versões do gcc para a geração e compilação de código para diferentes arquiteturas de máquianas (i386, Sparc, PowerPC, MIPS, 68000, Alpha); Pode-se facilmente perceber a importância e utilidade de um repositório específico para esse tipo de software adicional. No decorrer do tempo, com o desenvolvimento de novas ferramentas e tecnologias, a tendência é emergir cada vez mais a praticidade desse diretório específico de instalação de novas aplicações. Como os aplicativos "extras"são instalados num diretório como /usr/local/programas, instalações, configurações e atualizações após a imagem do sistema operacional ter sido gerada e alocada no servidor são simples e praticas. Isso por que basta liberar acesso de escrita a uma máquina, que acabou de carregar a imagem do Linux, ao diretório compartilhado /usr, que está alocado em um servidor de arquivos. Não é sequer necessário gerar novamente a imagem do sistema operacional, ou seja, basta instalar ou atualizar o aplicativo desejado. 6.1.2 Serviços Devido a instalação completa realizada, foram instalados e estão disponíveis todos os serviços que acompanham a distribuição do Linux utilizada. Alguns já estão abilitados e serão executados quando da incialização do sistema. Outros, não estão configurados ou estão desabilitados. Sabe-se que existe uma gama bastante grande de serviços no sistema. Mas, normalmente é desejável ativar os serviços realmente necessários e que sejam o mínimo possível passíveis de problemas de segurança. Até por que é facilmente habilitável algum outro serviço que seja de interece de um conjunto de usuários da comunidade da rede. Uma forma simples de tornar ativos apenas serviços essenciais é através da criação de um sistema de shell scripts que automaticamente realize essa tarefa. Para exemplificar melhor toma-se um exemplo. Supondo-se que existam o seguinte serviços no /etc/init.d: aep1000, crond, irda, lpd, ntpd, rhnsd, sshd, anacron, firstboot, isdn, netfs, pcmcia, saslauthd, 17

syslog, apmd, functions, kdcrotate, network, portmap, sendmail, xfs, atd, gpm, keytable, nfs, postfix, single, xinetd, autofs, halt, killall, nfslock, random, snmpd, ypbind, bcm5820, iptables, kudzu, nscd, rawdevices, snmptrapd. Deseja-se apenas ativar os seguintes serviços: xinetd, xfs, atd, gpm, syslog, network, autofs Neste caso pode-se utilizar um script do gênero, supondo que o init 3 e 5 somente serão utilizados: for i in 3 5 do cd /etc/rc$i.d/ for j in xinetd xfs atd gpm syslog network autofs do if test -f S$j then NOME=‘echo $j | tr ’S’ ’K’‘ mv $j $NOME fi done done

O que este simples script faz é testar para ver se existe algum link simbólico, no nível 3 ou 5 de inicialização, indicando a inicialização do serviço no processo de carga e inicialização do sistema. Neste caso, todos os serviços que serão inicializados no nível 5, por exemplo, iniciam pela letra S, seguida de um número que indica a ordem de execução e o nome do serviço (igual ou idêntico ao nome encontrado no /etc/init.d. Trocando a letra S pela letra K, o serviço não mais será inicializado naquele nível. Agora ainda restam os serviços ativados pelo xinetd. Estes são configurados e setados, normalmente, no diretório /etc/xinetd.d/. Tomando-se novamente um exemplo para facilitar o entendimento. Supondo a existência dos seguintes arquivos que configuram diferentes serviços: chargen, daytime, echo, rsync, services, time, chargen-udp, daytime-udp, echo-udp, servers, sgi_fam, time-udp. E desejase somente habilitar os seguintes serviços: rsync e daytime. O script abaixo realiza esta tarefa: cd /etc/xinetd.d/ # desabilita todos os serviços for i in * do cat $i | sed ’s/\(^.*disable .*=\).*$/\1 yes/g’ > $i.tmp cat $i.tmp > $i rm -f $i.tmp done # habilita somente os serviços desejados for i in rsync daytime do cat $i | sed ’s/\(^.*disable .*=\).*$/\1 no/g’ > $i.tmp cat $i.tmp > $i rm -f $i.tmp

18

done

Neste ponto, já se selecionou os serviços que serão incializados quando da escolha de carga do nível 3 ou 5. Como pode-se perceber, através da utilização de shell scripts bastante simples é facil e rapidamente realizável esta etapa. 6.1.3 Rede A configuração da rede do Linux é um passo fundamental para o bom funcionamento do boot remoto utilizando DHCP. É necessário indicar ao sistema a utilização do servidor de IPs dinâmico. Para tanto basta alterar alguns arquivos. Entre eles o /etc/sysconfig/network. Neste arquivo é somente necessária a seguinte linha: NETWORKING=yes. Um segundo arquivo que deve ser alterado é o /etc/sysconfig/network-scripts/ifcfg-eth0. Seu conteúdo deve ser igual ou semelhente ao trecho abaixo: DEVICE=eth0 BOOTPROTO=dhcp ONBOOT=yes

Com a configuração destes dois arquivos as opções de inicialização da rede devem estar corretas. Esse processo de configuração desses arquivos pode ser feito automaticamente através de um pequeno shell sript como o que segue: printf "NETWORKING=yes" > /etc/sysconfig/network printf "DEVICE=eth0\nBOOTPROTO=dhcp\nONBOOT=yes\n" > \ /etc/sysconfig/network-scripts/ifcfg-eth0

Com isso tem-se a rede configurada indicando a utilização de IPs definidos/disponibilizados pelo servidor DHCP. A utilização do servidor de nomes dinâmico, facilita e simplifica o processo de controle e atribuição de endereços IP as máquinas de uma rede. Os passos de configuração da rede, citados nos parágrafos anteriores, levam em consideração que a placa de rede está devidamente instalada, ou seja, possui o driver apropriado instalado e automaticamente carregado quando da inicialização do sistema. 6.1.4 Autenticação de usuários A tarefa de autenticação e controle de acessos de usuários é uma das partes mais importantes e críticas de qualquer rede de computadores que possua vários usuários utilizando as mesmas máquinas e sistemas. No nosso caso são utilizados dois sistemas de autenticação que trabalham de forma integrada. São eles o Samba e o LDAP. O primeiro é responsável pela autenticação de usuários em máquinas Windows. Já o segundo é responsável pela autenticação de usuários nos demais sistemas. Como o login no Linux, Webmail, acesso remoto via SSH, entro outros. 19

Clientes LDAP Como o sistema de autenticação do Linux utilizará a base de informações do LDAP para autenticar os usuários é necessário configurar o cliente LDAP do sistema. Incialmente é preciso realizar algumas modificações na organização dos arquivos de configuração do LDAP cliente. Quando da instalação completa do sistema podem ser encontrados dois arquivos ldap.conf no /etc. O /etc/ldap.conf e o /etc/openldap/ldap.conf. Para evitar problemas e conflitos deve-se apagar um dos dois arquivos e criar um link simbólico para o outro arquivo. Isso fará com que qualquer cliente LDAP do sistema sempre veja o mesmo arquivo de configuração. Abaixo segue um exemplo de como seria este procedimento: rm -f /etc/ldap.conf ln -s /etc/openldap/ldap.conf /etc/

No caso da nossa rede, as únicas linhas necessárias no arquivo ldap.conf são as que seguem: base dc=inf,dc=ufsm,dc=br uri ldaps://ldap.inf.ufsm.br/ ldaps://ldap2.inf.ufsm.br/ ldap_version 3 ssl on

A primeira linha indica o nome da base no domínio. Essa base é definida e setada quando da configuração do servidor LDAP. Na segunda linha são definidos os endereços dos servidores LDAP. No caso, existem dois servidores que podem ser consultados. Onde um é uma réplica do servidor primário. Para diminuir a carga do servidor primário basta configurar a imagem de um conjunto de máquinas invertendo a ordem de consulta. Neste caso, a segunda linha ficaria igual a que segue: uri ldaps://ldap2.inf.ufsm.br/ ldaps://ldap.inf.ufsm.br/

Essa configuração fará com que os cliente LDAP consultem primeiramente o servidor ldap2.inf.ufsm.br e, caso necessário, posteriormente o servidor ldap.inf.ufsm.br. Após devidamenet configurados os clientes LDAP falta configurar o PAM e o nsswitch dizendo para permitirem autenticação e consulta via LDAP. Para testar e ver se o LDAP cliente esta devidamente configurado utilize o comando ldapsearch. Exemplo: ldapsearch -x.

20

PAM O PAM, por padrão, não possibilita autenticação via LDAP. Para habilitar esta opção basta editar o arquivo /etc/pam.d/system-auth e incluir as linhas referentes ao LDAP. Além de incluir estas linhas é necessário também alterar algumas opções, de todas as linhas que as apresentarem, como nullok. Em especial, modificar a linha password sufficient /lib/security/pam_unix.so acrescentando os seguinte parâmetros: use_authtok, md5, shadow e max=20. Onde esta última é o parâmetro mais crítico. Sem esta opção setada usuário que possuirem senhas com mais de 7 caracteres não conseguirão logar no sistema. O trecho abaixo é um exemplo de como ficaria o arquivo system-auth após alteradas algumas opções e incluidas as linhas para tornar ativa a autenticação via LDAP. auth auth auth auth account password password password password session session session

required sufficient sufficient required required required sufficient sufficient required required required optional

DIR/pam_env.so DIR/pam_unix.so shadow md5 likeauth DIR/pam_ldap.so use_first_pass DIR/pam_deny.so DIR/pam_unix.so DIR/pam_cracklib.so retry=3 type= DIR/pam_unix.so use_authtok md5 shadow max=20 DIR/pam_ldap.so use_authtok DIR/pam_deny.so DIR/pam_limits.so DIR/pam_unix.so DIR/pam_ldap.so

Onde a cadeia de caracteres DIR representa a cadeia "/lib/security". Caso a autenticação via LDAP não funcione após a configuração do PAM é necessário trocar a biblioteca pam_ldap.so do sistema. Isso por que ela pode estar sem suporte a SSL. Neste caso, basta copiar esta biblioteca de uma outra máquina que já esteja funcionando com autenticação por LDAP ou compilar o código fonte do pam_ldap para gerar esta biblioteca com suporte a SSL e OpenLDAP. nsswitch O arquivo /etc/nsswitch.conf, que indica quais os sistemas serão consultados e em que ordem, deve conter a opção ldap setada ao menos nos sistemas de autenticação. Abaixo segue um exemplo de configuração desse arquivo com suporte a LDAP. passwd: shadow: group: hosts: bootparams: ethers: netmasks: networks:

files files files files files files files files

ldap ldap ldap dns ldap ldap ldap ldap

21

protocols: rpc: services: netgroup: publickey: automount: aliases:

files files files files ldap files files

ldap ldap ldap ldap

ldap

SSH Devido a opções e compatibilidade é necessário baixar o SSH disponível na página da Informática e compilá-lo para a arquitetura desejada. Abaixo seguem as opções de configuração para a compilação do SSH. ./configure --without-ssh-agent1-compat --without-internal-ssh1-compat make make install

Esses comandos farão com que o SSH seja compilado sem suporte a versões anteriores a versão 2 do SSH e irão instala-lo em /usr/local/. Após a instalação é necessário criar ou copiar o script de inicialização do demônio SSH da máquina. Esse script deve ser colocado em /etc/init.d/ e pode ser copiado de qualque máquina, da rede interna, que contenha o sshd rodando. Para ver se a máquina esta ou não rodando o sshd basta executar o comando nmap nomeDaMaquina. Caso o demônio SSH esteja rodando deverá aparecer uma linha indicando que o serviço está aberto na porta X. Por fim, faça os links necessários para que o sshd seja carregado automaticamente quando o sistema é inicializado. O script abaixo realiza esta tarefa. for i in 3 5 do ln -s /etc/init.d/sshdinit /etc/rc$i.d/S99sshd done for i in 0 6 do ln -s /etc/init.d/sshdinit /etc/rc$i.d/S99sshd done

Configurando o SSH Máquinas clientes, como as dos laboratórios temáticos, devem ter acesso restrito ao domínio interno via SSH. Ou seja, os usuários da rede tem permissão para logar, via shell seguro, de uma máquina interna para outra, mas não de uma máquina externa para uma máquina interna. A única excessão é a máquina ssh.inf.ufsm.br. Esta sim tem acesso externo liberado. A fim de garantir esta restrição basta incluir ou descomentar a seguinte linha do arquivo sshd2_config: AllowHosts 200.18.42.*. 22

Além disso, usuários como sala334 e ncc devem ser bloqueados (DenyUsers sala334,ncc). Outra linha que deve ser observada é a linha de autenticação do arquivo sshd2_config e ssh2_config. Na linha que indica as autenticações permitidas deve estar inclusa a a diretiva [email protected] que indica/habilita a possibilidade de autenticação via pam_ldap. Os arquivos de configuração do SSH, segundo o processo de instalação descrito na seção anterior, encontram-se no diretório /etc/ssh2/. Abaixo segue um exemplo de configuração do arquivo sshd2_config e ssh2_config, respectivamente. HostKeyFile hostkey PublicHostKeyFile hostkey.pub RandomSeedFile random_seed VerboseMode no QuietMode no SyslogFacility AUTH SyslogFacility LOCAL7 SftpSyslogFacility LOCAL7 Port 22 ListenAddress any RequireReverseMapping no NoDelay yes KeepAlive yes MaxConnections 29 Ciphers AnyCipher MACs AnyMAC PrintMotd yes CheckMail yes UserConfigDirectory "%D/.ssh2" AuthorizationFile authorization SettableEnvironmentVars LANG,LC_(ALL|COLLATE|CTYPE|MONETARY| NUMERIC|TIME),PATH,TERM,TZ AllowX11Forwarding yes AllowTcpForwarding yes AllowedAuthentications publickey,[email protected],password UserKnownHosts yes AllowAgentForwarding yes PermitEmptyPasswords no PasswordGuesses 3 AllowHosts 200.18.42.* DenyUsers sala334,ncc PermitRootLogin yes subsystem-sftp sftp-server .*: AllowedAuthentications [email protected],publickey,password DefaultDomain inf.ufsm.br

6.1.5 Montagem automática O controle e manipulação automática dos pontos de montagem de um sistema de arquivos é algo útil e desejável. Principalmente em máquinas clientes que montam vários sistemas de arquivos de rede. Como é o caso dos computadores que fazem parte dos diversos laboratórios temáticos dos nossos laboratórios. 23

O automount, juntamente com o script de inicialização autofs, são adequados para esta tarefa. Através da simples configuração do arquivo /etc/auto.master é possível dizem ao automount qual é o arquivo, ou quais são os arquivos, que contem a descrição dos pontos de montagem. A partir da definição destes arquivos, e da descrição dos pontos de montagem, a partir do momento em que o autofs for inicializado ou re-inicializado o sistema estará pronto para realizar automaticamente as montagens dos pontos de montagem especificados na hora em que for necessário. Exemplo de um arquivo auto.master: /home

/etc/auto.home

--timeout=180

Este exemplo esta dizendo ao automount que existe um arquivo /etc/auto.home que define os pontos de montagem válidos para o diretório /home. O arquivo /etc/auto.home descreve quais diretórios dentro do /home que serão automaticamente montados e qual será o diretório importado para a montagem. Abaixo segue um exemplo de uma possível configuração do arquivo /etc/auto.home. alunos public tmp install iso

-fstype=nfs -fstype=nfs -fstype=nfs -fstype=nfs -fstype=nfs

nfs-alunos:/export/alunos nfs-public:/export/public nfs-tmp:/export/tmp/tmp nfs-install:/export/install nfs-iso:/ftp/iso

Este arquivo define vários pontos de montagens. Cada um deles será somente montado quando necessário, ou seja, quando alguém acessá-lo ou fizer uso de algum recurso que referencie algo que esteja na árvore de arquivos deste diretório. 6.1.6 Demais configurações Swap em arquivo Como o sistema bpbatch utilizado cria apenas uma partição para o sistema e utiliza o restante do disco para cache, optou-se por utilizar cache em arquivo ao invés de partição. Alias, o problema que surgia quando da utilização de uma partição de cache éra o tamanho da partição de cache e de sistema, do Linux, ser igual ao tamanho da partição que seria utilizada pelo Windows. Como não foi possível estabelecer um tamanho as duas partições do Linux que fosse exatamente igual ao tamanho da partição do Windows cada vez que fosse trocado de Linux para Windows, ou vice-versa, o sistema éra carregado pela rede e a cache em disco éra simplesmente descartada. Isso ocorria devido as diferenças de tamanho das partições. Cria uma swap em disco resolveu o problema. Neste caso, algumas modificações são necessárias. A primeira delas é editar o arquivo /etc/rc.sysinit e comentar as linhas de criação e ativação da swap. São elas: 24

action $"Ativating swap partitions: " swapon -a -e swapon -a action $"Enabling swap space: " /bin/true

Para comentá-las basta coloar um "#"no inicio. Após feito isso, é necessário incluir as linhas de criação da memória swap em arquivo. Isso pode ser feito editando-se o arquivo /etc/rc.local e incluindo as seguintes linhas: dd if=/dev/zero of=/dev/swapfile bs=1024 count=128000 mkswap /dev/swapfile swapon /dev/swapfile

Essas três linhas irão criar um arquivo swap com 128MB de tamanho. Para aumentar ou diminuir este tamanho basta mudar o count. Por fim, não esquecer de remover ou comentar a linha referente a partição swap do arquivo /etc/fstab. XFS A partir da versão 8 do RedHat alguns scripts como o /etc/init.d/xfs vem com algumas modificações que podem não funcionar no caso de utilização do diretório /usr remoto. Especificamente no caso do xfs é fácil de resolver o problema. Toda vez que o sistema é inicializado o script de inicialização do xfs ele verifica se existe a necessidade de re-gerar o diretório de fontes. Se ele achar necessário, inicia-se um processo de remoção e atualização de arquivos armazenadas na árvore de diretórios do /usr, que por padrão é acessível somente leitura pelas máquinas cliente a fim de evitar possíveis problemas de segurança e alteração de dados. No entanto, esta re-construção da base de fontes não é necessária. Para evitar que este procedimento seja executado basta colocar um return no início da função buildfontlist() dentro do script /etc/init.d/xfs. Scripts de serviços Alguns problemas que também podem surgir no processo de inicialização e carga do sistema e no processo de finalização do sistema são a falta de comandos para os scripts do /etc/init.d/. A solução deste problema passa por duas etapas: a primeira delas é verificar quais comandos são necessários antes da montagem do /usr e a segunda é a verificação de quais comandos são necessários após a liberação do ponto de montagem /usr. No primeiro caso é preciso verificar quais comandos são necessários para os scripts que antecedem o script que monta os sistemas de arquivos. O script responsável pela montagem de diretórios remotos normalmente é o /etc/init.d/netfs. 25

Logo, basta ir até o /etc/rc3.d e /etc/rc5.d e procurar por comandos que estejam no /usr e são chamados pelos scripts que antecedem o script SXYnetfs. No caso de existir algum deve-se copiar os comando utilizados para um diretório como o /bin e modificar os scripts para procurarem estes comandos em suas novas localizações. Isso por que diretórios como o /bin serão incluidos na imagem do sistema. O segundo caso é idêntico ao primeiro. A única diferença é que agora devem ser localizados os scripts no /etc/rc0.d e /etc/rc6.d que são executados posteriormente ao script KXYnetfs. Os demais procedimentos são iguais aos descritos no parágrafo anterior, primeiro caso. Configurando a aparência das tty A configuração das tty é feita de modo a melhorar a aparência e facilitar a localização. São incluidos parâmetros como arquitetura, data, hora e número da tty. O arquivo que configura a aparência de uma tty é o /etc/issue. Incluindo os parâmetros citados no parágrafo anterior, este arquivo irá possuir um conteúdo semelhante ao que segue: Red Hat Linux release 8.0 (Psyche) Kernel \r on an \m \d \t \l

Onde "\r"indica a versão do kernel, "\m"a arquitetura da máquina, "\d"a data, "\t"a hora e "\l"o número da tty. Sincronização de relógios A sincronização de relógios é útil e desejável em uma rede de computadores. Relógios sincronizados evitam problemas de datas envolvendo arquivos de diferentes máquinas importados por NFS, evitam que um e-mail seja enviado de uma máquina com o horário e data desajustados. Para ativar a sincronização de relógios é necessário configurar o ntpd do sistema. Normalmente ele é configurado através do arquivo /etc/ntp.conf. A configuração desse arquivo deverá ter algo semelhante ao que segue: restrict default ignore restrict 127.0.0.1 server ntp.inf.ufsm.br fudge 127.127.1.0 stratum 10 driftfile /etc/ntp/drift broadcastdelay 0.008 authenticate yes keys /etc/ntp/keys

26

Sendo que o servidor de sincronização ntp.inf.ufsm.br deve estar sincronizando seu relógio com algum servidor de tempo externo e deve permitir que sincronizações sejam efetuadas por clientes internos a rede. Existe também um outro comando que simplesmente serve para ajustar o relógio em um dado momento. O comando rdate atualiza a data e hora da máquina local levando em consideração uma máquina fonte. O comando rdate -s relogio.inf.ufsm.br ajusta o relógio local de acordo com a resposta enviada pelo servidor de tempo relogio.inf.ufsm.br. Neste caso, é interessenta executar também o comando hwclock –systohc. Este atualiza o relógio físico da máquina a partir do relógio lógico, atualizado pelo comando rdate.

6.2 Compilando o Kernel Na versão do bpbatch utilizada surge um pequeno problema com relação ao tamanho do kernel do sistema operacional. Quando o kernel do Linux ultrapasso o tamanho de 1MBytes o bpbatch não consegue inicializar a imagem do sistema e gera algumas mensagens de erro. Porém, este erro não é identificado e não especifica que o problema á no tamanho do kernel. Através de testes e pesquisas realizadas é que se chegou a essa conclusão. A solução mais rápida e prática é a compilação do kernel para cada um dos conjuntos de arquiteturas de máquinas da rede. Diferentemente do que muita gente imagina, esta tarefa pode ser bastante simples. Basta saber as especificações de cada arquitetura e o que é necessário para o sistema. Com isto , a configuração do kernel é feita em questão de poucos minutos. A única tarefa custosa pode ser a compilação do kernel. Mas, caso existam algumas máquinas mais potentes, o ideal é utilizá-las para a compilação do kernel. Sabendo-se as configurações necessárias e possuindo algumas máquinas com um poder de processamento maior é possível se ter várias versões de kernel compiladas para diferentes arquiteturas em questão de alguns minutos. Um kernel com menos de 1 MB de tamanho pode facilmente ser conseguido compilando-se como módulo todas as configurações que tenham esta opção disponível. Outro detalhe importante e que merece atenção é o processo final de instalação do kernel. Comandos como o make modules_install devem ser executados na máquina com a arquitetura para a qual o kernel foi compilado e não na máquina que foi simplesmente utilizada para compilação. Por fim, para facilitar a configuração e seleção das opções do kernel necessárias basta verificar os manuais da placa mãe ou listar os dispositivos PCI ativos no sistema para o qual se deseja gerar um novo kernel. Executando o comando lspci obtem-se a lista dos disponitivos PCI da máquina. Dispositivos como controlador

27

de vídeo, adaptador de rede, placa de som, controladores IDE e outros mais que são necessários serem selecionados durante o processo de configuração do kernel.

6.3 Scripts de Atualização Os scripts de atualização são sistemas que permitem a atualização, instalação e configuração de aplicativos sem a necessidade de alterar a imagem do sistema operacional ou gerar uma nova imagem. A idéia consiste acrescentar uma chamada a um shell script "remoto"em algum dos scripts de inicialização do sistema que é executado toda vez que o sistema é carregado. Um exemplo é o acrescimo da três linhas de código abaixo no script /etc/rc.local. TIPO=compaq export TIPO sh /usr/local/etc/conserta.sh

No caso, o script, que fica na árvore de arquivos do diretório importado /usr, conserta.sh é o responsável por tarefas de atualização e configuração do sistema. A variável TIPO identifica o conjunto de máquinas ao qual será aplicado uma determinada rotina de atualização, configuração ou instalação. Desta forma cada conjunto de máquinas pode ter as suas próprias e independentes rotinas de manutenção. Como o script conserta.sh fica localizado num diretório armazenado no servidor de arquivos, a tarefa de realizar reparos, ajustes e incrementar o sistema fica fácil e prática. Incluindo-se os dados em algum diretório pertencente a árvore do /usr e as devidas rotinas de execução no script conserta.sh a maior parte das tarefas de atualização podem ser perfeitamente resolvidas.

6.4 Armazenando o /usr num servidor NFS Após o sistema ter sido devidamente configurado é hora de enviar uma cópia do /usr para um servidor de arquivos remoto. Este deve ser uma máquina capaz de atender a demanda gerada pelos clientes da rede. Ou seja, caso exista um número relativamente grande de máquinas clientes, uma máquina servidore com pouca memório, uma conexão de rede lenta ou um processador muito pobre poderá afetar sensivelmente o desempenho dos sistemas clientes. Tendo uma máquina adequada para o armazenamento do diretório que será importado por dezenas ou até centenas de máquinas é hora de liberar acesso de escrita para a máquina que acabou de ser instalada e configurada. O diretório exportado pelo servidor de arquivos pode ser montado em qualquer ponto de montagem para que seja realizada a cópia dos arquivos do /usr. Por exemplo, supondo-se que o diretório exportado seja o /export/linux/usrRH80. 28

O comando mount nfs-linux.inf.ufsm.br:/export/linux/usrRH80 /mnt irá montar o diretório remoto no /mnt. Após a montagem do diretório remoto basta realizar a cópia dos dados do diretório local /usr para o diretório remoto /mnt. O comando cd /usr; tar -c -f - . | ( cd /mnt; tar -x -f - ) realiza sem nenhum problema o processo de cópia de dados garantindo que as permissões e propriedades dos arquivos permaneçam intactas. Finalizando, falta apenas incluir o ponto de montagem /usr no arquivo /etc/fstab. Agora o /usr passará a ser um diretório remoto. No caso apresentado, deverá ser incluida uma linha como a que segue: nfs-linux:/export/linux/usrRH80 /usr nfs auto auto

Agora o sistema está pronto para ser testado com as novas configurações e o sistema de arquivos remoto. Executando o comando nfs-linux:/export/linux/usrRH80 /usr e o comando reboot e o sistema não apresentando nenhum tipo de anomalia é um sinal de que esta tudo funcionando como deveria. Sem problemas.

6.5 Geração da imagem do sistema O processo final de criação da imagem do sistema operacional é a geração da imagem do mesmo. Existe um aplicativo denominado mrzip que compacta e gera o(s) segmento(s) da imagem. Este programa recebe como entrada um arquivo contendo uma pequena descrição dos procedimentos básicos de gereção da imagem. Entre eles os diretórios que serão excluidos da imagem e o nome dos arquivos de saída. Normalmente coloca-se o mrzip e o arquivo de descrição (linux.mrz) no diretório /tmp. A geração da imagem iniciará a partir do comando mrzip linux. Este comando faz com que o mrzip leia o arquivo de descrição linux.mrz. Abaixo segue um exemplo de um arquivo .mrz. showlog filter -"tmp/*" fullzip "/" "/tmp/linux.imz"

Onde linux.imz é o nome que será dado a imagem. Esse nome pode ser alterado de acordo com a vontade e/ou necessidade de cada administrador/usuário. Filtros podem ser adicionados. Caso não se quer incluir o diretório /var/tmp basta incluir no arquivo .mrz a linha abaixo: filter -"var/tmp/*"

29

6.6 Atualização dos menus e teste da imagem Após gerada a imagem e o kernel do sistema devem ser transferidos para o servidor tftp. O próximo passo é a inclusão da nova imagem no menu do conjunto de máquinas ao qual a máquina geradora pertence. Essa tarefa pode ser feita manualmente. Atualmente a imagem é armazenada num diretório temporário na máquina ftpimz.inf.ufsm.br. Esta máquina possui servidor ftp e um usuário especial para a transferência de dados. O diretório padrão deste usuário é o próprio diretório temporário, exportado pelo servidor tftp e importado pelo servidor ftpimz, aonde as imagens devem ser armazenadas. Posteriormente, no servidor tftp, a imagem nova deve ser movida para o diretório do grupo a que pertence. A atualização dos menus é feita de forma automatizada. Existe um sistema de shell scripts que verifica todos os diretórios de imagens dos diversos grupos de máquinas e gera os respectivos menus. Portanto, após a nova imagem ter sido movida para o local adequado, a atualização dos menus pode ser feita através do sistema disponível no /etc/adm/tftpboot. Lá, basta digitar o comando make menus para que a nova imagem seja incluída no menu do respectivo grupo. Após atualizado o menu, agora surge a fase de teste da nova imagem. Para isso basta selecioná-la no menu de alguma das máquinas integrantes do grupo em questão. Caso o sistema seja alocado na cache da máquina e inicializado sem problema a imagem está correta, sem problemas. Caso contrário, é necessário verificar as mensagens de erro e o porque de a imagem não ser carregada e/ou não funcionar adequadamente.

6.7 Cuidados adicionais Alguns cuidados adicionais devem ser tomados quando se esta trabalhando com instalação e geração de imagens de vários conjuntos de máquinas com arquiteturas levemente distintas. Isso por que pode ser desejável um único diretório remoto compartilhado para o /usr de todas as máquinas. Neste caso, se as arquiteturas forem semelhantes, porém não totalmente compatíveis a nível de arquivos binários, é bom tomar cuidado para que seja armazenado o /usr, no servidor de arquivos remoto, do conjunto de máquinas que contenhas as instruções mais básicas, ou seja, instruções que serão perfeitamente interpretadas pelas máquinas dos demais conjuntos. Um exemplo simples seria um laboratório com dois conjunto de máquinas distintas. O primeiro conjunto é formado por máquinas K6II 450 MHz (i386) e o segundo conjunto é formado por computadores Pentium III 1 GHz (i686). Neste caso, o segundo conjunto de equipamentos é capaz de executar qualquer arquivo executável do primeiro conjunto. No entanto, o primeiro conjunto não será capaz 30

de executar qualquer código de máquina do segundo conjunto. Logo, o /usr do primeiro conjunto é o que deveria ir para o servidor. Evitando maiores problemas de compatibilidade. 6.7.1 Sistema de arquivos de rede Alguns cuidados que podem também ser levados em consideração são questões como a escolha do sistema de arquivos que dará suporte ao diretório de rede exportado /usr. Basicamente os mais conhecidos e utilizados são o NFS, o AFS e o CODA. O NFS é o mais antigo e simples. E talvez o mais eficiente. No entanto, podem surgir problemas referentes a sua escalabilidade. Um número muito grande de clientes pode acabar gerando um tráfego bastante grande e acabar criando verdadeiros gargalos de rede. Além disso, o NFS não oferece segurança aos dados. Já sistemas de arquivo como o CODA oferencem sistemas de cache e segurança. O sistema de cache, no lado dos clientes, ameniza o problema de escalabilidade. Devido a cache local nos clientes o CODA teorica e potencialmente suporta mais clientes que o NFS. Com as cópias locais são potencialmente feitas menos transferências de dados pela rede. O AFS tem entre suas caracterísitcas e benefícios segurança, consistência e redundância. Além disso, controle e manipulação de volumes e quotas. Imagens do sistema também são possíveis, cache local (escreve na saída), listas de controle de acesso (grupos, máquinas) e sistema de arquivos global. Devido a algums de seus benefícios a eficiência é prejudicada. Logo, cada ao administrador/organização verificar a validade e necessidade de sistemas de arquivos com características as do AFS.

7

Conclusão

O objetivo deste trabalho foi apresentar os passos para a instalação, configuração e manutenção de um sistema de boot remoto. Para isso foram apresentados os passos básicos para a instalação e configuração de um servidor de boot remoto e imangens de sistemas operacionais. No decorrer deste relatório são apresentadas idéias, sugestões e formas de resolver os problemas mais comuns em um sistema de boot remoto que utilize a tecnologia bpbatch e/ou que busque tornar o sistema mais simples, prático e efeciente. Esta produção escrita certamente servirá como base para usuários e instituições que desejam instalar um sistema desse gênero em sua rede. Além disso, as idéias e sugestões aqui apresentadas poderão ser úteis a administradores de rede 31

que já trabalham com processos de boot remoto para a manutenção de diferentes laboratórios temáticos e/ou sistemas em suas redes de computadores.

Referências [1] Mrzip para windows. http://www.inf.ufsm.br/~kreutz/ dowloads/bootRemoto/geracaoDeImagens/win%dowsMrzip. zip. [2] Bienvenue au CUI. Official BpBatch distribution and utilities related to remote-boot. http://cui.unige.ch/. [3] Chang Kim. Diskless, Remote-boot Linux, May 2000. [4] James Mohr. How to make Network Configuration as easy as DHCP. Linux Magazine, April 2000. [5] CS 125 Networking Project. Trivial file transfer protocol (tftp), March 2000. [6] Marc Vuilleumier Stückelberg and David Clerc. Linux Remote-Boot miniHOWTO: Configuring Remote-Boot Workstations with Linux, DOS, Windows 95/98 and Windows NT, February 2000. [7] Rembo Technology SaRL. Bpbatch. http://www.bpbatch.org. [8] Vassilis Virvilis. Yet Another Remote Boot HOWTO Story (YARB), September 1997. [email protected].

32